我创建了一个使用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位（here）。如果是，我想启动一个运行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
答案 0 :(得分：1)
回答我自己的问题：
1）我不需要32位和64位安装程序。但是，这只是因为我的所有程序集都是AnyCPU。
2）这不是一个坏主意，而是一个好主意，因为我只需要向客户端分发一个安装程序，它就会神奇地为64位计算机执行额外的安装操作。
3）我认为如果程序集或包含的引用明确构建为32位或64位，M $表示要安装两个安装程序。
最终解决方案：在我的32位安装程序中，我在machine.config中注册程序集。然后我检查操作系统是否是64位（使用链接提供我的问题）。如果是，我启动一个为AnyCPU构建的命令行实用程序（包含在我的安装程序中）作为一个单独的进程。该实用程序在64位machine.config中注册我的程序集。这是有效的，因为AnyCPU实用程序仅作为64位操作系统上的新进程启动，并假设它将默认为64位进程。完成。