2010-08-09 133 views
3

我最近开始在一个企业软件环境中工作,数百个不同的应用程序都被限制在自己的“孤岛”中。我的任务之一是尝试将事情标准化,第一次尝试将是标准事件日志记录。目前,该公司的“标准”是“每个人都应该使用企业库进行登录”。这实际上转化为什么,不同的开发人员在不同的项目中执行不同的日志记录,并且大多数时间使用该库。TFS项目可以相互引用吗?

为此,我期望在“公司标准”内部开发的接口背后提供实际的日志记录工具。这个想法是将“标准”的重点从实施工具中移开,并转移到如何使用它。然后,应用程序将使用内部库,而不关心幕后的工具(除了可能是app.config部分,尽管我已经知道如何用log4net将其抽象出来)。

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

如果TFS无法做到这一点,有没有人有任何其他建议?

+0

http://stackoverflow.com/questions/3385282/ best-practice-to-share-projects-between-solution-trees-msvs-2008-msvs-2010/3390190#3390190 – Robaticus 2010-08-09 19:52:14

+0

@Robaticus:我真的没有找到那个,谢谢。初看起来,那里的提问者使用的TFS与我们有些不同(更先进)。答案是需要进行一些调查,因为听起来(快速浏览)听起来有点像黑客,可能会变成我们环境的维护噩梦:( – David 2010-08-09 19:59:25

+0

我是那里的回应者,我们回到了两个解决方案之一是共享目录,解决方案2是所示的方法,在成功构建之后,共享目录将从TFS更新,根据我们所了解的情况,当我们移至2010年时,我们将调查共享目录方法 – Robaticus 2010-08-09 20:01:58

回答

4

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

  1. 将日志项目分支到每个需要它的团队项目。当您对日志记录项目进行更改时,您需要或者A)将日志记录项目更改合并到每个已分支到(“推送”)的项目或B)要求每个项目团队使用记录更改执行合并以获取最新更改(“拉”)。

  2. 作为日志记录项目的自动构建过程的一部分,将二进制文件发布到众所周知的位置。让每个需要记录二进制文件的项目都设置一个预生成事件,将最新版本的记录二进制文件复制到他们的解决方案- 或 -而不是预生成事件中,也可以让自动构建过程获取当前记录二进制文件并将其添加到解决方案(根据需要执行checkout/ins)。

可能还有其他的解决方案(通常有),但这就是所有这些想法。

希望这会有所帮助。

+0

是的。概述了这些选项http://stackoverflow.com/questions/3385282/best-practice-to-share-projects-between-solution-trees-msvs-2008-msvs-2010/3390190#3390190 – Robaticus 2010-08-09 20:02:51

+0

它会根据目前为止所有人的反馈,这两个都是主要的选择,我会诚实地说,这是基于我对这个特定环境的经验(这与我以前工作过的任何环境都非常不同) ,两种选择听起来就像他们在这里很难维护,随着时间的推移,问题的可能性越来越大。其中很大一部分是基于我们的构建/部署过程是_mess_的事实。 (还有别的我试图修复。) – David 2010-08-09 20:08:34

+1

我认为这是一个自动化过程引发的灾难。想象一下,你的API /工具在6个项目中使用,其中一个项目需要一个主要的支持并实现它。接下来构建5个其他项目去“kaboom”。取而代之的是,@RyanCromwell的所有依赖工具和API的版本控制和源代码控制在他的答案中都有所体现。 – 2010-08-10 08:52:12

0

我们成功的做法是用一个解决方案创建一个单独的TFS项目,该解决方案包含像日志这样的库的项目。当我们构建这个解决方案时,我们将程序集部署到服务器上的共享驱动器上。当我们需要使用这些库中的一个时,我们只需通过浏览到它在服务器上的位置来添加对程序集的引用。如果您需要对其中一个库进行更改,您可以随时进行更改。下一次使用该组件的项目中的一个将被更新为新版本。

5

杰夫的建议是最接近我们的建议。考虑内部API是一个独立的团队项目,作为客户为其他项目提供服务。那些项目会支持积压和发布周期。您可以根据需要制作CI,Beta和Release版本。消费/消费项目然后是使用他们选择的版本,因为他们可以在他们自己的发布周期中适当地适应。因为你的TFS版本会推到可用的放置位置,所以人们拉动而不是推送新版本。拉是选择和这些组件应该签入和版本控制在消费项目内的。这与真正的第三方装配没有什么不同,实际上你应该考虑这些。

当消费应用程序需要或带宽升级到较新版本的内部程序集时,它们会拉动。

-1

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

+1

将GAC用作全能部署线束就像使用全局变量作为全部状态管理一样。另外,这并不能解决源代码*中相互引用项目的问题,它只是引入了一个外部手动步骤,开发人员必须在代码甚至编译之前在他的工作站上安装更多的东西。 – David 2014-09-11 12:24:31

+0

请不要这样做。将公共库DLL部署到每个人都可以参考的共享网络位置。或者,如果您关心版本控制,请部署本地NuGet存储库并将功能包装在一个包中。您将在GAC中创建的泥球将无法管理。 – Adrian 2016-06-21 17:05:33

相关问题