我在C＃中编写了一个DLL库，它包含一个用于通信和操作我们产品的API。我希望我们团队中的QA人员可以使用它在.NET环境中构建测试工具。与封装原则相反（人们可能建议......），我希望QA人能够看到DLL中API方法的实际实现（例如，当他们点击“转到定义”时Visual Studio）而不是仅仅从元数据中看到声明/注释。
我不希望他们能够更改实际的DLL，我不希望他们每次构建新项目时都构建DLL，因此我不能简单地将库项目添加到他们的VS解决方案中
我想到的一种理论方法是将库项目添加到每个VS解决方案中作为只读（如果可能的话？）并指示他们永远不要构建它（只构建自己的新项目）或者甚至将它从建筑物中锁定（如果可能的话？）。问题是，理想情况下，我希望他们能够将VS解决方案中的库项目更新为版本控制系统的最新版本（我正在使用Tortoise SVN），只需按一下按钮，同时更新（内置）DLL文件（将DLL文件更新到他们的解决方案文件夹很简单，甚至可以在一个简单的批处理文件中完成，但我不知道如何自己更新项目文件......）。
当然，我想在某种模板中使用上述所有内容，以便开发新QA工具的准备工作快速而简单。
我发现这个问题难以制定（我希望我足够清楚），但我确信这在团队工作时是一个非常普遍的问题（我不习惯）。任何人都可以帮我理解处理这个问题的正确方法吗？
答案 0 :(得分：0)
这似乎是source server的工作。显然（虽然我自己没有亲身经历）这些工具已经在那里反对颠覆。这似乎是一个更好的选择，而不是让它们都保留源文件的工作副本（甚至是只读的）。
补充说明：上面的链接描述了作者使用perforce而不是颠覆的源服务器的实现，但你应该能够找到其他链接（如this one，或许更好的链接），尤其是讨论subversion。