将 .net 应用程序 32 位转换为 64 位
我有一个.net应用程序，
- 类库（目标平台设置为任何CPU）
- Winform应用程序（目标平台设置为任何CPU）
- 安装程序（目标平台设置为 >X86 和检测到的 .net Framework(x86) 依赖项设置)
现在，当我在 64 位计算机上通过 setup.exe 安装此应用程序时，它会安装在 Program Files [x86] 文件夹中；我猜这是 WoW64 在 64 位应用程序上模拟 32 位环境的功能。
现在，当客户要求将其转换为 64 位时，如果 32 位版本本身可以在 WoW64 中正常运行，为什么对他来说很重要？将其转换为 64 位会带来性能优势吗？
当我尝试将其转换为 64 位时，我是否需要更改所有内容，即
- 类库（将目标平台更改为 64）（如果我跳过此步骤会怎样？）
- Winform 应用程序（将目标平台更改为 64） （如果我也跳过这个怎么办？）
- 安装程序（将目标平台更改为 64）[检测到的依赖项列表没有显示任何 .NET Framework x64 选项，为什么？]
请提出建议。
I have got a .net application,
- Class library (Target Platform set to Any CPU)
- Winform Application (Target platform set to Any CPU)
- Installer (Target Platform set to X86 and Detected dependencies set for .net framework(x86))
Now when I install this application through setup.exe on a 64-bit machine, it is installed in the Program Files [x86] folder; I guess this is WoW64 feature of emulating 32-bit environment on a 64-bit application.
Now when a client asks to convert it to 64-bit, why does it matter to him if the 32-bit version itself works fine through WoW64? would converting it to 64 bit result in performance benefits?
And when I try to convert it to 64-bit, do I need to change it for all, ie ,
- Class Library (change Target platform to 64) (What if I skip this step?)
- Winform Application (change target platform to 64) (What if I skip this too?)
- Installer (change target platform to 64) [Detected dependencies listing doesn't show any .NET framework x64 option, why?]
Please suggest.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
无需转换，您的应用程序已作为 64 位进程运行。因为你在EXE项目上使用了AnyCPU。您将其安装到了错误的文件夹，但如果没有其他进程尝试以编程方式启动您的进程，那么这并不重要。这是极其罕见的。
从 TaskMgr.exe 的“进程”选项卡验证这一点。 32 位进程的进程名称后带有 *32。
为了让您的客户满意，请将安装项目的 TargetPlatform 设置更改为 x64，以便将其安装在 c:\program files 中。需要你几分钟。
No conversion is necessary, your app already runs as a 64-bit process. Because you used AnyCPU on the EXE project. You installed it to the wrong folder but that doesn't matter much if no other process tries to start yours programmatically. That's exceedingly rare.
Verify this from TaskMgr.exe, Processes tab. A 32-bit process has *32 after its process name.
Make your client happy by changing the Setup project's TargetPlatform setting to x64 so it gets installed in c:\program files. Takes you a few minutes.
您可以将 .NET 代码项目保留在 AnyCPU 上，但是要安装到 64 位而不遇到 32 位 WOW 内容，您需要更改您提到的安装程序项目属性。
如果您在安装程序中有自定义操作，则当您更改为 64 位时，这些操作可能不起作用。您可能会收到
BadImageFormatException。要解决此问题，您需要处理生成的 MSI：http:// adamhouldsworth.blogspot.com/2010/10/64bit-custom-actions.html
如果您的应用程序是独立的，那么它不会对客户端产生太大影响。当使用 64 位时，除了可以访问更多 RAM 之外，并没有任何免费的性能优势（尽管 JIT 有不同类型的可用优化）。
我见过的唯一需要 64 位的情况是当您在另一个应用程序中使用该 DLL 时，您不能在单个进程中混合位。
更新：也许缺少 64 位框架先决条件是因为您使用的是 VS 2005？
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7b00f4e9-64e3-4fb6-9906-880820ecda92
You can leave the .NET code projects on AnyCPU, however to install onto 64-bit without hitting the 32-bit WOW stuff you need to change the installer project property that you mention.
If you have custom actions in the installer, these may not work when you change to 64-bit. You might get a
BadImageFormatException. To resolve this, you need to faff with the resulting MSI:http://adamhouldsworth.blogspot.com/2010/10/64bit-custom-actions.html
It won't make much of a difference to the client if your application is standalone. There is no free performance benefit, other than access to more RAM, when going to 64-bit (though the JIT has different types of optimisations available).
The only situation I've seen where 64-bit is required is when you consume that DLL in another application, you cannot mix bit-ness in a single process.
Update: perhaps the lack of a 64-bit framework prerequisite is because you are using VS 2005?
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7b00f4e9-64e3-4fb6-9906-880820ecda92
64 位可能会也可能不会产生性能差异。 64 位应用程序还可以比 32 位应用程序利用更多的内存。
如果您在 64 位操作系统上启动 AnyCpu exe，它应该以 64 位启动（在任务管理器中查看，32 位进程会附加 *32）。如果将应用程序设置为 x64，则库必须是 x64 或 AnyCpu。
如果您没有本机仅限 x64 的引用，您可以将 exe 和 dll 保留为 AnyCpu，但您需要将设置修改为 x64。
至于框架，在 x64 计算机上（这是 x64 应用程序运行的唯一位置），框架始终包含 32 位和 64 位，分别位于 C:\Windows\Microsoft.NET\Framework 和 Framework64 中。
64 bit may or may not give performance differences. A 64 bit application can also utilize (way) more memory than a 32bit application.
If you launch an AnyCpu exe on a 64bit OS it should launch in 64bit (see in the task manager, 32bit processes are appended with *32 there). If you set the application to x64, the library must be either x64 or AnyCpu.
If you do not have native x64-only references you can leave your exe and dll as AnyCpu, but you will need to modify the setup to x64.
As for the framework, on an x64 machine (which is the only place an x64 app will run anyway), the framework always includes both 32 and 64 bit, found in C:\Windows\Microsoft.NET\Framework and Framework64 respectively.
不，它与程序无关，只与安装程序有关。
32位安装程序将其安装在程序的32位文件夹中，无论程序是32位还是64位。
遗憾的是，您无法让一个安装程序同时执行这两项操作 - 从设计上来说，您需要一个 32 位安装程序和一个 64 位安装程序。
这完全是 MSI 部分的设计决定，并且与程序完全无关。
No, it has NOTHING to do with the program, only with the installer.
32 bit installer installes it in the 32 bit folder for programs, regarless whether the program is 32 or 64 bit.
Sadly you can not have one installer doing both - you need an installer for 32 and one for 64 bit in concept, by design.
This is totally a design decision on the MSI part and, again, has nothing to do with the program at all.