logo标签列表

TFS项目可以相互引用吗？

.netloggingtfsshared-libraries
3
最近我开始在一个企业软件环境中工作，其中有数百个不同的应用程序都被限制在自己的“孤立空间”中。我的任务之一是尝试将事情标准化一些，第一次尝试将是标准事件记录。目前，公司的“标准”是“每个人都应该使用Enterprise Library进行日志记录”。实际上，这意味着不同的开发人员在不同的项目中以不同的方式实现不同的日志记录，并且大多数时间只使用该库。
为此，我希望将实际的日志记录工具抽象出来，在一个内部开发的“公司标准”接口后面。这样做的想法是将“标准”的焦点从实现工具转移到如何使用它。然后应用程序将使用内部库，而不会涉及背后的工具（除了可能的app.config部分，但我已经知道如何用log4net抽象它）。
然而，我现在面临的问题是所有这些应用程序都在单独的TFS项目中。如果我创建一个包含用于日志记录的公共库的项目，其他项目是否有办法引用它？我不想在每个项目中分发该库，因为它们很快就会失去同步。
如果TFS无法做到这一点，是否有其他建议？
可能是重复的问题 https://dev59.com/pU_Ta4cB1Zd3GeqPBHte#3390190 - Robaticus
@Robaticus：实际上我还没有找到那个，谢谢。乍一看，似乎那里的提问者使用TFS的方式与我们有些不同（更高级）。而且答案需要进行一些调查，因为这听起来（无论如何，快速浏览）像是一个可能会在我们的环境中变成维护噩梦的黑客攻击 :( - David
我是那里的回答者。我们到了两个解决方案。方案一是共享目录，方案二是所示方法。共享目录将在成功构建后从 TFS 更新。鉴于我们所学到的，当我们转移到2010年时，我们将调查共享目录方法。 - Robaticus
5个回答
5

Jeff的建议是我们推荐的最接近的。将内部API视为单独的团队项目，为其他项目提供服务。这些项目会提供待办事项和发布周期。您可以根据需要拥有CI、Beta和Release版本。消费/使用方项目然后使用他们选择的构建，以便在自己的发布周期中适当地进行调整。因为您的TFS构建将推送到可用的放置位置，人们会拉取而不是您推出新版本。拉取是选择并且那些程序集应该被签入和在使用方项目中进行版本控制。这与真正的第三方程序集没有区别，实际上您应该将其视为同样重要。

当使用应用程序需要或具备升级到内部程序集的新版本时，他们会拉取。

4
TFS没有“共享”文件夹的概念（例如我们在Visual SourceSafe中所拥有的）。工作区提供了一些灵活性，但是当您尝试将同一个“共享”文件夹映射到多个项目时，这种灵活性就会崩溃。以下是可能解决您特定情况的几个选项：
1. 将Logging项目分支到需要它的每个团队项目中。当您更改Logging项目时，您需要执行以下操作之一：A)将Logging项目更改合并到每个已分支到的项目中（“推送”），或B)要求使用Logging更改的每个项目团队执行合并以获取最新更改（“拉取”）。
2. 作为Logging项目自动化构建过程的一部分，将二进制文件发布到众所周知的位置。让每个需要Logging二进制文件的项目设置一个预构建事件，将最新版本的Logging二进制文件复制到其解决方案中 - 或者 - 而不是预构建事件，您还可以使自动化构建过程获取当前的Logging二进制文件并将其添加到解决方案中（根据需要执行签出/签入）。
可能还有其他解决方案（通常如此），但这就是我能想到的全部。
希望这有所帮助。
是的。在https://dev59.com/pU_Ta4cB1Zd3GeqPBHte#3390190中概述了这些选项。 - Robaticus
根据目前所有人的回复，这两个选项似乎是主要的选择。说实话，基于我在这个特定环境中的经验（与我之前工作的任何环境都非常不同），这两个选项听起来都很难在这里维护，并且随着时间的推移问题的可能性越来越大。这其中很多问题都基于我们的构建/部署过程非常混乱。（这是我正在努力解决的另一个问题。） - David
1
我认为将这个过程自动化会招致灾难。想象一下，你的API/工具被用于6个项目中，其中一个项目需要进行重大更改并实施。接下来，其他5个项目的构建就会“炸掉”。相反，像@RyanCromwell在他的回答中建议的那样，将所有依赖工具和API的版本化并放在源代码控制下。 - MrHinsh - Martin Hinshelwood
好的，我确实看到了那个观点。如果没有其他的事情，你们至少给了我一些见解/信息，让我带回我的团队考虑我们的选择。谢谢！ - David
1
仅仅是补充一下MrHinsh上面的评论...我同意。每当你在处理共享组件时，你必须始终考虑到兼容性问题。如果一个合同必须更改，最好以保持向后兼容的方式进行更改（例如重载方法、创建新接口等）。如果你没有在共享组件中实践这个概念，那么自动化这个过程不是一个好主意。 - Jeff Bramwell
0
我们成功做到的是创建了一个单独的TFS项目，其中包含像日志记录这样的库项目的解决方案。当我们构建这个解决方案时，我们将程序集部署到服务器上的共享驱动器中。当我们需要使用其中的一个库时，只需通过浏览服务器上的位置来添加对程序集的引用即可。如果您需要更改其中一个库，随时可以这样做。下次构建使用该程序集的任何项目时，它都会更新为新版本。
0

在 TFS 2018 中:

如果您的解决方案包含在另一个 TFS 2018 项目存储库下的项目 (.csproj)，您仍然可以通过以下两个步骤引用这些 DLL:

  1. 引用必须相对于相同的根目录。您的工作区源映射必须模仿源代码控制中的相同结构。即 (在 .csproj 文件中使用项目引用)
    <ProjectReference Include="..\..\..\OtherTFSProject\src\ProjectDLL\ProjectDLL.csproj">
      <Project>{e8ed9a74-a9e9-47de-ab08-0b554a950606}</Project>
      <Name>ProjectDLL</Name>
    </ProjectReference>

在TFS2018中，当您创建一个构建时，您必须在构建的"获取源代码"阶段中添加一个工作区映射到其他TFS项目存储库。我建议您将映射添加到最低级别的文件夹，因为构建将编译您选择的目录下的所有项目。在上面的示例中，您将选择：
$\OtherTFSProject\src\ProjectDLL

我还没有找到关于这个问题的在线文档。希望这可以帮到你！
-2
只需将所有核心库部署到GAC，这样应用程序在更新时就可以从GAC获取最新版本。您可以使用命令轻松地将GAC推送到所有“服务器/工作站”。只需记住保持DLL中所有公共方法的签名不变，否则开发人员在更改库（如果它们正在引用该方法）时会出现错误。
1
将GAC作为一个万能的部署工具就像使用全局变量作为万能的状态管理一样。此外，这并不能解决项目在源代码中相互引用的问题，它只是引入了一个外部手动步骤，在代码编译之前开发人员必须在他的工作站上安装更多的东西。 - David
请不要这样做。要么将公共库dll部署到每个人都可以引用的共享网络位置。或者，如果您关心版本控制，可以部署本地NuGet存储库并将功能打包在一个包中。在GAC中创建的混乱代码将无法管理。 - Adrian
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接