在我目前的.net项目中，我使用各种.dll文件，一些是外部编写的，一些是由我创建的。现在我问自己，在不同的解决方案和项目中处理不同.dll文件的最佳实践是什么，让他们使用SVN，以便在不同的开发人员中使用它们。
好的，所以我要问一些一般提示：
我应该将.dll项目按源绑定到不同的解决方案，还是直接通过其release.dll绑定？
如何防止人们通过SVN获取文件来重新绑定dll源（全局程序集问题等）
使用尽可能多的.dll（按功能划分）或使用一个大的.dll来获得更简单的概述是不是很好？
请不要太难，我是这个行业的初学者，英语不是我的母语。
提前谢谢你，哈利。
答案 0 :(得分：2)
.NET中关于DLL的事情是它们在.NET .NET编程之前根本不像DLL。它们只是代码的容器。
几年前我读了一篇很好的文章也解释了这一点，因为它曾经让我感到困惑 - 我相信，它是由MS模式和实践人员之一编写的，讨论了命名空间之间的关系，程序集，项目和解决方案（如果我找到它，我会发布链接）。
出于源代码管理的目的，我认为您最好存储代码，并让它在最终用户的机器上进行编译。将已编译的DLL放入源代码控制中通常是您为第三方依赖项所做的事情。
这完全取决于我的经验 - 一些专家可能会有更好的建议。
答案 1 :(得分：2)
我建议设置包含外部dll的自己的NuGet提要。您可以将NUGet Feed设置为共享文件夹（无需安装）。这些供稿将在您的组织内部，您可以完全控制升级。
多个项目可以使用相同的NuGet包共享相同的dll。
http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds
答案 2 :(得分：1)
我认为在您的应用程序中使用dll不是可以回答的问题是好或不好不好，因为这取决于为什么你是哪个dll？使用
因此，如果您在解决方案中使用第三方dll，我认为将您的代码而不是您正在创建的dll设置为最佳实践，这样您就不会许多dll和你的编译器也没有引用许多dll。
答案 3 :(得分：1)
我认为3层架构是很好的做法。
GUI.dll
Business.dll
DataAccess.dll
我更喜欢项目引用而不是DLL引用，因为您在调试配置中引用Debug dll，在Release配置中引用Release dll。
答案 4 :(得分：1)
一般情况下，如果有充分的理由将代码划分为不同的程序集，则应将其划分为....
有很多理由将代码放入dll中，而不是将其放在一个大项目中。但是如果没有理由这么做就不应该创建很多dll（我已经看到一些ppl为每个命名空间创建一个dll，它们包含的类没有那么多，并且没有理由将它们分开）。
当然，将代码拆分为dll可能会导致一些问题，比如你在dll a中有一个类，在dll b中有一个类，并且每个都需要引用另一个。这主要是应用程序的设计问题。