C# 不断增长的.NET项目的管理和结构

我们正在为公司内部使用的测试自动化构建一个.NET软件平台

应用程序由GUI（WinForms）组件和各种动态加载到其中以执行的“操作”组成

大约有100个行动项目正在进行中，而且这个数字还在增加。 其中一些项目与其他项目相互依赖，等等

加载的所有操作都必须针对各种活动引用我们的“SDK”dll（结果到主应用程序、日志等）

通过这一相对简单的设计，我们面临着一些我们希望以最佳方式解决的管理决策：

操作（“插件”）应该引用我们的SDK项目输出，还是它的某个已知稳定版本？ 例如，在开发大型应用程序时（仅以MS Office为例），并非所有团队都能自然地使用所有组件的源代码 对于这种情况，最好的解决方案是什么？为什么

如何正确地验证所有需要的依赖项（例如第三方库）是否确实从正确的位置获取

---

在管理多个相互关联的项目的场景中，常见的做法是什么？有什么建议吗？

这是一个没有明确答案的问题，但是

你可以走两条路。强耦合系统或松散耦合系统

对于强耦合系统，我可以为二进制文件推荐两个目录：第三方目录和一个包含公司构建的DLL的目录，其他开发人员可以参考。第三方DLL（公司之外）应位于源代码管理中，以便所有开发人员从同一位置引用相同版本的第三方DLL，从而避免开发人员机器不一致以及在每台机器上安装第三方软件的问题。内部DLL不应在源代码管理中引用，而应通过自动构建批处理文件或类似文件在每台开发人员机器上构建。在buildpost步骤中，您可以将它们全部复制到同一目录，只要开发人员获得最新的源代码管理和构建，您公司内的每个人都有相同的DLL

例如，获取最新版本、生成（使用批处理文件生成所需的所有项目），然后作为生成后步骤将输出复制到common。现在，您的所有其他项目都可以从同一位置引用通用的compnay DLL和第三方DLL，并且每个项目都是一致的

问题在于，引用是强耦合的，因此，如果没有正确沟通，更改有时可能会有问题

松散耦合的系统使用一个框架，如MEF（托管可扩展性框架）和您的组件引用“契约DLL”，它们定义了组件的接口。项目引用接口或契约DLL，并不真正关心实现，然后MEF为您管理插件

在本例中，您引用的是接口DLL，而不是实现的实际DLL

例如，假设我有一个名为ILog的接口和一个名为LogMessage的方法

private ILog _logger;
_logger.LogMessage();

因此，在强耦合的情况下：Action.DLL直接引用Logger.DLL

在松散耦合的情况下，Action.DLL引用ILog.DLL（只是接口）。Logger.DLL实现ILog.DLL。但是Action.DLL没有直接引用Logger.DLL

现在我可以有任意数量的DLL实现ILog接口，但Action.DLL不直接引用它们。这很酷，而且是MEF和松耦合的一个更令人兴奋的特性，即不具有依赖性的能力

选择哪种方式都是可以接受的，我认为松散耦合的想法最适合您的场景，因为团队只需要了解合同和实际实现

---

我不会有一个庞大的契约DLL，我会尝试将接口分成逻辑分组。例如，日志记录似乎是一种实用类型的干扰，因此我将创建一个带有ILog接口的实用契约DLL。它是如何分割的取决于你想做什么。或者每个接口都可以是契约DLL，但这可能有点极端。

这是一个有点复杂的主题，尤其是在.NET领域。我不知道什么是“最佳”解决方案，但我将解释我们如何管理它；也许你会觉得它对你自己有用

这允许您构建包含大量链接项目的大型系统，但会带来许多复杂性问题。我认为，任何此类解决方案都会如此

第一：物理结构（我们使用SVN）

• 每个项目都有一个源代码管理根目录
• 每个项目都有自己的主干、分支和标记
• 主干文件夹有一个版本化的\src和\build文件夹，以及一个未版本化的\lib文件夹 \lib文件夹包含要引用的二进制文件。 这些二进制文件可以是第三方库或您需要链接到的其他项目（例如，您的SDK）。\lib下的所有二进制文件都来自企业常春藤存储库（请参阅）。这些天来，在.NET的土地上有很多的移动，所以你也可以查看一下

versioned\build文件夹包含生成脚本，例如从ivy获取二进制文件、将项目发布到ivy或编译每个项目。当您希望将持续集成服务器指向每个项目时，它们也会派上用场

第二：定义依赖项的来源

答：它们来自您的常春藤存储库（它可以像网络共享文件系统一样简单）。 您已经创建了存储库，因此可以控制其内容。 对安装在GAC中的第三方二进制文件要非常小心。VisualStudio在处理这一问题上是一个难题

具体而言：

如何正确验证所有需要的 依赖关系（第3页）