一个很好的例子是System.Data.SQLite.
以上链接有这样的说法：
[Mixed-mode assembly] packages should only be used in cases where the assembly binary must be deployed to the Global Assembly Cache for some reason.
但为什么？混合模式组合似乎在我的项目中工作正常,没有GAC安装(只是xcopy到应用程序的exe目录).很少有一个更少的DLL.感觉更整洁那么有什么缺点呢？
反之亦然,为什么/应该有人喜欢两个DLL“native-dll interop-dll”版本？
Disclaimer: For a definite answer,you’d have to ask someone from the development team,but here’s my best guess.
在标准配置中,托管程序集将尝试查找并加载其所需的本机DLL.它将在平台相关的目录(x86或x64)中进行搜索.然后它将加载它找到的DLL,并继续在其上抛出P / Invoke互操作.
这是一个相当标准的过程,与.NET中的本地库进行互操作 – 唯一的自定义System.Data.sqlite代码是尝试查找DLL并加载正确版本的代码.其余的是P / Invoke.但是,即使这是在处理图书馆时常见的做法.
这种方法的主要优点是图书馆用户可以为Anycpu平台构建他的项目,并且处理器体系结构将在运行时解决 – 如果您在x86或x64上运行,则所有内容都将按预期运行,前提是两个本机DLL都可用.图书馆作者获得的支持请求较少.
我们将其与混合模式方法进行比较.混合模式DLL有一些缺点,主要的是它必须是平台特定的.所以如果你选择这种方法,你必须把你的应用程序绑定到一个特定的平台.如果要同时支持x86和x64,则必须构建单独的版本,每个版本链接到正确版本的System.Data.sqlite.
如果你没有完全正确的话,那么繁荣.更糟糕的是,如果您在x64开发机器上为Anycpu平台构建它,那么它首先看起来就会正常工作,但是它会破坏客户的旧x86盒子.处理这种问题不是很好,使用单独的DLL的简单解决方案完全解决了这个问题.
我可以想到的另一个缺点是无法从内存加载程序集,但这应该是最小的不便之处,因为这也适用于本机DLL.
对于GAC,我的猜测是,在单独的本机程序集的情况下,搜索它们的代码在某些情况下可能无法找到它们,或者可以找到不同版本的DLL. System.Data.sqlite中的代码尝试很难找到本机DLL,但混合模式DLL首先没有这样的问题,所以失败不是一个选项.
不过,你说：
It feels tidier.
我们来仔细看看这个.
