我们使用Team Foundation Server并拥有大量ASP.NET Web应用程序项目。每个Web应用程序都使用我们内部开发的自定义内容管理系统。 CMS本身就是一个ASP.NET Web应用程序。
部署后，CMS驻留在子目录中，例如“/ Admin”。 CMS由.aspx和ascx文件组成，相应的程序集当然放在bin中。
目前，CMS文件分别存在于源代码管理中的每个Web App。换句话说，每个依赖于CMS的Web应用程序中都存在“Admin”文件夹。这带来了明显的挑战，因为必须将对CMS的更新分发到每个依赖站点。我的工作是自动化/简化流程。
我们目前不执行任何自动构建。我对TFS中的源代码控制分支知识有限，我不确定它是否适用于这种情况。确保依赖项目从CMS项目接收最新程序集和标记的最佳方法是什么？提前谢谢。
听起来像＃2（来自'bamboo）是我追求的解决方案。鉴于共享代码已经存在于每个单独的项目中，您是否可以简要描述我将进行“分支/共享”CMS的过程？此外，值得注意的是，我不希望.cs文件传播到依赖项目，只是标记和程序集。这会改变策略吗？我应该首先在共享项目上创建构建事件，以将必需的文件复制到“Release”文件夹，然后分支Release文件夹吗？
答案 0 :(得分：7)
这是处理这种情况的两种流行方式。
将共享内容的TFS项目映射到每个应用程序工作区，然后在每个应用程序解决方案中包含共享项目。如果您希望所有团队/应用在构建时立即获得共享更改，请使用此方法，因为他们也会获得最新的共享内容。
将共享内容分支/共享到每个应用程序源代码控制树中。这在TFS中很容易做到。如果每个团队/应用程序想要控制何时获得最新的共享内容，这真的很好。这使得团队能够做好自己的事情，直到他们准备好整合共享的东西。
我通常更喜欢＃2。但这实际上取决于你需要/想要工作的具体细节。
答案 1 :(得分：0)
不确定TFS，但在大多数源代码管理系统中，您可以跨多个位置共享代码。对所有共享副本的更改都反映在所有副本中。在Visual Studio级别，它们将显示为独立的代码段。
您的每个网络应用（解决方案）都包含一个完全由共享代码组成的项目。通常，源代码是共享的，并成为构建过程的一部分。您可以共享生成的DLL，但大多数人不会提供控制DLL。
如果您没有共享部件的来源，可能在GAC中安装代码成为您创建共享部分的唯一选择。
答案 2 :(得分：0)
我们有一个与我们的几个项目一起使用的共享库。然后我们添加对共享库的引用，而不是实际的项目...
然后，您必须将引用的路径添加到构建xml，以便您的TFS服务器知道.dll所在的位置。每次为项目完成新构建时，它都会将最新版本的共享副本复制到项目的bin中。
我们所有的项目包括共享有4个分支：开发，集成，分期和生产。因此，当我们需要对共享库进行更改时，我们会在其开发分支中进行更改，因为它是孤立的。一旦我们满意，我们就会将变更合并到整合中我们构建共享集成，然后构建项目受变更影响的项目。这是我们开始测试其他应用程序以查看我们的更改是否导致任何错误。所以......