从非特定 .NET 应用程序引用特定于平台的库
我经常需要在我的 C# 应用程序中包含少量本机代码，我倾向于通过 C++/CLI 来完成此操作。 通常我只需要使用 C++ 库，而 .NET 没有好的替代方案； 但有时性能也是一个因素。
这是有问题的； 这样做意味着添加对特定 x86 或 x64 库的引用。 大多数库都支持 64 位和 32 位编译，或者只需要进行少量修改即可在 64 位下工作。 但是，我只能引用特定 C# 项目构建目标中的一个版本。 这意味着我需要为解决方案中的每个项目手动添加多个构建目标。
在这种情况下，VS.NET 非常没有帮助：如果将 C++ 库和 C# 库添加到同一解决方案中，并且 C# 和 C++ 库同时具有 32 位和 64 位目标，则您的解决方案将包含一个“任何 CPU”目标，一个“混合平台”目标、x64 目标、x86 目标（C# 称为 32 位）、win32 目标（C++ 称为 32 位），甚至更多； 全部至少有两个版本（发布版和调试版，除非您添加了更多版本）。
这一切很快就变得混乱起来，而且没有什么充分的理由。 明显的行为不应该那么棘手：如果我有一个引用 C++ 项目的 C# 项目，那么很明显 64 位版本应该引用 64 位版本，对于 32 位也是如此。
最糟糕的是，所有这些都会产生两个独立但相同的可执行文件：任何 CPU .NET 项目都可以在 32 位和 64 位模式下未经修改地工作，但我还没有找到加载适当平台特定支持的方法库取决于应用程序启动的模式。
总结一下这个长篇大论：
- 是否有可能在跨平台应用程序上使用 VS 减轻痛苦 - 让它无需手动添加对适当构建目标的适当引用-保持？
- 是否有一种简单的方法可以使 .NET 可执行文件具有特定于平台的引用，可以在 32 位和 64 位模式下运行，并根据需要加载适当的程序集？
I often need to include little bits of native code in my C# apps, which I tend to do via C++/CLI. Usually I just need to use a C++ library for which there exists no good alternative for .NET; but sometimes performance is a factor too.
This is problematic; doing so means adding a reference to a specific x86 or x64 library. Most libraries support both 64-bit and 32-bit compilation, or require only minor modifications to work under 64-bit. However, I can only reference one of the versions from a particular C# project build target. That means I need to add several build targets by hand for every project in the solution.
VS.NET is extremely unhelpful in this case: If you add a C++ library and C# library to the same solution, and the C# and C++ libraries have both 32 and 64 bit targets, your solution will contain an "Any CPU" target, a "Mixed Platforms" target, a x64 target, a x86 target (which is what C# calls 32-bit), a win32 target (which is what C++ calls 32-bit), and maybe more; all in at least two versions (being Release and Debug, unless you've added more).
This get's messy fast, and for no good reason. The obvious behaviour shouldn't be that tricky: if I have a C# project referencing a C++ project, then it should be somewhat obvious that the 64-bit version should reference the 64-bit version, and similarly for 32-bits.
The worst part of it all is that all this results in two separate but identical executables: a Any CPU .NET project can work unmodified in both 32 and 64 bit modes, but I've not found a way to load the appropriate platform specific supporting libraries depending on the mode the app was started in.
To summarize this long ramble:
- Is it possible to make working with VS on cross-platform apps less of a pain - to get it to add the appropriate references to the appropriate build targets without hand-holding?
- Is there a simple way to make a .NET executable with platform-specific references that can run both in 32-bit and 64-bit mode, loading the appropriate assemblies as needed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该问自己的主要问题是，您是否需要 64 位版本。 有关详细信息，请参阅 Scott Hanselman 和 我自己。
如果您确实需要这两个版本，您还可以将 32 位和 64 位库都加载到 GAC 中，以便运行时可以自动选择正确的版本。
如果您不想对您的库进行 GAC，您还可以查看 这篇 StackOverflow 帖子，其中描述了加载正确程序集的方法。 但我不太喜欢这个解决方案，因为它确实需要一个插件模型
The main question you should ask yourself is, do you need a 64-bit version. For details see blogs posts by Scott Hanselman and myself.
If you really need both versions, you can also load both the 32bit and 64bit library into the GAC, so the runtime can chose the correct one automatically.
If you don't want to GAC your libraries, you can also take a look at this StackOverflow post, where a way to load the correct assembly is described. I don't really like this solution though, because it really requires a plugin model
我的回答是肯定的。 一种可能的方法是使用插件架构，这样它的工作方式如下：
然后为插件版本准备两个项目。 一个配置为针对 x86 进行编译，而另一个则针对 x64 进行编译。 反过来，x86 插件包装了 C++ 库的 x86 构建，以及 C++ 库的 x64 构建。
这有点复杂，因为您必须维护两个插件项目文件，而源文件可以共享。
使用插件架构，插件库在运行时加载，因此您有足够的时间来检测现在是在 x86 还是 x64 上，然后决定加载哪个插件。
希望这有帮助。
My answer is YES. A possible approach is to use addin architecture so it works like this,
Then you prepare two projects for the addin versions. One is configured to compile for x86, while the other for x64. In turn, the x86 addin wraps over x86 build of the C++ library, and the x64 over x64 build of the C++ library.
This is slightly complicated because you have to maintain two addin project files, while the source files can be shared.
Using addin architecture, the addin libraries are loaded at runtime, so you have plenty of time to detect if now on x86 or x64, and then decide which addin to load.
Hope this help.