在 32 位安装程序期间启动 64 位进程以修改 32 位和 64 位 .NET machine.config
我创建了一个使用 AnyCPU 构建的 ADO.NET 数据提供程序。直接引用时，它在 64 位和 32 位 Windows 操作系统上都可以正常工作。但是，在我的安装程序中，我使用 .NET machine.config 注册 DbProviderFactory 并将我的程序集放置在 GAC 中，以便用户可以通过 System.Windows.DbProviderFactories 访问数据提供程序。只要应用程序以 32 位运行，这种方法就非常有效。它不适用于为 x64 构建的应用程序。
这是我发现的。我的安装程序针对 32 位。因此，我的 DbProviderFactory 仅添加到 32 位 .NET machine.config。为了让 x64 应用程序通过 DbProviderFactories 使用我的数据提供程序，需要使用 64 位 .NET machine.config 进行注册。
我必须有两个安装人员吗？一个针对 32 个，另一个针对 64 个？我的所有程序集都是 AnyCPU（因为我不知道也不关心用户的应用程序是什么平台）。
我的有点复杂的解决方案是这样的。在安装程序期间，我有自定义操作来检查操作系统是否为 64 位（此处）。如果是，我想启动一个运行 64 位控制台应用程序的进程，将我的 DbProviderFactory 添加到 machine.config （64 位）。我的安装程序本身将在 32 位 machine.config 中注册。我尝试过，但失败了，因为我无法在面向 32 位的安装项目中使用 64 位程序集。但是，我将尝试使用 AnyCPU 构建控制台应用程序，假设它将作为 64 位操作系统上的 64 位进程运行。
这相当混乱，但我认为它会起作用。为什么这是一个坏主意？为什么微软说“要将 .NET Framework 应用程序分发到 32 位和 64 位平台，请构建两个 MSI 包，一个针对 32 位计算机，另一个针对 64 位计算机”（msdn）。由于从技术上讲我的所有程序集都是 AnyCPU，它会起作用吗？
另外，我正在使用 .NET 3.5
I have created an ADO.NET data provider that is built using AnyCPU. When referenced directly it works fine on both 64 and 32 bit Windows OS. However, in my installer, I register my DbProviderFactory with the .NET machine.config and place my assemblies in the GAC so users can access the data provider through System.Windows.DbProviderFactories. This works great as long as the application is running as 32-bit. It does not work for applications built for x64.
This is what I have found. My installer is targeted for 32 bit. Therefore, my DbProviderFactory only gets added to the 32-bit .NET machine.config. In order for x64 applications to use my data provider through the DbProviderFactories, it needs to be registered with the 64-bit .NET machine.config.
Do I have to have two installers? One targeting 32 and the other 64? All of my assemblies are AnyCPU (because I don't know or care what platform the user's application is).
My somewhat complex solution was this. During the installer, I have custom action that checks if the OS is 64-bit (here). If it is, I want to start a process that runs a 64 bit console app that will add my DbProviderFactory to the machine.config (64-bit). And my installer itself will register with the 32-bit machine.config. I tried and it failed since I cannot have a 64-bit assembly in a setup project that targets 32-bit. However, I am going to try to build the console app using AnyCPU assuming it will run as a 64-bit process on 64-bit OS's.
This is rather messy, but I think it will work. Why is this a bad idea? And why does microsoft say "To distribute a .NET Framework application both to 32- and 64-bit platforms, build two MSI packages, one targeted at a 32-bit and the other a 64-bit computer" (msdn). Will it work since technically all of my assemblies are AnyCPU?
Also, I'm using .NET 3.5
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
回答我自己的问题：
1）我不需要 32 和 64 位安装程序。然而，这只是情况，因为我的所有程序集都是 AnyCPU。
2) 这不是一个坏主意，相反，这是一个好主意，因为我只需向客户端分发一个安装程序，并且它神奇地为 64 位计算机执行额外的安装操作。
3) 我认为 M$ 说如果程序集或包含的引用是为 32 或 64 位显式构建的，则拥有两个安装程序。
最终解决方案：在我的 32 位安装程序中，我在 machine.config 中注册程序集。然后我检查操作系统是否是 64 位（使用我的问题提供的链接）。如果是，我会启动一个命令行实用程序（包含在我的安装程序中），该实用程序是作为一个单独的进程为 AnyCPU 构建的。该实用程序在 64 位 machine.config 中注册我的程序集。这是可行的，因为 AnyCPU 实用程序仅在 64 位操作系统上作为新进程启动，并假设它将默认为 64 位进程。完毕。
To answer my own questions:
1) I do not need 32 and 64 bit installers. However, this is only the case because all of my assemblies are AnyCPU.
2) It's not a bad idea, rather, it is a good idea because I only have to distribute one installer to clients, and it magically preforms extra install actions for 64-bit machines.
3) I think M$ says to have both installers if the assemblies or included references are explicitly built for 32 or 64 bit.
The final solution: In my 32-bit installer, I register the assembly in the machine.config. Then I check if the OS is 64-bit (using the link provided my question). If it is, I launch a command line utility (included in my installer) that is built for AnyCPU as a separate process. The utility registers my assemblies in the 64-bit machine.config. This works because the AnyCPU utility only gets started as new process on a 64-bit OS, with the assumption it will default to a 64-bit process. Done.