Visual studio 防止在VSS中签出第三方DLL

（我知道我正在使用Visual Source Safe，我没有选择，因为它附带MSDN订阅许可证，我的公司不想购买第三方源代码管理解决方案……）

我有一个VS2005解决方案，其中包含3个C#类库项目、2个ASP.NET网站项目和一个存储在Visual Source安全数据库中的ASP.NET web服务项目。一些项目引用了处理常见任务的公共库DLL

当一个新人在他们的工作站上设置解决方案并首次构建它时，它会在ASP.NET网站和web服务项目的bin文件夹中检出公共库DLL。当另一个正在进行项目开发的开发人员尝试构建时，他们会收到一条“由其他用户以独占方式签出的文件”消息

VS2005不会在引起头痛的DLL旁边显示复选标记

---

有什么方法可以防止这种情况发生吗？

不确定这是问题还是最佳解决方案，但如果您更新每个开发人员的计算机，使其安装相同的最新版本的通用DLL，这种情况就不会继续发生。我认为，如果项目文件引用的版本与开发人员计算机上安装的版本不匹配，VSS将签出\bin文件夹中的DLL。

为什么将bin文件夹签入SourceSafe？在我参与的项目中，第三方DLL被检入到与解决方案文件处于同一级别的单独文件夹（可能称为ExternalLibraries或ThirdParty）。编译过程将被设置为将DLL复制到bin文件夹中。这可以通过.refresh文件处理，也可以通过编译前或编译后步骤处理。这样，VisualStudio/SourceSafe就不会将文件视为已更新，也不会尝试将其签出

如果由于文件是依赖项，编译器已经将其拉入，我建议从VSS中删除bin文件夹。这与“从项目中排除文件夹”不同，后者在编译时对VS05隐藏文件夹（并给出您提到的编译错误）

如果第三方DLL不打算更改，另一个选项是在VSS中使这些文件为只读。这样，任何用户都无法签出文件。（要将文件标记为只读，您需要从VSS管理工具更改权限；开发人员的工具没有该功能。）

至于为什么会发生这种情况，我不相信VSS会检查二进制版本号——它只与修改文件日期有关。如果新开发人员提取所有代码，则所有文件（包括二进制文件）将以当前日期作为修改日期。这可能会导致不必要的签出

关于您以后的评论-我不确定为什么VS05不会将文件视为受源代码控制，但VSS UI会。我怀疑这与该文件夹中的.vss文件（及类似文件）有关。在这种情况下，VS05不正确。

@Pedro:

在VS 2005 IDE界面中，它没有指示\bin文件夹在VSS中。当我在VSS UI中查看该项目时，它显示该项目已签出给在其工作站上进行最新构建的用户

如果使用“从项目中排除文件夹”选项，将导致编译器抛出“未找到引用”错误

在我的解决方案结构中，类库项目使用“addreference”命令创建对第三方DLL的引用。然后，我在我的ASP、NET网站和web服务项目（使用网站项目模板）中为类库设置项目引用。因为类库依赖于第三方DLL，所以它们被复制到\bin文件夹中

---

如何通过VSS UI将文件设置为只读？

我知道这不是重点，但既然您暗示您对VSS不满意，但他们不会为另一个文件付费，为什么不使用SVN？我是说，还不错。。。在你的价格清单上（按舒适度降低的顺序）“SVN”、“被踢到坚果里去”，VSS。重点是Bill K……我对VSS有很多头疼的地方，它是不真实的。当我们有多余的硬币时，我会尝试推SVN。这是一个金钱上的决定…SVN是免费的，与VSS对您的成本相同。当我有一些停机时间时，我会调查SVN。感谢您的建议。我刚刚检查了每个项目的\bin文件夹中每个公共库DLL的“修改日期”，它们与每个开发人员工作站上安装的版本不同。可能不是这样。我认为修改的日期只显示从VSS本地复制它们的时间，所以这总是不同的。这些DLL是您自己的项目还是第三方DLL？它们是ActiveReports还是Log4Net？我们有自己的DLL，但它们是此解决方案之外的独立项目，因此我猜它们将被视为第三方DLL。不，它们不是ActiveReports或Log4Net。另一件要做的事情是严格执行每个人在每台机器上的同一位置检查内容的策略。如果不同的开发人员对VSS中的同一文件有不同的绝对路径，则可能会出现此问题。换句话说，如果一个开发人员在“c:\Projects\OurApplication”中拥有所有内容，而另一个开发人员在“c:\Program Files\Visual Studio 2005\Projects\OurApplication”中签出内容，VSS将不喜欢它。我用其他信息更新了我的原始帖子。如果每次都正确地将文件复制到bin文件夹，我建议从VSS中删除bin文件夹。这应该解决这个问题。