If I have an application A with a ProjectReference to some assembly B versioned using Nerdbank.GitVersioning, the generated code in B sets AssemblyVersionAttribute and friends but these are only visible at compile-time and not at restore-time (restore instead always sees B's version as 1.0.0, and this is the version that is written in to the A's project.assets.json).

Is there a way to set the version correctly for the NuGet restore (as it is if we specify <VersionPrefix> directly in B's csproj instead of using GitVersioning)?

Some context for why this is a problem - we currently use source dependencies for almost all of our internal code, and are in the process of migrating to binary dependencies (with the help of GitVersioning for controlling our package versions). As such, during the transition period we are likely to have dependency trees with both ProjectReferences and PackageReferences to the same assemblies. In this case in a NuGet restore the version of the ProjectReference seems to take precedence over the version of the PackageReference, regardless of which is closer to the application in the dependency tree. Since this version is 1.0.0, this leads to version conflicts and build failures if the PackageReference version is > 1.0.0.

This is fairly easily resolved by adding a direct (rather than transitive) PackageReference from the application to the offending dependency, but I can imagine there are other potentially negative effects of NuGet seeing the wrong version during restore that I haven't come across yet.