如何阻止visual studio更新程序集引用？ [英] How to stop visual studio from updating assembly references?

问题描述

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

In our environment we have a Lib folder which contains various third party assemblies referenced by our projects. For example, Enterprise Libary and Elmah.

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

Sometimes a dev doesn't do a get latest on that folder. When the dev then loads a project which can't find the assembly in the expected folder, Visual Studio automatically locates another copy and updates the project references.

当出现问题时开发人员检查项目并将其他人搞砸了。

The problem occurs when the dev checks in the project and it screws everyone else up.

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

Is there a way to stop visual studio 2008 from doing this?

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

UPDATE: I wanted to add that we are using TFS for source control.

推荐答案

这是我们如何守卫在我的公司反对。 （您的里程会有所不同！）

Here's how we guard against that at my company. (Your mileage will vary!)

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

Any non-system (or otherwise non-GAC) references come from our dev server, which every developer has mapped to their W: drive. We have a common DLL directory, with subdirectories by client (or vendor), and further subdirectories as appropriate. No DLLs are ever stored in source control, except license.dll as needed by Infragistics occasionally.

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

For vendor-provided libraries (EntLib, Infragistics, etc.), as policy we reference from the W: drive. Period. No one is authorized to reference from anywhere else. This codes the Hint in the project files to a common path.

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

For in-house libraries (client and internal projects), our continuous integration process outputs the DLLs into the appropriate branch of this directory -- again, where all our references come from.

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

This does slow down our local compile time (for local debugging), as VS will auto-refresh these against the server every time. It's an annoyance (sometimes a project may take 5 or 6 minutes to build locally), but it's a necessary evil to work around people using different references. The advantage here is that as soon as someone checks in code for one of those references, the CI server kicks off a build and everyone gets it pretty darned quickly.

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

The trick to this is a stable, repeatable build process and a continuous integration server. We're using CruiseControl.NET, integrated with NAnt builds, but insert your favorite CI server and build tool here.

到目前为止，由于这个过程我们没有问题，除非构建服务器启动，而我们的源代码控制系统（也称为Demon Spawn，请参阅我最近的许多评论）执行一个大型的多文件办理登机手续。 （由于Demon Spawn不支持交易签到。）然而，这种情况非常罕见 - 可能每5或6周一次。然后立即重建力量来处理它。

So far we've had zero issues as a result of this process, except when the build server kicks in while our source control system (also known as the Demon Spawn, see so many of my recent remarks) performs a large multi-file check-in. (As Demon Spawn doesn't support transacted check-ins.) However, this is a very rare occurrence -- perhaps once every 5 or 6 weeks. And a force rebuild immediately afterward takes care of it.

只是一些想法......这种技巧应该让人们不要搞砸你的源代码控制 - 并作为额外的奖励，减少源控件的大小，因为你不会检查DLL，只是dll.refresh文件。

Just some thoughts ... This technique should keep people from screwing up your source control -- and as an added bonus, reduce the size of your source control as you won't be checking in DLLs, just dll.refresh files.

这篇关于如何阻止visual studio更新程序集引用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！