代码之家 › 专栏 › 技术社区 › David

TFS项目能否相互引用?

shared-libraries tfs logging .net

David · 技术社区 · 14 年前

我最近开始在一个企业软件环境中工作,数百个不同的应用程序都被限制在各自的“筒仓”中。我的任务之一是尝试将事情标准化一点,第一个尝试将是标准的事件日志记录。目前,该公司的“标准”是“每个人都应该使用企业库进行日志记录”。实际上,这意味着从事不同项目的不同开发人员以不同的方式实现不同的日志记录,而且大多数时间都使用该库。

为此,我希望抽象出一个“公司标准”内部开发接口背后的实际测井工具。这样做的目的是将“标准”的焦点从实现工具转移到如何使用它。然后应用程序将使用内部库,而不关心幕后的工具(除了app.config部分,尽管我已经知道如何用log4net将其抽象出来)。

然而,我现在面临的一个问题是,所有这些应用程序都位于不同的TFS项目中。如果我创建了一个包含通用日志库的项目,那么其他项目是否可以引用它?我不想在每个项目之间分发库,因为它们很快就会失去同步。

如果TFS不能做到这一点,有人有其他建议吗?

5 回复 | 直到 14 年前

Jeff Bramwell 14 年前

TFS没有“共享”文件夹的概念(例如,与Visual SourceSafe类似)。工作区为您提供了一些灵活性,但一旦您尝试将同一个“共享”文件夹映射到多个项目,这种灵活性就会崩溃。只有几个选项可以解决您的具体情况:

将日志项目分支到每个需要它的团队项目中。当您对日志项目进行更改时,您需要 (一) 将日志项目更改合并到其分支到的每个项目(“推送”)或 (二) 请求使用日志记录更改的每个项目团队执行合并以获取最新的更改(“pull”)。
作为日志项目自动构建过程的一部分,将二进制文件发布到一个众所周知的位置。让每个需要日志记录二进制文件的项目设置一个预生成事件,将日志记录二进制文件的最新版本复制到它们的解决方案中 -或者-

可能还有其他的解决方案(通常是有的),但这就是我现在想到的全部。

希望这有帮助。

Ryan Cromwell 14 年前

杰夫的建议与我们的建议最接近。将内部api视为一个独立的团队项目,将其他项目作为客户机服务。这些项目提供了积压工作和发布周期。您可以拥有CI、Beta和Release版本。消费/消费项目所做的就是使用他们选择的构建,因为他们可以在自己的发布周期中适当地适应。因为您的TFS构建将推送到一个可用的放置位置,所以人们推送而不是您推送新版本。Pull是选择和 应该签入这些程序集并控制其版本 在消费项目中。这与使用真正的第三方程序集没有什么不同,事实上,您应该从同样的角度考虑这些问题。

chris 14 年前

Chris - Haddox Technologies 6 年前

2018年TFS :

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

    <ProjectReference Include="..\..\..\OtherTFSProject\src\ProjectDLL\ProjectDLL.csproj">
      <Project>{e8ed9a74-a9e9-47de-ab08-0b554a950606}</Project>
      <Name>ProjectDLL</Name>
    </ProjectReference>

在TFS2018中,创建建造 ,必须添加 工作区映射 “在” 获取来源 “生成到其他TFS项目存储库的阶段。我建议您在最低的文件夹中添加映射,因为生成将编译所选目录下的所有项目。在上面的例子中,你会选择

$\OtherTFSProject\src\ProjectDLL

-2

user1226687 10 年前

只需将所有核心库部署到GAC,这样应用程序就可以在每次更新时从GAC获得最新信息。您可以使用命令轻松地将GAC推送到所有“服务器/工作站”。请记住保持DLL中所有公共方法的签名不变,否则当您更改库时,开发人员将出错(如果他们引用该方法)