SDK writes package version to deps file in place of assembly version for project references

[ericstj]

Describe the bug

The deps file is meant to contain AssemblyVersion and FileVersion for runtime files. This is used by the host when deciding if the assembly provided by the application is newer than one provided by the shared framework.

The SDK does this correctly for nuget packages and binary references, but writes the wrong value for project references. For project references you can see it will write the package version instead. This is because it's misusing the library version here:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/DependencyContextBuilder.cs

Line 536 in a4e5d12

library.Version.ToString(),

To Reproduce

Try the repro: deps-assemblyversion-projectreference.zip

It prints all the assembly version info from the deps, you'll see:

File(AssemblyVersion)
test.dll()
Microsoft.Extensions.DependencyModel.dll(8.0.0.2)
wb.dll(0.0.0-this-is-a-package-version-not-an-assembly-version)
System.Private.CoreLib.dll(9.0.0.0)
Microsoft.VisualBasic.dll(10.0.0.0)
Microsoft.Win32.Primitives.dll(9.0.0.0)
mscorlib.dll(4.0.0.0)
netstandard.dll(2.1.0.0)
System.AppContext.dll(9.0.0.0)
...

Note the 0.0.0-this-is-a-package-version-not-an-assembly-version that's a problem.

This is particularly a problem for the WPF repo which is trying to test and needs to replace the windowsbase.dll from dotnet/runtime with their real copy, but could be a problem for anyone trying to use ProjectReferences to replace framework assemblies (common for folks testing the frameworks).

The fix is to read the assembly version just as is done for other files (and the file version) or pull it from the reference metadata (EG: FusionName msbuild metadata).

[baronfel]

@ericstj is this something that you'd want us to fix forward, or do we need to take care of this in already-released versions too?

[ericstj]

I think it's fine to just do it in the latest version. The customers of this are us so I suspect it's fine to just have in latest. I know @JeremyKuhne needs this - it's possible @buyaa-n might need it for the fuzz testing work she's doing as well.

For anyone hitting this the workaround is to make the project sets a PackageVersion that matches its AssemblyVersion -- of course that won't work if the project actually needs to produce a package (like System.Text.Json, for example).

[ViktorHofer]

This affects dotnet/runtime#109852 which is failing because the vstest testhost (used by one of the host tests) doesn't upgrade to the latest STJ in the app output directory because the version in the deps.json file is 10.0.0-dev instead of 10.0.0.0. When I change the version to the latter (or even just 10.0.0 without the last digit) the newer STJ gets successfully loaded.

[joeloff]

I've started investigating this, will discuss more in triage on Tuesday

[ViktorHofer]

@joeloff kindly asking for an update