我已经阅读了很多关于32位转换为64位的文章。我使用了很多供应商硬件，并最终获得了每个硬件的64位和32位驱动程序。从32位到64位似乎是一个简单的过渡。
然而，问题在于我们不想“过渡”。我们希望保持两者并存，而不必为每个修改复制代码库。当我说“我们”时，我指的是“我”，因为我是唯一的开发人员，如果复制更改，我的生产力将减少三分之一。
我知道对于简单的C#应用程序，我可以编译一个无论架构如何都能运行的版本，并且已经能够做到这一点。然而，我在处理我使用的驱动程序和库方面遇到了困难。我认为只需编写两个不同的安装程序，每个安装适当的驱动程序，就可以轻松解决问题，但是我该如何在应用程序中实际引用那些DLL呢？如果我引用32位驱动程序但安装了64位驱动程序，则会出现找不到正确库的错误。尝试同时引用两者也无法解决问题，因为其中一个始终会缺失。
我该如何正确处理这个问题呢？我希望在安装方面得到建议（我是否正确地使用了两个单独的安装程序），以及如何正确引用DLL以允许任何一种。
你能否只引用一个通用命名的.dll文件，并且该DLL文件可以根据安装程序安装为64位或32位？此外，如果你可以依赖目标文件系统是NTFS，你可以根据需要创建32位或64位DLL的符号链接。
看看ScottHanselman的文章“回到基础：关于x86和x64以及.NET Framework和CLR的32位和64位混淆”。
他没有提到任何特别涉及您安装程序困境的内容，但可能有一些对您有用的信息。
我可以提供一个建议：您能否通过依赖注入来抽象出驱动程序（或与驱动程序配合工作的代码），就像在N-Tier应用程序中抽象出数据访问一样？
最佳实践是进行两次设置，这就是为什么您在混合设置上可能会找不到信息的原因，就微软而言，他们说要进行2个设置，并且第三方设置 IDE（如 InstallShield）也支持这种策略。
在 InstallShield 中，您将使用发布标志，在构建设置时将其传递给 Installsheild 的命令行。您制作 2 个合并模块，一个用于32位平台，另一个用于64位平台，其中包含每个平台所需的驱动程序。当设置构建时，您已经分配给每个合并模块的发布标志允许选择32位或64位，具体取决于您正在构建32位还是64位。
顺便提一下，如果您的应用程序在 Windows 上运行，很可能您的客户会比您预期更快地迁移到 64 位版本。上次我开始维护双平台版本时，它应该持续多年，但最终我们仅在几个月后停止了 32 位版本的构建。
