ASP.NET和Visual Studio - 添加项目引用与Bin文件夹DLL

Question

我昨天刚刚开始一份新工作，这只是我在ASP.NET工作的第二份工作。我们正在设置我的开发盒，并且遇到了Telerik等一些第三方组件的问题。我注意到他们安装了这些第三方工具，搜索DLL文件，将它们复制到bin中，然后添加引用指向BIN中文件的项目。对我而言，这似乎不是正常的做法。

我的印象是，如果你只是在bin文件夹中转储一个DLL，你不需要添加一个引用，它只是可用的？原因是，在我上一份工作中，我们使用了一些我们内部构建的类库来进行数据访问，并将DLL放在我们制作的任何新网站（而不是webapps）中。我不记得每个人都必须添加一个引用才能让它工作。

那么，有人可以解释如何向您的网络应用添加第三方引用的最佳实践吗？您是否在系统中安装DLL的位置添加引用？如果是这样，你检查复制本地，然后复制到垃圾箱？你是否只是将dll复制到bin中就是这样？您是否将dll复制到bin中，然后在那里添加对它的引用？

很抱歉，我确信这似乎是一个简单的问题，但我对我见过的两种看似不同的方法感到困惑。

Answer 1

这取决于项目的设置方式。如果要预编译站点（并使Intellisense正常工作），则必须具有Visual Studio引用。但是在bin文件夹中删除的任何内容都将在运行时由ASP.NET自动加载...因此可以在代码中访问该程序集的控件/对象，而无需添加项目引用。

对于小项目，我只是将DLL放入bin并添加引用。对于更复杂的站点/项目，我有一个专用的“库”文件夹，用于第三方加载项和代码。

Answer 2

我们使用Subversion版本控制我们的第三方程序集，然后通过svn:externals将它们下拉到相关解决方案或项目的子目录中，然后引用它们（并复制到bin中）。

这提供了很多好处：

1. 构建服务器更快乐，需要更少的维护并且不那么脆弱。
2. 我们有发布历史，可以通过在每个svn：external上设置修订号来明确控制每个解决方案/项目的版本控制。例如，您的中继代码可能使用最新的Telerik版本，但您的发行版分支使用旧版本。
3. 我们可以为不同的项目共享第三方程序集，并确信它们使用的是正确的版本。
4. 我们不依赖开发人员安装或升级到正确的版本，但他们仍然可以添加和测试新版本而不会干扰其他项目（假设您已明确定义了修订版）
5. 我们可以测试新版本，但如果事情不起作用，可以轻松返回。

所以更多的工作设置，但我认为这是值得的。请注意，我们没有版本控制（svn：ignore）我们的bin和obj目录，第三方程序集位于相同的Subversion存储库中，由相对路径引用。

FWIW：Subversion 1.6.6修复了基于文件的svn：externals的烦人错误。这意味着您可以从目录中选择一个或多个文件（例如程序集），而不必将整个目录拉下来。

2013年更新

随着NuGet的兴起，在选择使用svn：externals之前，请考虑通过本地服务器hosting your own feed，因为它为您提供了所有相同的好处，并且通过Extension Manager将其添加到Visual Studio中并提供了更好的信息和元数据，例如能够让开发人员知道什么时候有新版本。

唯一需要注意的是使用Win2008或更高版本的服务器来托管您的Feed，因为我使用带有Windows身份验证的SSL来保护Feed时遇到了旧的Win2003服务器的一些问题。我相信这是由于Win2003中使用的旧版IIS，但无法验证。

Answer 3

通常我只是将它们放入垃圾箱，除非它是不那么简单的东西的一部分。例如，Sitecore会安装自己，并且有几个文件夹，它们喜欢使用它来放置一些自己的代码来举例说明一些非常重要的事情。

Answer 4

那里的Si非常正确。 另外：保留bin文件夹以获取构建/编译的结果。如前所述，使用“库”文件夹进行链接。我甚至用devexpress来做这件事。

通常通过安装devexpress，它会将其dll安装在GAC中，您可以像参考标准的.Net dll一样引用它们。但是对于版本控制，使用库文件夹要容易得多。

通过这种方式，您可以确保每个人都使用相同版本的devexpress（sourcesafe中的版本）来测试他们的代码，并且您在机器上编译的代码的问题会更少，但是不会另一个。

Answer 5

我总是喜欢有项目引用而不是DLL引用。以下是它的主要原因。

• 添加其他项目参考的项目将不会是最新的。
• 对引用项目的任何更改都不会直接反映出来。用户必须手动删除旧引用并添加新引用。