我构建了大量的控制台应用程序来运行这里的业务流程。大多数都具有相同的性质，它们被部署到应用程序服务器，访问源数据库并将分阶段数据放入目标数据库。一些访问文件共享等。
鉴于该设置，我喜欢一遍又一遍地使用SAME日志包（log4net）。我在每个app.config中保留配置。但是，我一直发现我和我一起“携带”了log4net的DLL。
我的意思是，当我开始一个新项目时，我必须引用log4net。我选择不将log4net放入GAC或将其完全安装到我的开发机器上。相反，我将整个下载包放在一个目录中，通常这样做：
我抓住DLL并在我的控制台应用程序项目中创建一个/ lib目录，我引用它。
这个接缝的好处是我总是知道我有正确的版本，因为我复制到本地DLL。我也在项目中查看。
但是，缺点是我最终得到了大量的项目，每个项目都有一个/ lib目录，通常存在相同的DLL。
我做错了什么？我只是错过了解决方案/项目开发背后的整个想法吗？我觉得我的项目非常不同，以至于我不希望所有项目都加载到一个解决方案中。
我很想知道别人如何解决这个问题。
答案 0 :(得分：1)
为每个控制台项目创建一个lib文件夹只是为了容纳DLL，除了确保它存在于您的计算机本地之外时，它不会用于任何实际目的。如果您担心组织，那可能会使事情变得更糟，因为现在您的开发计算机和应用服务器上有多个DLL副本，所有这些都是相同的。
当log4net发布更新时会发生什么？然后，您必须更新log4net，重建和重新部署的每个独立/物理副本和引用。如果你使用除log4net之外的多个第三方DLL，问题只会变得更糟。
话虽如此，当您添加第三方引用时，默认情况下，每次编译时它都会将DLL复制到本地DLL到构建文件夹，并且您的控制台程序将使用该本地副本。您可以通过自己添加一个，并查看引用的Copy Local属性（应该设置为true）来验证这一点。所以基本上，你已经做了VS已经为你做的额外工作。
我要做的是将所有第三方DLL放在开发机器的中央目录中，只需在每次创建控制台应用程序时添加对这些DLL的引用。每次部署时，它都会随身携带DLL的本地副本。如果有新的第三方dll版本，您仍然需要更新每个解决方案中的每个引用，重建并重新部署到您的应用程序到应用程序服务器... 但是，区别你只是更新一个物理副本！
答案 1 :(得分：1)
你看过ilmerge了吗？您应该能够将log4net.dll文件化为可执行文件，以使其独立。
示例用法（作为构建后步骤）：
"$(SolutionDir)Lib\ilmerge" /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /out:$(ProjectDir)bin\Merged\MyExe.exe MyExe.exe log4net.net40.dll