我们在工作中有相当多的可重用代码（一件好事）。每当我创建一个使用它们的新项目时，我习惯将他们的项目作为我的解决方案的一部分包含在内，我想知道是否应该将它们重新用作已发布的dll。我包含该项目的原因（或理由）是，如果我在其中一个中发现了一个错误，我可以在那里进行分支和修复。但它似乎将我的重点放在手头的项目上。
（不确定这是否应该是CW，因为只有两个答案，我有兴趣了解您的偏好）
答案 0 :(得分：4)
这里有几点需要考虑。
我将预编译库用于几个月内不会改变的代码。如果我需要在一个包中每月更改一些代码，那么该包不会被预编译。
我更喜欢预编译以加速主程序的编译。但我总是在预编译中包含调试符号，因此如果发生错误，我可以像其他一样轻松地逐步执行预编译的程序集。
答案 1 :(得分：3)
这真的取决于你是否在负责他们的团队，如果你在团队中将他们添加到你的来源并随时修复它们。如果您不在该团队中，则将其用作客户并在发现缺陷时提出缺陷，否则您可能会对您的工作范围之外的代码负责。如果你处于一个可能无关紧要的灵活环境中，但对我来说，突然之间成为代码更改的所有者可能是一个问题，我没有发言权。
答案 2 :(得分：2)
对此的一个考虑因素是所述库的重用频率。如果它们倾向于在完全不同的项目中使用，那么你必须要小心，不要把自己画成一个角落，在那里你会发现你在三周前对图书馆做出的改变，以支持一些新的应用程序，结果是破坏了其他几个应用程序。
基本上我所说的是你不想忍受不顾一切地改变图书馆的诱惑;最好不要在第一时间把这种诱惑放在你面前。如果库是为重用而设计的，那么应该非常仔细地设计和实现对它的任何重大更改，并针对所有依赖库/应用程序进行全面测试。当你真正把源放在你面前等待修改时，采取严格的方法变得相当困难。
我的方法是创建相关库的解决方案;例如，我可能有一个用于核心接口和抽象类的程序集，一些用于不同具体实现的程序集，另一个用于单元测试，等等。如果存在依赖的可重用库层，那么它们通常都会被集中到同一个解决方案中。
但它在应用程序级别停止。任何不总是将与核心库一起部署的项目都不共享解决方案，它只是引用已编译的DLL。它迫使我对库更改保持纪律，而不是开始调整它以支持某些特定的UI功能。
我不知道这是否是“正确的”方法，但我之前因为过早更改库而没有正确测试依赖性而被咬过，而且它总是过于专注于单个应用程序而不是考虑副作用。我对此的看法是，当您在图书馆工作时，您需要专注于库本身，而不是如何在特定场景中使用它。
答案 3 :(得分：1)
对于这种情况，库是由多个独立解决方案重用的，或者当库由另一个团队管理而不是使用它的团队时，我认为要记住的最重要的规则是特定版本的解决方案通常应该与该库的特定版本相关。
问自己以下几点：从六个月前检查解决方案的源代码时，我会得到哪个版本的库？如果答案是：“始终是库的最新版本”，这可能会有问题。
我参与了一个项目，开发人员自动在本地网络上发布了他们的dll的新版本。我们正在处理的解决方案只引用了该特定位置的dll。这个问题是我们从来不知道我们正在编译哪个版本的库，并且不止一次，在测试之后，我们发布了一个版本的应用程序，因为突然发布了该库的新版本（我们没有不测试。
但是，当您开发应用程序的第2版时，它将变得更加明显，但仍需要维护应用程序的已发布版本1。您希望发布版本1的补丁，其版本与最初发布的版本相同（当错误不在该库中时），否则您将不得不重新测试整个应用程序。
因此我通常会添加我使用的所有库（默认情况下不在GAC中）作为我的解决方案的一部分，并将它们检入源代码管理中。通过这种方式，我可以完全控制解决方案在任何给定时刻使用的版本。