Microsoft.CodeAnalysis in 5.0.100 source-built Razor SDK is newer than Microsoft-built copy

[dagood]

Microsoft.CodeAnalysis is also shipped with the Microsoft-built SDK:

$ tar tf ~/downloads/dotnet-sdk-5.0.100-linux-x64.tar.gz | grep Microsoft.CodeAnalysis.dll
./sdk/5.0.100/Sdks/Microsoft.NET.Sdk.Razor/tools/Microsoft.CodeAnalysis.dll
./sdk/5.0.100/Roslyn/bincore/Microsoft.CodeAnalysis.dll

I can't see the version of the bincore dll, but the Razor/tools version seems to be 3.7.0 (instead of 3.8.0) 😞

$ exiftool ./sdk/5.0.100/Sdks/Microsoft.NET.Sdk.Razor/tools/Microsoft.CodeAnalysis.dll | grep -i version
ExifTool Version Number         : 12.00
Linker Version                  : 48.0
OS Version                      : 4.0
Image Version                   : 0.0
Subsystem Version               : 4.0
File Version Number             : 3.700.20.37502
Product Version Number          : 0.0.0.0
File Version                    : 3.700.20.37502
Product Version                 : 3.7.0-6.20375.2+34202cc2f3e869fd70a26d8237f4552cf9e192cf
Assembly Version                : 3.7.0.0

Originally posted by @omajid in #1849 (comment)

(In the source-built SDK, Roslyn is 3.8.0 including in Sdks/Microsoft.NET.Sdk.Razor/tools.)

[dagood]

Assuming we're building 3.8.0 for some valid reason, this could mean the Microsoft SDK is incoherent. It might be fine for us to replace 3.7.0 with 3.8.0 in this case. But maybe we don't have a valid reason for 3.8.0?

[dagood]

Actually, directly inspecting all Microsoft.CodeAnalysis.dll files present shows that the SDK has incoherent versions:

#> 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

[dagood]

@JunTaoLuo, do you know if it's ok for source-build to use a 3.8.0 version at ./sdk/5.0.100/Sdks/Microsoft.NET.Sdk.Razor/tools/Microsoft.CodeAnalysis.dll rather than 3.7.0? Is the incoherency in Microsoft.NET.Sdk.Razor expected?

Is this something that should be fixed in 5.0 servicing in the Microsoft build to make it more coherent?

[dagood]

@mmitche, maybe you have some broader context over whether that incoherency is expected in the 5.0 SDK, if it's ok for source-build to use 3.8.0 in both cases?

[dagood]

Triage: @JunTaoLuo, @mmitche, any thoughts on this?

[dagood]

Filed dotnet/aspnetcore#28096 to figure out what the next steps are.

[dagood]

In dotnet/aspnetcore#28096 it's confirmed that using 3.8.0 in both places is fine. Closing.

There's a PR proposed for 5.0.1 to update the Microsoft build to use 3.8.0 in both places there, too.

In the future, when we start building multiple SDK bands, we may get incoherent again due to the nature of building an SDK tool inside a Runtime repo like aspnetcore. More details: dotnet/aspnetcore#28096 (comment)