在我的团队中，我们有数百个共享dll，其中许多还引用其他dll自己引用其他dll，等等。我们已经开始为所有我们觉得足够通用的dll使用'Shared'目录，以便在其他项目中使用，例如数据库通信dll。在C＃中处理共享dll的最佳方式是什么？
的问题是，如果这些DLL一路下滑树的一个改变，那么一切都引用它需要重新编译，以避免版本问题（发生在运行时）。
为了避免这种情况，现在谈加入我们所有的“共享”的DLL到一个大集会，和任何人创建新的应用程序简单地引用，这本身。
这显然会变得越来越大，我不知道这是最好的方法还是不行。请任何想法？
这绝对不是最好的办法。我在我的工作中有几个“共享”的DLL，就是这样的。他们变得笨拙和困难（阅读：不可能）做出有意义的更改，因为变得难以确保更改不会破坏下游应用程序，这看起来与您正在尝试执行的操作完全相反。
这听起来像你真正需要做的是分开你的关注点好一点。如果所有这些DLL都相互引用，它们可能会紧密耦合。一个真正的“共享”DLL应该能够独立存在，或者作为三个或四个分组旅行的一部分。如果你的依赖关系实际上阻止你做出改变，那么你的耦合策略已经发生了可怕的错误。
把一切放在一个大的DLL当然不会让事情变得更好。事实上，可能是相反的。一旦你在一个DLL中获得了所有的东西，诱惑将会在那里把它里面的所有东西紧紧地联系在一起，这将使得事情不可能在以后分离出来。
我们做的是治疗共享DLL的维护，本身就是一个项目，拥有自己的源代码控制和一切。然后，每年大约两次，我们向公众发布共享DLL的“释放”，并带有其自己的版本号和所有内容。只要你总是使用DLL作为'set'（意味着你引用的所有文件都来自同一个版本），你就可以保证不会有任何依赖性问题。
可以使一个解决方案，包括所有连接的项目。
当你需要释放，只是构建此解决方案
更新。
正如你所说，解决方案不能容纳这么多dll。
在另一方面，你可以使用CruiseControl.NET有可能做出这样复杂的任务使外部MSBuild脚本 或。
从GoF的书，引述“计划，以一个接口，而不是实现。”这可能适用于您的一些图书馆。你已经意识到当你紧密耦合时你的发展变得脆弱。现在需要解决的是如何给你喘息的机会。
您可以创建一个接口。这将提供一个合同，任何应用程序都可以使用该合同来指定可用的最小功能集。
您可以创建一个实现接口的服务。这将允许你提供什么被认为是插件或插件。这使您可以设计一个契约版本，并期望您的工具能够遵守。
您可以创建仅使用接口的服务。这将允许您的应用程序发送符合设计合同的任何具体实现。
像开发编辑器和Web浏览器这样的产品使用这种方法来使一些代码重用成为可能。谢谢。美好的一天。
这将工作，但将意味着所有的项目加载到Visual Studio中，我不觉得被添加太多的项目后，这将是非常敏感的。此外，它意味着必须手动管理每个项目的编译dll，即使使用后构建脚本例如。 – HAdes 2009-02-11 21:48:45