命名空间结合 TFS/源代码控制解释
作为一家 ISV 公司，我们慢慢遇到了“构建代码”问题。我们主要使用Visual Studio 2008和2010 RC进行开发。语言 c# 和 vb.net。我们有自己的 Team Foundation Server，当然我们也使用源代码管理。 当我们开始基于.NET Framework进行开发时，我们也开始以原始的方式使用命名空间。随着我们“变得更加成熟”，我的意思是我们学会了使用命名空间，并且我们越来越多地构建代码，但仅限于解决方案范围。 现在，我们的 Source Safe 中有大约 100 个不同的项目和解决方案。我们意识到我们自己的许多类的编码非常冗余，我的意思是，在所有这些项目和解决方案中可以找到 Write2Log、GetExtensionFromFilename 或类似的函数 1 到 20 次。
所以我的想法是：
在源代码管理中创建一种根文件夹，并在该根下启动一个自己的命名空间层次结构，让我们将其命名为 CompanyName。 然后可以在 CompanyName.System.Logging 中找到 Write2Log 类。 每当我们创建新的解决方案或项目并且需要日志功能时，我们都会对该解决方案进行“命名空间”并将其相应地放置在 CompanyName 根文件夹下的某个位置。为了获得日志记录功能，我们将现有项目导入（添加）到 解决方案。 然后，可以将具有 write2log 类的 20 多个项目/解决方案维护在一个位置。
对于我的问题： - 命名空间和源代码控制的哲学是个好主意吗？ - 一定有一本好书解释命名空间与源代码管理相结合，是吗？有任何提示/方向/技巧吗？ - 您如何管理 50 多个项目？
As an ISV company we slowly run into the "structure your code"-issue. We mainly develop using Visual Studio 2008 and 2010 RC. Languages c# and vb.net. We have our own Team Foundation Server and of course we use Source Control.
When we started developing based on the .NET Framework, we also begun using Namespaces in a primitive way. With the time we 'became more mature', i mean we learned to use the namespaces and we structured the code more and more, but only in the solution scope.
Now we have about 100 different projects and solutions in our Source Safe. We realized that many of our own classes are coded very redundant, i mean, a Write2Log, GetExtensionFromFilename or similar Function can be found between one and 20 times in all these projects and solutions.
So my idea is:
Creating one single kind of root folder in Source Control and start an own namespace-hierarchy-structure below this root, let's name it CompanyName.
A Write2Log class would then be found in CompanyName.System.Logging.
Whenever we create a new solution or project and we need a log function, we will 'namespace' that solution and place it accordingly somewhere below the CompanyName root folder. To have the logging functionality we then import (add) the existing project to the
solution.
Those 20+ projects/solutions with the write2log class can then be maintained in one single place.
To my questions:
- is that a good idea, the philosophy of namespaces and source control?
- There must be a good book explaining the Namespaces combined with Source Control, yes? any hints/directions/tips?
- how do you manage your 50+ projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我们是这样做的（我们也是 ISV，并且我们使用 TFS）：
我们有一个所有产品都使用的内部框架。该框架包括数据访问层的基类、日志记录、实用功能、UI 控件等服务。
因此，我们的框架有一个团队项目：
Framework\v1.0\Main\Framework
（注意重复的“框架”，看起来很奇怪，但很重要）
然后我们为每个产品都有一个团队项目，并将框架分支到团队项目中：
ProductName\v1.0 \Main\ProductName
ProductName\v1.0\Main\Framework （从 \Framework\v1.0\main\Framework 分支，我们将此分支设置为只读）
“\Main\ProductName”下的任何代码" 可以引用 \Main\Framework 下的任何代码
此外，如果我们需要创建产品的工作分支，我们只需在“Main”处分支，如下所示：
ProductName\v1.0\WIP\MyBranch\ （从 Main 分支，其中 MyBranch == Main）
这给了我们两个非常酷的功能：
只要我将“Main”下面的所有内容都放在一起，我就可以创建分支而不会弄乱我的引用。这是因为 VS 将使用引用的相对路径，并且只要我将 Main 下面的所有内容放在一起（并且我不引用 main 之上的任何内容，相对路径保持不变。
如果我更新“真实”框架（在 \Framework\v1.0 下）），当我想要将这些框架更新合并到产品的代码库中时，我可以为每个产品进行选择。
（如果您使用共享库，这非常有用，因为它将共享框架的内部版本与产品的外部版本解耦）。如果您刚刚转向共享库，您将遇到的问题之一是“冲突”，即对共享代码的更改要求对产品代码进行更改以保持兼容性。通过对共享代码进行分支，您可以更新框架，而不会立即影响所有产品。
Here's how we do it (we're also an ISV, and we use TFS):
We have an in-house framework that all of our products use. The framework includes base classes for our Data Access Layer, services like logging, utility features, UI controls, etc).
So, we have a Team Project for our framework:
Framework\v1.0\Main\Framework
(note the repetition of "framework", looks weird, but it's important)
Then we have a Team Project for each product, and we branch the framwork into the team project:
ProductName\v1.0\Main\ProductName
ProductName\v1.0\Main\Framework (branched from \Framework\v1.0\main\Framework, we make this branch read-only)
any code under "\Main\ProductName" can reference any code under\Main\Framework
Further, if we need to create working branches of our product, we just branch at "Main" like so:
ProductName\v1.0\WIP\MyBranch\ (branched from Main, where MyBranch == Main)
That gives us 2 really cool features:
I can create branches without messing up my references as long as I keep everything below "Main" together. This is because VS will use relative paths to the references, and as long as I keep everything below Main together (and I do NOT reference anything "above" main, the relative paths remain intact.
If I update the "real" framework (under \Framework\v1.0)), I can choose for each product when I want to merge those framework updates into the product's code base.
(that's really useful if you use shared libraries, because it decouples internal releases of your shared framework from external releases of your products). If you are just moving to shared libraries, one of the problems you are going to encounter is "collisions", where a change to your shared code mandates changes to your product code in order to stay compatible. By branching your shared code, you can update your framework without immediately impacting all of your products at the same time.