VB.NET 调用DLL的问题

[weixin_41052431]

大家好，

DLL是以前VC++编写的，主要用于各种计算，32位。供其他非.NET程序调用的。
现在有需求开发一个VB.NET的程序，正好可以使用DLL中的一些计算逻辑，所以想直接使用。
有一些不明白的地方：

1， .Net编译的时候一班选择Any CPU。这样的话在64位主机上应该就是按照64位运行的，这个时候，调用的32位DLL会有什么问题吗？

2， DLL是否应该被编译成64位的更好？

还是说其实和DLL是32位 64位没有任何关系？
因为是春节期间，又是竞标阶段，所以来不及试了。如果有兄弟有类似的经验，麻烦分享。
谢谢!

[threenewbee]

.Net编译的时候一班选择Any CPU。这样的话在64位主机上应该就是按照64位运行的，这个时候，调用的32位DLL会有什么问题吗？ 有问题，不能调，必须架构相同 DLL是否应该被编译成64位的更好？ 32调用32，64调用64，64位的优势在于（1）可以利用更大的内存空间，数据量大的有优势。（2）long、double等高精度运算速度明显快。64位对于一般的商业程序，性能上没有什么优势。

[weixin_41052431]

这个方案可以吗 DLL不改，VB.NET编成32位的。这样是不是成本最小。

[liiris]

和主机要对应，32位主机用32位dll，64位主机用64位dll

[蒋晟]

做两个版本 AnyCPU发布的话要带两个版本的DLL，在安装的时候检测CPU类型选择装哪个，也可以在AssemblyResolve的时候检测CPU类型决定加载哪个目录下的DLL。

[以专业开发人员为伍]

你可以仅仅将你调用对方DLL的“中间层类库”声明为 32 位的。

[以专业开发人员为伍]

引用 楼主 weixin_41052431 的回复:

1， .Net编译的时候一班选择Any CPU。这样的话在64位主机上应该就是按照64位运行的，这个时候，调用的32位DLL会有什么问题吗？

不完全是这样的。编译为 Any CPU 的 DLL按照 exe 来动态适配，既有可能使用 64 位也有可能是用wow32位的 .net 框架类库。

[以专业开发人员为伍]

不过，我们有一点要事先明确，既然我们降低标准引用一个 32 位的第三方 DLL，那么上述的为了封装它的 api 而声明为 32 位的“中间类库”其实也就不可能用一个基于 CLR 64 位的 exe 来调用。所以你需要判断并且告诉用户“您用的这个 c++ 类库早就过时了！” 或者你干脆就将 exe 主程序也降级为 32 位的，这样所有的 Any CPU 的 DLL 在运行时就会自动降级为 32 位的。但是建议你除非万不得已不要采取这么被动的解决方案。

[sp1234_maJia]

嗯，我觉得还是应该再整理一下思路： 首先我的出发点不是从所谓“技术”出发，而是从你的问题的背景出发。你既然选择一个 32 位第三方类库，那么要么你的整个解决方案（的主程序）不得不声明为 32 位的，要么就是要为一套 32 位第三方类库和另外一套 64 位的第三方类库分别开发“中间类库”来封装接口，并且以工厂方式来调用。前者是整个解决方案都不能享受到64位系统的好处了，如果你认为编译时的“成本最小”是你最在乎的事情话（而你并不在乎运行时让进程获得 64 位的好处），那么也只需要将主程序和封装第三方类库的类库声明为 32 位的，其它类库仍然可以声明为 Any CPU 的。后者是麻烦了一些，但是这个麻烦的根源并不是 .net 功能太差而造成的，而是你选择一个 32 位的第三方计算库造成的，你需要同时再去找一个 64 位的第三方类库来适配。 所以对第二个问题来说，DLL 通常应该声明为 Any CPU 的，这样才能同时适配 32 位和 64 位应用。

[sp1234_maJia]

你的 .net 的类库“通常”就是应该保持为 Any CPU的。只有这类极端尴尬的情况下，因为你必须封装第三方非 .net 类库，改为 x84 或 x64。

[weixin_41052431]

相比之下，是不是大家还是推荐把第三方DLL升级成64位的？

[良朋]

不知道你有没主要到，当你选择Any CPU时，下面有一个缺省的勾选项“首选32位”，.net编译时会先尝试32位编译。