在C ++的“旧时代”中,您有两个选项可用于创建(类或其他)库 - DLL或静态链接。
我的解决方案中有一些项目是“共享”库,供同一解决方案中的两个或多个其他项目使用。现在,它们被导出为DLL,然后忠实地复制到使用它们的每个实际可执行文件的“bin”文件夹中。
我已经厌倦了看到所有这些DLL都在运行(对于我的库和Nuget提供的第三方库),如果有.NET,我实际上更愿意将它们“链接”到可执行文件中这样做的方法(不仅仅是将代码放在单独的文件夹中并将它们包含在所有项目中,这对于通过检查解决方案资源管理器使其显而易见而言是一种丑陋的方式)。
那么 - 将“链接”库与.NET一起消失了吗?如果是这样,至少有一种注册程序集的方式(我们以前用来注册COM DLL的方式),所以在安装解决方案中有多个可执行文件的情况下,只有DLL的一个副本在多个地方复制相同的DLL?
答案 0 :(得分:2)
AFAIK .NET(和CLR)没有静态链接库的概念。
正如SLaKs指出的那样,有一些工具可以愚弄IL,但是你需要权衡这种增加的复杂性的成本,以减少浮动的DLL文件的数量;真的那么重要吗?
相反,您可以使用"共享项目",至少从Visual Studio 2015开始。
它只是作为公共代码/资源的可引用容器,与您希望实现的结果非常接近。
请参阅" What is the difference between a Shared Project and a Class Library in Visual Studio 2015?"。
根据SLaKs,也请参阅" Static Linking of libraries created on C# .NET"。
答案 1 :(得分:0)
实际上,我发现了一个"解决方案"这给了我很多我想要的效果。 Costura.Fody Nuget包在编译时将所有必要的东西(包括通常复制到bin / [configuration]文件夹中的所有DLL)收集到最终可执行文件中的资源中。
我要标记另一个答案,因为这是我原来问题的重点;但是,如果有其他人来看,他们可能会想要考虑Costura.Fody包,如果它符合他们想要完成的目标。