如何阻止visual studio更新程序集引用?

时间:2008-10-23 14:34:45

标签: .net ide tfs

在我们的环境中,我们有一个Lib文件夹,其中包含我们项目引用的各种第三方程序集。例如,Enterprise Libary和Elmah。

有时开发人员不会在该文件夹上获取最新信息。当开发人员加载一个无法在预期文件夹中找到程序集的项目时,Visual Studio会自动找到另一个副本并更新项目引用。

当开发人员检查项目时,会出现问题,并且会阻止其他人。

有没有办法阻止visual studio 2008这样做?

更新:我想补充说我们正在使用TFS进行源代码管理。

4 个答案:

答案 0 :(得分:4)

以下是我们如何防范我公司的情况。 (你的里程会有所不同!)

任何非系统(或其他非GAC)引用都来自我们的开发服务器,每个开发人员都已将其映射到其W:驱动器。我们有一个共同的DLL目录,客户端(或供应商)的子目录,以及适当的其他子目录。没有任何DLL 永远存储在源代码管理中,但偶尔需要Infragistics需要的license.dll除外。

对于供应商提供的库(EntLib,Infragistics等),作为我们从W:驱动器引用的策略。期。没有人被授权从其他任何地方参考。这会将项目文件中的提示编码为公共路径。

对于内部库(客户端和内部项目),我们的持续集成过程将DLL输出到此目录的相应分支中 - 同样,我们的所有引用都来自。

这确实减慢了我们的本地编译时间(用于本地调试),因为VS每次都会针对服务器自动刷新这些时间。这是一个烦恼(有时一个项目可能需要5到6分钟才能在本地构建),但是使用不同的引用来解决这些问题是一个必要的恶魔。这里的优点是,只要有人检查其中一个引用的代码,CI服务器就会启动构建,每个人都会很快得到它。

这方面的技巧是稳定,可重复的构建过程和持续集成服务器。我们正在使用与CruiseControl.NET版本集成的NAnt,但在此处插入您最喜欢的CI服务器和构建工具。

到目前为止,由于这个过程我们没有问题,除非构建服务器启动,而我们的源代码控制系统(也称为Demon Spawn,看到我最近的许多评论)执行一个大的多-file签入。 (由于Demon Spawn不支持交易签到。)但是,这种情况非常罕见 - 可能每5或6周一次。然后立即重建力量来处理它。

只是一些想法......这种技术应该让人们不要搞砸你的源代码控制 - 作为一个额外的好处,减少你的源代码控件的大小,因为你不会检查DLL,只需要dll.refresh文件

答案 1 :(得分:2)

除了将你的dll放在源代码控制中之外,我在大多数情况下都与John进行了协商。

我通常有一个ThirdParty文件夹,然后有供应商产品和版本细分,因此,ajax工具包存储在$ / ThirdParty / Microsoft / AjaxToolkit /(某些版本号)中。我喜欢这种方法,因为我们可以在制作构建的所有工件上添加标签。

另一个想法可能是项目中的dll,所以如果他们获得最新的项目,他们将获得dll。

答案 2 :(得分:1)

我认为这不可能。

如果在文本编辑器中打开项目文件,您将看到visual studio不存储对程序集的硬引用,但它会存储“HintPath”。如果找不到引用,visual studio将自动尝试GAC。

建立一个持续集成服务器(如果你还没有)可能是一个好主意,这将作为这种情况的预警系统。

答案 3 :(得分:0)

是的,这绝对是绝对的,真的很痛苦。这是您的另一个选择: 1.如其他帖子所示,从GAC中删除程序集。 2.让您的依赖项解析系统将程序集传递到BIN文件夹。这也是您编译所有解决方案程序集的地方。 3.设置所有引用Copy Local = false AND Specific Version = False。 这一点是在调试时导致程序集加载异常,因为如果它不在BIN中,则没有任何东西可以在那里复制它。并且您的解决方案将编译得更快,因为VS不必复制文件。这将阻止“亡灵”dll坐在obj目录中的某个地方,VS会奇迹般地找到并复制...

这适用于您控制的解决方案。多年来我们一直这样做。并且很容易弄清楚是否有什么东西偏离原因然后你只是去寻找一个具有Copy Local = true或者Version Version = True的程序集,偶尔会发生这种情况(忘记,累了等等)。 我目前的问题是我不控制我正在处理的解决方案的结构或设置,因此寻找这个古老问题的解决方案。我希望VS团队能够解决它......唉......团队,请停止这种痛苦。