c# - 命名空间结合 TFS/Source Control 解释

Question

作为一家 ISV 公司，我们慢慢地遇到了“构建您的代码”的问题。我们主要使用 Visual Studio 2008 和 2010 RC 进行开发。语言 c# 和 vb.net。我们有自己的 Team Foundation Server，当然我们使用源代码管理。
当我们开始基于 .NET Framework 进行开发时，我们也开始以原始方式使用命名空间。随着我们“变得更加成熟”，我的意思是我们学会了使用命名空间并且我们越来越多地构建代码，但仅限于解决方案范围。
现在，我们的 Source Safe 中有大约 100 个不同的项目和解决方案。我们意识到我们自己的许多类的编码非常冗余，我的意思是，在所有这些项目和解决方案中，可以找到 1 到 20 次 Write2Log、GetExtensionFromFilename 或类似的函数。

所以我的想法是:

在源代码管理中创建一种单一的根文件夹，并在此根目录下启动一个自己的命名空间层次结构，我们将其命名为 CompanyName。
然后会在 CompanyName.System.Logging 中找到 Write2Log 类。
每当我们创建新的解决方案或项目并且需要日志功能时，我们都会将该解决方案“命名空间”并将其相应地放置在 CompanyName 根文件夹下方的某个位置。为了具有日志记录功能，我们然后将现有项目导入(添加)到
解决方案。
然后可以在一个地方维护 20 多个具有 write2log 类的项目/解决方案。

对于我的问题:
- 这是一个好主意，命名空间和源代码控制的哲学吗？
- 一定有一本解释命名空间与源代码控制相结合的好书，是吗？任何提示/方向/提示？
- 您如何管理 50 多个项目？

Answer 1

这是我们的操作方法(我们也是 ISV，我们使用 TFS):

我们有一个我们所有产品都使用的内部框架。该框架包括我们的数据访问层的基类、日志记录、实用功能、UI 控件等服务)。

所以，我们的框架有一个团队项目:
框架\v1.0\Main\Framework

(注意“框架”的重复，看起来很奇怪，但很重要)

然后我们为每个产品都有一个团队项目，我们将框架分支到团队项目中:

产品名称\v1.0\Main\产品名称

ProductName\v1.0\Main\Framework(从\Framework\v1.0\main\Framework 分支，我们将此分支设为只读)

"\Main\ProductName"下的任何代码都可以引用\Main\Framework 下的任何代码

此外，如果我们需要为我们的产品创建工作分支，我们只需在“Main”处进行分支，如下所示:

ProductName\v1.0\WIP\MyBranch\(从 Main 分支，其中 MyBranch == Main)

这为我们提供了 2 个非常酷的功能:

我可以创建分支而不会弄乱我的引用，只要我将所有内容都保留在“Main”之下。这是因为 VS 将使用引用的相对路径，并且只要我将所有低于 Main 的内容放在一起(并且我不引用“高于”main 的任何内容，相对路径将保持不变。

如果我更新“真正的”框架(在\Framework\v1.0 下)，我可以在我想将这些框架更新合并到产品的代码库中时为每个产品选择。

(如果您使用共享库，这真的很有用，因为它将共享框架的内部版本与产品的外部版本分离开来)。如果您只是转向共享库，您将遇到的问题之一是“冲突”，其中对共享代码的更改要求更改您的产品代码以保持兼容。通过分支您的共享代码，您可以更新您的框架，而不会立即同时影响您的所有产品。