我已经阅读了很多关于将32位转换为64位的主题。我使用了很多供应商的硬件，并最终获得了每个硬件的64位和32位驱动程序。从32移动到64似乎是一个简单的过渡。
然而，问题在于我们不希望“过渡”。我们希望并排维护两者，而不必为我们执行的每个修改复制代码库。而“我们”，我的意思是“我”，因为我是唯一的开发人员，它会有效地将我的工作效率降低三分之一来复制更改。
据我所知，对于一个简单的C＃应用程序，我可以简单地编译一个无论架构如何都能运行的版本，并且能够做到这一点。但是，我在弄清楚如何处理我使用的驱动程序和库时遇到了麻烦。我认为简单地编写2个不同的安装程序，每个都安装相应的驱动程序，这是微不足道的，但我如何在应用程序中实际引用这些DLL？如果我引用32位驱动程序但安装了64位驱动程序，则会出现无法找到正确库的错误。试图引用两者并不会解决问题，因为总是会丢失它。
我该如何妥善处理？我想在安装方面提出想法（我是否正确使用2个独立的安装程序）以及如何正确引用DLL以允许其中任何一个。
答案 0 :(得分：2)
最佳解决方案是Reinderien建议：让安装人员处理它。
如果由于某种原因，您希望同时安装32位和64位DLL并使您的应用程序能够加载，那么SetDllDirectory API函数就派上用场了。您的p / invoke DllImport属性可以使用“SomeLib.dll”，您可以使用SetDllDirectory指向。\ Lib32或。\ Lib64子目录。你会尽快做到这一点，可能是Main的第一件事。
答案 1 :(得分：1)
您是否可以引用一个通常名为.dll的DLL，并且安装程序安装该DLL是64位还是32位？此外，如果您可以依赖目标文件系统为NTFS，则可以根据需要对32位或64位DLL进行符号链接。
答案 2 :(得分：0)
查看ScottHanselmans的文章“Back to Basics: 32-bit and 64-bit confusion around x86 and x64 and the .NET Framework and CLR”。
他没有提到任何专门涵盖安装人员困境的内容，但可能会为您提供一些有用的信息。
我可以投入的一件事：您是否能够通过依赖注入抽象出驱动程序（或与驱动程序一起使用的代码） - 就像您在N层应用程序中抽象出数据访问一样？
答案 3 :(得分：0)
最佳做法是进行两次设置，这就是为什么你在查找混合动力信息时遇到的困难，就微软而言，他们说有两种设置，而第三方设置IDE就像installshield一样认可该策略。
在Installshield中，您将使用在构建设置时通过命令行传递给Installsheild的释放标志。你创建了2个合并模块，一个用于32个，一个用于64个包含每个平台的驱动程序，当安装程序构建时，已经分配给每个合并模块的发布标志允许选择32位，如果您的建筑物32，反之亦然。
顺便说一句，如果您的应用程序在Windows上运行，那么一旦您的64位版本可用，您的客户很可能会比您预期的更快地迁移。上次我开始维护双平台构建时，它应该会持续多年，最后我们在几个月后才停止构建32位。
答案 4 :(得分：0)
你应该做两个单独的安装程序。然后使用带有自定义操作的第三个部署项目来加载正确的安装程序。
我在这篇文章中给出了一个例子：Single MSI to install correct 32 or 64 bit c# application