如何对跨项目共享的资源进行版本控制
我们使用 Team Foundation Server 并拥有许多 ASP.NET Web 应用程序项目。 每个网络应用程序都使用我们内部开发的自定义内容管理系统。 CMS 本身就是一个 ASP.NET Web 应用程序。
部署后，CMS 驻留在子目录中，例如“/Admin”。 CMS由.aspx和ascx文件组成，相应的程序集当然放在bin中。
目前，源代码管理中每个 Web 应用程序的 CMS 文件单独存在。 换句话说，每个依赖于 CMS 的 Web 应用程序中都存在一个“Admin”文件夹。 这带来了明显的挑战，因为 CMS 的更新必须分发到每个相关站点。 我的工作是自动化/简化流程。
我们目前不执行任何自动化构建。 我对 TFS 中的源代码控制分支了解有限，并且不确定它是否适用于这种情况。 确保依赖项目从 CMS 项目接收最新的程序集和标记的最佳方法是什么？ 提前致谢。
听起来#2（来自“bamboo”）是我想要的解决方案。 鉴于共享代码已驻留在每个单独的项目中，您能否简要描述一下我将要执行的“分支/共享”CMS 的过程？ 另外，值得注意的是，我不希望 .cs 文件传播到依赖项目，而只是传播到标记和程序集。 这会改变策略吗？ 我是否应该首先在共享项目上创建构建事件以将必需的文件复制到“Release”文件夹，然后分支“Release”文件夹？
We use Team Foundation Server and have numerous ASP.NET Web Application Projects. Each of the Web Apps uses a custom content management system that we've developed in house. The CMS is itself, an ASP.NET web app.
When deployed, the CMS resides in a subdirectory, such as "/Admin". The CMS is comprised of .aspx and ascx files, and the corresponding assemblies are, of course, placed in the bin.
Presently, the CMS files exist separately for each Web App in source control. In other words, an "Admin" folder exists in each web application that depends on the CMS. This poses obvious challenges since updates to the CMS must be distributed to every dependent site. It's my job to automate/simplify the process.
We currently do not perform any automated builds. I have limited knowledge of source control branching in TFS and I'm not sure that it's applicable in this scenario. What is the best way to ensure that dependent projects receive the latest assemblies and markup from the CMS project? Thanks in advance.
It sounds like #2 (from 'bamboo) is the solution I'm after. Given that the shared code already resides in each individual project, can you briefly describe the process that I'll go through to "Branch/Share" the CMS? Also, it's worth noting that I do not want the .cs files propagated to the dependent projects, just the markup and assemblies. Does this change the strategy? Should I first create a build event on the shared project to copy the requisite files to a "Release" folder, and then branch the Release folder?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有几种流行的方法来处理这种情况。
将共享内容的 TFS 项目映射到每个应用程序工作区，然后将共享项目包含在每个应用程序解决方案中。 如果您希望所有团队/应用程序在构建时立即获取共享更改，请使用此方法，因为他们也会获取最新的共享内容。
将共享内容分支/共享到每个应用程序源代码控制树中。 这在 TFS 中很容易做到。 如果每个团队/应用程序都想控制何时获得最新的共享内容，这真的很好。 这使得团队能够做他们的事情，直到他们准备好集成共享的东西。
我一般总是更喜欢#2。 但这实际上取决于您需要/想要如何工作的具体情况。
The are a couple popular ways to handle this scenario.
Map the TFS project for the shared stuff to each applications workspace and then include the shared project in each applications solution. Use this method if you want all teams/apps to get the shared changes immediately when they build since they will get latest of the shared stuff as well.
Branch/Share the shared stuff into each applications source control tree. This is easy to do in TFS. This is really good if each team/app wants to control when they get the latest of the shared stuff. This keeps the teams being able to do their thing until they are ready to integrate the shared stuff.
I generally always prefer #2. But it really depends on the specifics of how you need/want to work.
不确定 TFS，但在大多数源代码控制系统中，您可以跨多个位置共享代码。 对任何共享副本的更改都会反映在所有共享副本中。 在 Visual Studio 级别，它们将显示为独立的代码片段。
您的每个 Web 应用程序（解决方案）都包含一个完全由共享代码组成的项目。 通常，源代码是共享的并成为构建过程的一部分。 您可以共享生成的 DLL，但大多数人不会对 DLL 进行源代码控制。
如果您没有共享部分的源代码，那么在 GAC 中安装代码可能会成为您创建共享部分的唯一选择。
Not sure about TFS, but in most source control systems, you can share code across multiple locations. Changes to any shared copy are reflected across all. At the Visual Studio level, they will appear as independent pieces of code.
Each of your web apps (solutions) contains a project that is comprised entirely of the shared code. Typically the source code is shared and becomes part of the build process. You could share the resulting DLL, but most people do not source control DLLs.
If you don't have source to the shared parts, likely installing the code in the GAC becomes your only option to create a shared piece.
我们有一个共享库，用于我们的几个项目。 然后，我们添加对共享库的引用，而不是实际项目...
然后，您必须将引用的路径添加到构建 xml，以便您的 TFS 服务器知道 .dll 的位置。 每次为项目完成新构建时，都会将最新版本的共享复制到项目的 bin 中。
我们所有的项目（包括 Shared）都有 4 个分支：开发、集成、登台和生产。 因此，当我们需要对共享库进行更改时，我们会在其开发分支中进行更改，因为它是隔离的。 一旦我们感到满意，我们就会将更改合并到集成中。 我们构建共享集成，然后构建受变更影响的项目。 这是我们开始测试其他应用程序以查看我们的更改是否导致任何错误的时候。 所以...
We have a shared library that is used with several of our projects. We then add a reference to the shared library, not the actual project...
You then have to add the referenced path to the build xml, so that your TFS server knows where the .dll is located. Each time a new build is done for the project it copies the most recent version of shared to the bin for the project.
All of our projects including Shared has 4 branches: Development, Integration, Staging, and Production. So when we need to make changes to our Shared library and we do it in its Development branch because its isolated. Once we are happy we merge our changes into integration. We build shared integration, and then we build what ever projects are affected by the change. This is when we start testing the other applications to see if our changes have caused any bugs. So...