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:

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).