将程序集部署为.Net Framework的一部分

Question

我有一个针对.NETFramework 4.0(具有强名称)的程序集(MYASM.dll)

我希望以某种方式部署此程序集,它是.NETFramework(或整个系统认为它)的一部分在目标计算机上.

我的意思是:

1. .NET运行时看到它看到System.dll(无需在本地部署或提供引用路径)
2. MSBuild在不需要<Reference Include="MYASM" />提示路径的情况下看到它
3. 用户可以Add reference在Visual Studio中进行制作,<Reference Include="MYASM" />而无需强/全名

我已经通过将其添加到GAC解决了1.(显然是2.).但这显然是不够的.

通过将我的程序集放在一个特殊的文件夹([INSTALLFOLDER]\lib)中并设置了registryKey,我已经部分解决了3.HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0\AssemblyFoldersEx\MyAssemblies

然后我可以做添加引用,但后来我得到:
<Reference Include="MYASM, Version=1.1, Culture=neutral, ..." />在我的csproj而不是<Reference Include="MYASM" />我想要的.

使用第二种方法,如果我手动编辑csproj,一切都很好,但我不能要求我的用户这样做.

我该怎么办？

[编辑]显然我有自己的MSI并不明显.但是我有.我不用魔棒控制用户的机器

Answer 1

不,你已经把它尽可能地拿走了.实际上,VS如何将部分程序集名称放入项目文件中并不明显.这不是公共代码,不能被篡改.很确定它不使用白名单,也不能注意参考装配位置.

最可能的细节是程序集的PublicKeyToken.框架组件总是必须为它们提供完全相同的值,b77a5c561934e089.它的值甚至在CLI规范(Ecma-335)中规定.接下来最有可能的是签名证书,将该程序集标识为Microsoft所拥有的.但是两者都存在完全相同的问题,您无法获得强名称或签署程序集所需的私钥.他们被锁在雷德蒙德的一个金库中,只有值得信赖的构建工程师可以访问它们.

还有另一个令人讨厌的小细节你正在俯瞰,你几乎不怕DLL地狱.冷酷的事实是,如果你曾经揭露装配在GAC另一台机器,是不是在你的控制,那么你永远不能再次进行更改.您无法再修改程序集的公共接口.无法添加新的公共方法或类型,无法修改方法的参数和返回类型,无法添加枚举成员等.甚至更严厉的是,微软担心的是,你无法真正改变私人和内部成员.程序员有使用Reflection来解决这个问题的诀窍,这是一个非常好的bug修复工具.但至少你可以告诉他们"不要那样做!".

进行此类修改需要增加[AssemblyVersion].现在您获得了另一种DLL Hell,安装程序可能没有更新该机器.或者更糟糕的是,解决方案使用具有不同引用的项目.Microsoft必须为框架程序集解决这个问题,他们通过修改CLR来解决这个问题.自动将旧版本转发到新版本.使用为.NET 2.0构建的程序集的基本原因可以在.NET 4.x项目中使用.您无法为自己的DLL获得此类服务.

"不要这样做"是唯一的好建议,进入DLL地狱的麻烦是一个很棒的学习经验,我可以推荐给任何人.地狱必须经历令人担忧.

最好的建议是发布Nuget包.它们完全相反,从未部署在GAC中,版本号变化非常快.但是当程序员需要它时总是可用的.