【问题标题】:'Sharing' class libraries in Visual Studio Online source controlVisual Studio Online 源代码管理中的“共享”类库
【发布时间】:2015-01-02 15:08:06
【问题描述】:

我们目前正在将源代码管理迁移到 Visual Studio Online。我们在旧系统(SourceGear Vault)中的一个功能是在解决方案之间共享项目。虽然这会在每个解决方案中为我们的框架项目创建一个文件夹,但它会在签入更改时使其保持最新状态。

这对我们很有用,因为它允许我们在所有使用它的解决方案中处理框架代码。我知道只编译 dll 并引用它们是更好的做法——在开发的这一点上,我们希望继续在使用这个核心框架的所有解决方案中拥有完整的代码访问和调试。

非常感谢任何帮助。

【问题讨论】:

  • 共享代码或固定永远不会在 TFVC 中实现,因为它被认为是一种不好的做法。
  • @MrHinsh:您能否详细说明为什么您认为共享代码(项目/程序集/库)是一种不好的做法。在我看来,至少共享代码的概念接近——如果不是的话——是 .NET Framework 本身的核心。见证 GAC。
  • GAC 中没有“代码”,它们是二进制文件。您应该编译您的代码,将其打包在 Nuget 中并在本地发布。然后依赖于那个包。创建一个 DevOps 管道来发布包,并且您有一个从签入到使用的自动提要。

标签: visual-studio tfs azure-devops


【解决方案1】:

您有几个同样有效的选项来处理共享项目:

  1. 从每个需要它的解决方案中引用相同的项目。

这使您可以在处理消费解决方案时完全控制共享项目的源代码,并且可以更轻松地进行调试。

这里的缺点是,如果解决方案 A 在星期四发布,那么维护和发布可能会变得更加棘手,但解决方案 B 将在 3 个月后发布,并且正处于一个巨大的重构周期中间,该周期显着修改了共享组件 X,并且共享组件 X 不够稳定,无法发布。

  1. 从内部 NuGet 存储库引用共享组件。

您设置了发布管道以将共享组件推送到 NuGet 作为发布过程的一部分(理想情况下,使用专门构建的发布管理工具......我在这里想到的是 Microsoft 发布管理)——您签入代码,项目就建好了。发布过程将其打包并作为“预发布”版本推送到 NuGet。您在需要最新版本的任何内容中引用最新版本。 如果需要引用已知良好的稳定版本,只需确保将项目配置为从 NuGet 提取特定版本。

完成后,您已经测试了共享的东西,并且您知道一切都很好,您批准了预发布版本,并将相同的二进制文件重新打包成“稳定”版本。

这里的缺点是对您的团队有一些额外的软件要求、配置和培训。这是我推荐的方法。

  1. 将二进制文件签入源代码管理。

我不推荐这个——你最终会膨胀你的源代码控制仓库(如果你使用 Git,这是一个明确声明的反模式——从不将二进制文件放入 Git ,它会导致长期严重的性能问题),并且永远不清楚哪些项目正在使用哪些程序集的哪些版本。这是维护的噩梦。

(1) 是最好的方法,如果您要同步发布所有内容并且不必担心维护单独的版本。

如果#1 为假,

(2) 是最好的方法。

(3) 是最好的方法,如果 #1 是错误的,并且你是一个时间旅行者,从 2006 年开始发帖。

【讨论】:

  • 我会说如果 #1 为真,那么将所有内容都放在解决方案上。如果你不能,那么#2是正确的答案......
【解决方案2】:

您是否考虑过使用 签入二进制文件或 NuGet 存储库 方法来实现 Symbol ServerSource Server 索引?这使您可以在调试时轻松返回源代码,并且它来自单个已知位置。 Visual Studio Online 和 Team Foundation Server 具有内置支持,可帮助您在构建过程中获取此设置。更多信息请参见此处的文章:Source Server and Symbol Server Support in Team Foundation Server and Visual Studio Online

【讨论】:

    【解决方案3】:

    感谢您的回复。我们实际上找到了一个适合我们的解决方案。当我们想要访问代码库时,我们将框架项目分支到实现项目中。如果不是,我们只使用 DLLs

    如果它随后被更改并签入到实施项目中,则可以在准备好后轻松地与其他框架分支合并。

    如果框架代码被大量开发,这可能不会很好,因为它现在只进行小的添加和调整,因此不会受到合并问题的困扰。

    【讨论】:

    • 我绝不会推荐这种方法,因为它会带来风险并影响质量。 Daniel Mann 在上面有正确的解决方案。您在这里所拥有的是针对不成熟的软件开发团队的临时工作。
    【解决方案4】:

    我必须同意大多数人的观点。我刚刚遇到了同样的问题。我在内部网络上实现了 Nuget Gallery 站点。实施起来很痛苦,但是一旦实施,它就很容易使用。我创建了一个实现 ADO.Net 和 EntityFramework 的类库项目。我将它捆绑到一个 NuGet 包中并将其上传到内部 NuGet 库。从那里我可以将包源添加到内部 NuGet 库并获取我上传的包。非常简单方便。

    我使用 Visual Studios 2017 设置了 NuGet 库。仅供参考:确保构建项目不是发布的一部分。它不会出现 ViewHelper.cshtml 错误。

    我使用 Visual Studios 2015 创建了项目。我以管理员身份运行命令提示符。我还必须将 NuGet.exe 文件复制到项目文件所在的目录中。

    查看以下链接了解更多信息。

    NuGet Gallery
    Hosting NuGet Gallery
    Create and Publish Package
    Creating a Package
    Create .Net Standard Package

    【讨论】:

      猜你喜欢
      • 2016-02-17
      • 2012-09-16
      • 1970-01-01
      • 1970-01-01
      • 2019-04-12
      • 2015-04-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多