0

我用 C# 编写了一个 DLL 库,其中包含一个用于通信和操作我们产品的 API。我希望我们团队中的 QA 人员使用它在 .NET 环境中构建测试工具。与封装原则相反(有人可能会建议...),我希望 QA 人员能够看到 DLL 中 API 方法的实际实现(例如,当他们单击“转到定义”时) Visual Studio),而不仅仅是从元数据中查看声明/注释。

我不希望他们能够更改实际的 DLL,也不希望他们每次构建新项目时都构建 DLL,所以我不能简单地将库项目添加到他们的 VS 解决方案中。

我想到的一种理论方法是将库项目作为只读方式添加到他们的每个 VS 解决方案中(如果可能的话?),并指示他们永远不要构建它(只构建他们自己的新项目)甚至锁定它从建筑(如果可能的话?)。问题是,理想情况下,我希望他们能够以某种方式按下一个按钮,将其 VS 解决方案中的库项目更新为版本控制系统(我正在使用 Tortoise SVN)的最新版本,以及更新的(内置)DLL 文件(将 DLL 文件更新到他们的解决方案文件夹很容易,甚至可以在一个简单的批处理文件中完成,但我不确定如何自己更新项目文件......)。

当然,我希望在某种模板中包含以上所有内容,以便开发新的 QA 工具的准备工作变得快速而简单。

我发现这个问题很难表述(我希望我足够清楚),但我确信这是在团队中工作时很常见的问题(我不习惯)。谁能帮我理解处理这个问题的正确方法?

4

1 回答 1

0

这似乎是源服务器的工作。显然(尽管我自己没有个人经验)这些工具已经可以用来对抗颠覆。这似乎比让他们都保留源文件的工作副本(甚至是只读副本)更好。

补充说明:上面的链接描述了作者使用 perforce 实现的源服务器,而不是 subversion,但是您应该能够找到其他链接(比如这个,也许更好的链接)特别讨论 subversion。

于 2012-06-13T16:02:04.073 回答