Microsoft.CodeAnalysis incoherency in 5.0.100 SDK between 3.8.0 and Microsoft.NET.Sdk.Razor's 3.7.0

Describe the bug

The 5.0.100 .NET SDK contains an incoherency between the “base” Roslyn version and the copy that’s redistributed by Microsoft.NET.Sdk.Razor:

• sdk/5.0.100/Roslyn/bincore/Microsoft.CodeAnalysis.dll: version 3.8.0
• sdk/5.0.100/Sdks/Microsoft.NET.Sdk.Razor/tools/Microsoft.CodeAnalysis.dll: version 3.7.0.

Is this something that needs to be fixed in the official build for 5.0.1 / 5.0.101 SDK? Or is this somehow intentional?

Source-build only builds one version of Roslyn: 3.8.0. Is it ok for source-build to put 3.8.0 in both places?

This started as https://github.com/dotnet/source-build/issues/1869. We need a response to make sure this doesn’t block 5.0.100 source-build.

@Pilchie /cc @JunTaoLuo @mmitche @dleeapho

To Reproduce

Download the 5.0.100 .NET SDK and examine these two DLLs with your favorite assembly version workflow. Or, follow these shell commands on Linux with PowerShell installed:

#> wget https://download.visualstudio.microsoft.com/download/pr/820db713-c9a5-466e-b72a-16f2f5ed00e2/628aa2a75f6aa270e77f4a83b3742fb8/dotnet-sdk-5.0.100-linux-x64.tar.gz
...
#> tar -xf dotnet-sdk-5.0.100-linux-x64.tar.gz
...
#> find . -iname 'Microsoft.CodeAnalysis.dll' -exec pwsh -c 'echo {}; [System.Reflection.AssemblyName]::GetAssemblyName("{}").Version.ToString()' \;
./sdk/5.0.100/Sdks/Microsoft.NET.Sdk.Razor/tools/Microsoft.CodeAnalysis.dll
3.7.0.0
./sdk/5.0.100/Roslyn/bincore/Microsoft.CodeAnalysis.dll
3.8.0.0

Further technical details

• ASP.NET Core version: 5.0.0
• .NET SDK version: 5.0.100

[pranavkm]

Yup, we should be safe to update the versions here. Razor requires referencing two different versions of Roslyn

• Razor compiler that ships as part of the SDK needs to reference the same version as the rest of the SDK
• Razor runtime compilation is shipped as a NuGet package and needs to reference a version of Roslyn that ships as a NuGet package. Roslyn doesn’t follow the runtime ship schedule and some amount of manual work is required to keep this updated.

In the AspNetCore-Tooling repo, these used two different version numbers. When we migrated to the AspNetCore repo, these numbers got squished together. @mmitche / @dotnet/aspnet-build could you help me with the gesture required to automate version updates for the package? At least for the first bit, we should be using the newest all the time.

[pranavkm]

Yup, that’s my plan. It’s the least spooky thing to do