1

我们拥有一整套产品，包括：

  • 用 VB6 编写的桌面应用程序。
  • 用 .NET 编写的桌面应用程序。
  • 用 .NET 编写的 Windows 服务。
  • 用 .NET 编写的 ASP.NET Web 应用程序。
  • 用 .NET 编写的 ASMX 和 WCF 服务。

所有 .NET 代码都是用 VS2008 编写的，面向 .NET 3.5 和“任何 CPU”。我们可以针对特定的处理器，但不希望这样做，因为它会在依赖关系树的下方引起问题。我们还不能将任何东西迁移到 .NET 4.0，尽管稍后它将成为一个选项。

所有应用程序共享一些重要的注册表项。我们通过让 .NET 代码始终查看 32 位注册表视图来解决注册表重定向问题。

一些 .NET 代码通过 COM 互操作与 VB6 DLL 对话，但这非常有限，我们可以轻松删除这种依赖关系（现在注释掉，稍后在 .NET 中重新编写）。

所有 Web 应用程序和服务都设计为托管在 IIS 中。需要支持从 5.1 开始的所有版本。

我们构建的虚拟机当前运行的是 Windows XP（32 位）。如有必要，我们可以创建新的。

我的任务是确保一切都在 64 位 Windows（所有版本）上正常运行。我目前在使用 .NET 安装项目时遇到问题，所有这些项目都是使用 VS2008 安装项目模板编写的。

即使源代码是 Any CPU，设置项目也没有此功能。您必须将该TargetPlatform属性设置为一个处理器。这不是很有用。我们不能setup.exe在 32 位操作系统上安装为 32 位，在 64 位操作系统上安装为 64 位吗？如果我是安装应用程序的最终用户，我将不知道要运行哪个安装程序。

4

2 回答 2

1

从那以后，我研究了 VS2010 安装项目、WiX 和 InstallShield，它们的行为方式都相同。我将不得不把这个问题写成“不可能”。我打算这样做：

  • 只需提供单独的 32 位和 64 位安装程序即可。
  • 编写一个单独的加载程序批处理文件或 exe 来检测位数并运行适当的安装程序。
于 2011-06-06T08:13:11.213 回答
0

我有一个应用程序可以决定在运行时加载哪些 DLL，包括 32 位还是 64 位 DLL。我最终和我的老朋友 setup2go 一起完成了这项工作。无论什么无法将 64 位 dll 放入 x86 安装程序，除非将其更改为 x64 但这不是我想要的，它也应该安装在 32 位系统上，其中 64 位 DLL 会占用一些空间但没有害处.

所以只是谷歌 setup2go，有可能，也许只是没有 MSI。

于 2013-01-24T11:16:23.440 回答