针对 64 位和 32 位进行开发
我读过很多关于将 32 位转换为 64 位的内容。我使用了很多供应商硬件，并最终获得了每种硬件的 64 位和 32 位驱动程序。从 32 到 64 似乎是一个简单的过渡。
但问题是我们不想“转型”。我们希望并排维护两者，而不必为我们执行的每次修改复制代码库。我所说的“我们”是指“我”，因为我是唯一的开发人员，重复更改会有效地将我的生产力降低三分之一。
据我所知，对于一个简单的 C# 应用程序，我可以简单地编译一个无论架构如何都可以运行的版本，并且已经能够做到这一点。但是，我在弄清楚如何处理我使用的驱动程序和库方面遇到了困难。我认为简单地编写 2 个不同的安装程序，每个安装程序安装适当的驱动程序是很简单的，但是我如何在应用程序中实际引用这些 DLL？如果我引用 32 位驱动程序但安装 64 位驱动程序，则会收到错误消息，指出无法找到正确的库。尝试引用两者并不能解决问题，因为总会缺少一个。
我该如何正确处理这个问题？我想要关于安装方面的想法（我关于使用 2 个单独的安装程序是否正确）以及如何正确引用 DLL 以允许其中任何一个。
I've read a lot on the subject of converting 32-bit to 64-bit. I use a lot of vendor hardware, and have finally obtained both 64-bit and 32-bit drivers for each. Moving from 32 to 64 seems like it will be an easy transition.
The problem, however, is that we do not wish to "transition". We want to maintain both, side by side, without having to duplicate the codebase for each modification we perform. And by "we", I mean "I", since I'm the sole developer and it would effectively cut my productivity by a third to duplicate changes.
I understand that for a simple C# app, I can simply compile a version that will run regardless of architecture, and have been able to do it. However, I'm having a disconnect at figuring out how to handle the drivers and libraries I use. I think it'd be trivial to simply write 2 different installers, each installing the appropriate drivers, but how do I actually reference those DLLs in the application? If I reference the 32-bit drivers but install the 64-bit drivers, I get errors that it cannot find the proper libraries. Trying to reference both doesn't fix things, as one will always be missing.
How do I handle this properly? I'd like ideas on both the installation side (am I right about using 2 separate installers) as well as how to properly reference the DLLs to allow for either.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
最佳解决方案正如 Reinderien 所建议的那样：让安装人员来处理。
如果出于某种原因，您想要同时安装 32 位和 64 位 DLL，并让您的应用程序确定要加载哪个 DLL，则 SetDllDirectory API函数就派上用场了。您的 p/invoke DllImport 属性可以使用“SomeLib.dll”，并且您可以使用 SetDllDirectory 指向 .\Lib32 或 .\Lib64 子目录。您将尽快执行此操作，这可能是 Main 中的第一件事。
The optimal solution is as Reinderien suggests: Let the installer handle it.
If, for some reason, you want to install both 32- and 64-bit DLLs and have your application work out which to load, the SetDllDirectory API function comes in handy. Your p/invoke DllImport attribute can use "SomeLib.dll" and you can use SetDllDirectory to point to .\Lib32 or .\Lib64 subdirectories. You would do this as soon as possible, probably first thing in Main.
您能否仅引用一个通用名称为 .dll 的文件，并让安装程序安装的该 DLL 是 64 位还是 32 位？此外，如果您可以依赖 NTFS 目标文件系统，则可以根据需要符号链接到 32 位或 64 位 DLL。
Can you just reference one generically named .dll, and have that DLL be 64-bit or 32-bit as installed by the installer? Also, if you can rely on the target file system being NTFS, you could symlink to the 32-bit or 64-bit DLL as needed.
查看 ScottHanselmans 的文章“回归基础：围绕 x86 和 x64 的 32 位和 64 位混淆以及.NET Framework 和 CLR”。
他没有提到任何专门解决您安装人员困境的内容，但可能有一些对您有用的信息。
我可以提出的一件事是：您是否能够通过依赖注入抽象出驱动程序（或与驱动程序一起工作的代码）——就像您在 N 层应用程序中抽象出数据访问一样？
Check out ScottHanselmans article "Back to Basics: 32-bit and 64-bit confusion around x86 and x64 and the .NET Framework and CLR".
He doesn't mention anything that specifically covers you installer dilemma but there might be some useful info for you.
One thing I can throw in: are you able to abstract out the drivers (or the code that works with the drivers) via Dependency Injection - just like you'd abstract out Data Access in a N-Tier app?
最佳实践是进行两次设置，这就是为什么您很难找到有关混合设备的信息，就 Microsoft 而言，他们说进行两次设置，并且像 installshield 这样的第 3 方设置 IDE 也支持该策略。
在 Installshield 中，您将使用在构建安装程序时在命令行中传递给 Installsheild 的发行标志。您制作 2 个合并模块，一个用于 32 位，一个用于 64 位，其中包含每个平台的驱动程序，当安装程序构建时，已分配给每个合并模块的发布标志允许选择 32 位（如果您构建的是 32 位），反之亦然。
顺便说一句，如果您的应用程序在 Windows 上运行，一旦您的 64 位版本可用，您的客户很可能会比您预期的迁移速度更快。上次我开始维护双平台构建时，它应该持续多年，最终我们在仅仅几个月后就停止了构建 32 位。
It's best practice to make two setups, thats why you'll have trouble finding info on a hybrid, as far as Microsoft goes, they say 2 setups, and 3rd party setup IDE like installshield endorse that policy.
In Installshield you would use release flags that you pass in command line to Installsheild when building the setup. You make 2 merge modules, one for 32 and one for 64 containing your drivers for each platform, when the setup builds, your release flag already assigned to each merge module allows to select 32bit if your building 32 and vice versa.
Btw, if your application runs on windows, it's very likely your customers will migrate faster than you expect, once your 64bit version is available. Last time I started maintaining a dual platform build, it was supposed to go on for years, and in the end we stopped building 32bit after only a few months.
您应该制作 2 个单独的安装程序。然后使用第三个部署项目和自定义操作来加载正确的安装程序。
我在这篇文章中给出了一个例子： 单个 MSI 安装正确的 32 或 64 位 C# 应用程序
You should make 2 seperate installers. Then use a third deployment project with a custom action to load the right installer.
I've given an example on this post: Single MSI to install correct 32 or 64 bit c# application