Odtnhj

I have a solution containing several projects. Let's say PackageA and PackageB, where PackageB depends on PackageA with a ProjectReference.

Each project is set to also output a NuGet package on build. This process itself works perfectly but I am unable to specify a package version-range for individual builds.
E.g. I'd like to restrict PackageB to only refer to PackageA version 1.0.* (patch steps).

<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="..PackageAPackageA.csproj" />
 </ItemGroup>
</Project>

MSBuild seems to ignore any Version="1.0.*" or AllowVersion="1.0.*" arguments within the ProjectReference tag.

Is there a possibility to specify a version range without breaking the ProjectReference or using PackageReference?

As far as i know it's not possible with ProjectReference, however there are some open issues in this topic on Github, so it might happen that they will implement it sometime.

But for now this functionality is only enabled on PackageReference. Docs.

Well let's think that through shall we? The project may have a version number embedded in in it somewhere, but it's likely to be the latest or previous version, which might not even build, and there's no guarantee that a subsequent build step won't update that value. The point at which a build system produces a versioned artifact is near the end of the build, usually the last step, which is normally the packaging or publishing step.

If your project must limit version ranges for any of its dependencies, it should take dependencies on other packages, not the projects that build them. This provides a natural asynchronous set of workflows to feed into a single product.

If you want the convenience of having dependencies built to their latest, then you must keep all the projects in sync with each other wrt compatibility. Project dependencies really only make sense for developer builds, not CI builds.

One thing you should never do, is produce two different packages with the same version numbers. Visual Studio projects are broken by design in the area of versioning, as they default to using a static version string that must be set prior to the build. If you happen to forget to bump that number, you will violate this semantic versioning rule.

Even if the Nuget/VS devs give you what you are asking for, it's not a good solution. What if the the currently checked out project is for a version outside of the specified range? Assuming the devs can figure out what code to check-out of revision control, is that really what you want to happen on your dev box? Any solution they come up with will be complex and prone to errors. Even if you've got the version checked-out, Nuget can't know you didn't make a breaking change to it.

It's better to run independent pipelines of code, review, build, package, test and publish, using only published packages as dependencies.