Project Nuspec References

[gareth-horstmann]

I have been facing an issue with ProjectReference versions when packing nuget package over the last few days. After some investigation I've found that it seems to be a logged issue with NuGet github project but thought it may be worth posting this here to make this project aware of the discussions. The reason for notifying you is that I think the use case that GitVersion uses may be affected as well. Here are the related issues I found on the nuget github project:
NuGet/Home#5540
NuGet/Home#4337
NuGet/Home#5525
NuGet/Home#3953

Here is an outline of the issue:

Setup:

• I have two projects in the same solution, ProjectA and ProjectB
• Both projects are using the new VS2017 csproj format and both referencing GitVersionTask
• Both projects DO NOT have the version tag and am relying on GitVersionTask to set
• ProjectA reference ProjectB as a ProjectReference
• I have created a tag in my git history (4.3.4 - issue is the same for a release or prerelease version)

Expected behavior:

When I build the solution and pack the nuget packages (manually or as part of the build using msbuild), both projects produce a nupkg:

• ProjectA.4.3.6.nupkg
• ProjectB.4.3.6.nupkg
  Looking at the content for each package, The relevant assembly and packge versions are corrrect:
  
  

Unexpected behavior:

Looking at the dependencies in ProjectA.4.3.6.nupkg, ProjectB shows as >= 1.0.0. This causes an issue when resolving the dependency (especially using prerelease versions as we do in development as part of our workflow)

Cause:

Looking into the cause of the issue, it seems to be down to the way that a project reference is handled by visual studio. When ProjectB is added as a dependency to ProjectA, it will update the project.assets.json file automatically and will only use the value specified in the version project property. If I provide a value in the version property for ProjectB, it works as expected.

Something also worth noting is that if I add ProjectB as a PackageReference, the dependency version is correct

How do I think it relates to GitVersion:

Using GitVersionTask, I don't need to specify any version information and the task will auto-generate all of the version information for the assembly and the package (great :)), but how will this affect the project.assets.json file as this file is generated into the obj folder when the projects are saved, not at compile time. It may be that the GitVersionTask will need to also update the project.assets.json file? Or hook into any solutions the links above come up with?

I appreciate that this isn't directly a GitVersion issue but looking at some of the suggestions about using project variables (one suggestion was to add a PackageVersion to each ProjectReference) I think this may be relevant to know about new properties relating to versions so that the GitVersionTask can also update these values on compile.

Also, if anyone has a suggestion about how I can get around this for the moment - besides having to add a hard version each time - that would be great? I've tried setting the version parameter to the SemVer variable but as the project.assets.json file is generated before compiling, it doesn't have an effect.

Here is a test project showing the issue:
ProjectReference.zip

[mschofie]

My team hit the same issue. Here's what appears to be happening: When NuGet restores a "vs2017 light-weight" project it generates the <project name>.csproj.nuget.g.targets file that Imports GitVersionTask's targets file. But that Import is conditional on two things:

1. existence of the targets file, and,
2. whether ExcludeRestorePackageImports is not true.

When nuget restore is performed, it kicks off targets of the referenced project to discover the dependencies, but sets ExcludeRestorePackageImports to true when it does this. As a result, at restore time all project references don't get the GitVersionTask's targets file imported, so they all get the default version of 1.0.0. Which is wrong, and causes invalid NuGets to be produced.

I attempted to work-around by setting ExcludeRestorePackageImports. Before either the package import props or targets files are imported, Directory.Build.props is imported, so I set ExcludeRestorePackageImports to false there. Since ExcludeRestorePackageImports is a Global Property, you also have to set the TreatAsLocalProperty attribute on the Project element of the Directory.Build.props file. This works, but only if you nuget restore twice; with a clean 'intermediate' folder the package imports props/targets files aren't present when version is needed. Upon a second restore, the file was already laid out, and ExcludeRestorePackageImports has been stomped with false, so the targets are imported and the correct version is calculated for the ProjectReference.

So there's two problems;

1. NuGet doesn't provide a way for a package reference to avoid the ExcludeRestorePackageImports conditional on its package imports
2. NuGet doesn't write out the package import props or targets to hook up the build steps until /after/ the version has already been calculated.

I attempted a second work-around; Importing the package import targets directly from the packages folder by adding the following to my Directory.Build.props:

<Import Project="$(UserProfile)\.nuget\packages\gitversiontask\4.0.0-beta0012\buildMultiTargeting\GitVersionTask.targets" Condition=" '$(ExcludeRestorePackageImports)'=='true' " />

Obviously this assumes the location of the packages folder. Unfortunately, this fails if the package hasn't already been installed (but does work with a clean intermediate folder).

At this point I can't see a way to use a NuGet package to control the version of a project that is correctly reflected when that project is referenced by another.

[mschofie]

This is currently an issue tracked against NuGet: NuGet/Home#4790

@AArnott documents a workaround for his "NerdBank.GitVersioning" project under the issue tracking the problem; dotnet/Nerdbank.GitVersioning#113

[asbjornu]

Since a workaround exists and this is a bug in NuGet, I'm not sure there's much we can do in GitVersion? Can this be closed?

[gareth-horstmann]

According to the nuget 4790 issue this problem has been resolved in vs 15.6 but I tried on the latest version of visual studio (15.6.6 with nuget package manager 4.6.0) and the references are still incorrectly 1.0.0 if I use gitversion.

I tested using NerdBank.GitVersioning and the version is correctly being set in the nuspec files without any workarounds. I would normally switch over to something that works but we have integrated gitversions tag/branching strategy into our release cycle (which I prefer over NerdBanks strategy)

[gareth-horstmann]

For reference, here is the same project as I attached above (which still doesn't work) but with the updated NerdBank reference (which does work):
ProjectReference-NerdBank.zip

Building using vs 15.6.6 will generate the correct dependency versions

[AArnott]

Yes, VS 15.6 fixed the issue, but NB.GV still had a change to make to "opt in" to the new supported feature of 15.6.

GitVersion may still need to make a similar change.

[gareth-horstmann]

Thanks for confirming AArnot. I noticed you’d asked everyone to upgrade to the latest to get it working.

Based on there still needing a change and to respond to asbjornu, can we leave this open and find out if/when a fix can be applied to gitversion?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.