Question

我有一个包含多个项目的解决方案。假设 PackageA 和 PackageB ，其中 PackageB 依赖于 PackageA 和 ProjectReference 。
每个项目都设置为在构建时也输出NuGet包。这个过程本身可以完美地运行，但是我无法为单个版本指定软件包的版本范围。例如。我想限制PackageB只引用PackageA版本1.0。*（补丁步骤）。

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup
    <TargetFrameworks>netstandard2.0;netcoreapp2.0;net46</TargetFrameworks>

    <RootNamespace>PackageB</RootNamespace>
    <Company>MyCompany</Company>
    <Authors>John Doe</Authors>
    <Description>This package depends on a specific version of PackageA.</Description>
    <Version>1.1.0</Version>
    <Copyright>Copyright © 2018 John Doe</Copyright>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\PackageA\PackageA.csproj" />
  </ItemGroup>
</Project>

MSBuild似乎忽略了 ProjectReference 标记内的任何 Version =“ 1.0。*” 或 AllowVersion =“ 1.0。*” 参数。
是否可以指定版本范围而不破坏 ProjectReference 或使用 PackageReference ？

Answer 1

据我所知，ProjectReference是不可能的，但是在Github上该主题中有一些开放的issues，所以他们可能会在某个时候实现它。

但是目前仅在PackageReference上启用了此功能。 Docs。

Answer 2

让我们考虑一下，我们应该经过吗？该项目可能在其中某个位置嵌入了版本号，但它可能是最新版本或以前的版本，甚至可能没有构建，也无法保证后续的构建步骤不会更新该值。构建系统生成版本化工件的时间点接近构建的结尾，通常是最后一步，通常是打包或发布步骤。

如果您的项目必须限制其任何依赖项的版本范围，则它应该依赖于其他软件包，而不是构建它们的项目。这提供了自然的异步工作流集，可将其馈入单个产品。

如果要使构建最新依赖关系的便利，则必须使所有项目彼此兼容并保持兼容性。项目依赖项实际上仅对开发人员构建有意义，而对CI构建则没有意义。

您永远不应该做的一件事就是产生两个具有相同版本号的不同软件包。 Visual Studio项目在版本控制方面被设计破坏，因为它们默认使用必须在构建之前设置的静态版本字符串。如果您碰巧忘记增加该数字，则会违反此语义版本控制规则。

即使Nuget / VS开发人员满足您的要求，也不是一个好的解决方案。如果当前签出的项目的版本超出指定范围怎么办？假设开发人员可以弄清楚要检查版本控制的哪些代码，那真的是您想在开发人员框中发生的事情吗？他们提出的任何解决方案都会很复杂，而且容易出错。即使已签出版本，Nuget也不知道您没有对其进行重大更改。

最好仅使用已发布的程序包作为依赖项来运行独立的代码管道，进行审查，构建，打包，测试和发布。

具有ProjectReference依赖关系的NuGet版本控制

2 个答案: