在项目中使用开源库(例如 SharpPcap 或 FakeItEasy)时,我们应该将源代码添加到解决方案中还是针对 DLL 进行编译并将它们放在解决方案中的目录中?
6 回答
您应该使用二进制文件进行编译。
原因很简单:你的项目和第三方库是不同的项目,在你自己的构建过程中编译别人的库可能会引入不必要的复杂性和项目依赖。
有些库要求您在环境中安装一些工具和插件。
通常我在 Visual Studio 解决方案的根目录中有一个依赖项或lib目录,而不是在构建过程中包含开源代码,其中包含二进制文件和源代码。当我想调试第三方代码时,我只需打开另一个 Visual Studio 实例,并将调试器附加到整个过程。
想想一些第三方开源库很肥,可能你自己的代码库很小:因为你添加了很多源代码,你的构建过程会延迟很多,因为你只是添加了无用的东西(代码,插件。 ...)。
我更喜欢将构建过程委托给库的作者的原则,就我而言,我认为自己是此类库的消费者:我不需要每次都重新编译它。
啊,如果您打算修改源代码,最好的做法是联系作者并将补丁发送给他/她,以便他/她可以将其包含在官方发行版中。如果没有,您知道:每次作者发布新版本时,您都会有额外的工作将新源代码与您自己的更改合并...
我想说的是,如果您使用的是最新版本的源代码,那么使用提供的二进制文件可能会不稳定。但是,如果他们提供版本化的二进制文件,那么它们很可能已经过测试并且是稳定的。
这还取决于您是开箱即用还是要对其进行修改。
通常我针对二进制文件进行编译。我的解决方案上有一个文件夹 vendor/libs,或者我只是使用 NuGet,然后重新编译 Dll。
但是,有时我需要调试开源库,而事情没有按预期发生。就在那时,我链接了源代码(仅用于调试)。
投入生产时,我使用二进制文件,因为代码已经过很好的测试。
我也不会想。
以下是不放源代码的原因:
- 开发人员可能会不小心修改代码
- 图书馆通常会发生变化
以下是解决方案中包含 DLL 的原因:
- 使部署更容易
- 减少使用不兼容版本库的机会
- 减少丢失参考的机会
那么,怎么做?
Class Library
将具有唯一名称的新项目添加ClassLibrary1
到解决方案中,例如在
Build
其项目设置页面中,配置Output path
到应用程序输出路径在
Build Events
页面中,将以下行添加到Post-build event command line
块中:del "$(TargetPath)"
将外部 DLL 复制到其文件夹并将它们添加到
ClassLibrary1
设置
Copy Local
为true
所有添加的引用设置
Project Dependancies
其他项目,检查ClassLibrary1
从放置 DLL 的路径添加其他项目的引用
ClassLibrary1
将
Copy Local
所有这些添加到其他项目中的 DLL 集合到false
因此,该项目ClassLibrary1
成为解决方案外部库的中央控制。每次您将添加到其Rebuild Solution
的ClassLibrary1
最新 DLL 复制References
到应用程序输出文件夹中,并删除它自己生成的名为ClassLibrary1.DLL
. 并且应用程序在编译时或运行时将使用相同版本的 DLL,您无需在每次发布应用程序时进行额外的部署或检查每个部署。
二进制文件:
- 除非您注意提取源的发布版本,否则更稳定
- 更轻松
来源:
- 可以修改
- 可以通过直接进入源代码来调试 API 的使用
最后一点通常很重要,因此请准备好在 IDE 中下载并打开源代码,即使您只是从二进制文件开始,尤其是在您使用的库还很年轻或测试不佳的情况下。
奥卡姆剃刀说,如果您不需要修改库,则应该使用二进制文件。