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

这取决于项目的设置方式。如果要预编译站点(并使IntelliSense正常工作),必须具有Visual Studio引用。但在运行时,ASP.NET将自动加载bin文件夹中丢弃的任何内容…因此,可以在代码隐藏中访问该程序集的控件/对象,而不添加项目引用。

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

我们使用Subversion版本控制第三方程序集,然后通过 svn:externals 进入相关解决方案或项目的子目录,然后引用它们(并复制到bin中)。

这提供了相当多的好处:

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

所以多做点准备工作,但我觉得值得。请注意,我们没有版本控制(svn:ignore)我们的bin和obj目录,第三方程序集位于同一个Subversion存储库中,由相对路径引用。

fwiw:subversion 1.6.6为基于文件的svn:externals修复了一个恼人的bug。这意味着您可以从一个目录中选择一个或多个文件(例如程序集),而不必向下拉整个目录。

2013更新

随着Nuget的兴起,考虑 hosting your own feed 在选择使用svn:externals之前,通过本地服务器,这仅仅是因为它提供了所有相同的好处,而且它通过扩展管理器烘焙到Visual Studio中,并提供了更好的信息和元数据,例如,能够让开发人员知道何时有新的版本。

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

通常我只是把它们放进垃圾箱,除非它是一些不那么简单的东西的一部分。例如,SiteCore安装自己,并有几个文件夹,它喜欢使用这些文件夹来放置自己的代码,以提供一个非平凡的示例。

这里的si是非常正确的。 另外:保存您的bin文件夹以获得生成/编译的结果。如前所述,使用“库”文件夹进行链接。我甚至用devexpress来做这个。

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

这样,您就可以确保每个人都使用相同版本的devexpress(在sourcesafe中的版本)来测试他们的代码,并且您对在您的计算机上编译但在另一台计算机上不编译的代码的问题会更少。

我总是首选项目引用而不是dll引用。主要原因如下。

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