Fix casing of Microsoft.DotNet.ILCompiler for SB artifact bootstrapping #16626
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The casing of the
Microsoft.DotNet.ILCompilerpackage name is incorrect in the project configuration which handles source-build artifact bootstrapping. Because Linux is case-sensitive, this causes two versions of theMicrosoft.DotNet.ILCompilerto exist in thepreviously-source-builtlocal package feed:Microsoft.DotNet.ILCompiler: This is the original package that came from the source built artifacts tarball.Microsoft.DotNet.IlCompiler: This is the "bootstrapped" package that was pulled from nuget.org.The contents of these two packages are different. But from the perspective of NuGet, whose implementation is not case-sensitive with respect to NuGet package names, they have the same name and version. Because of non-deterministic behavior in NuGet you may get one package or the other, leading to unpredictable results in the build (see dotnet/runtime#83695 (comment) and dotnet/runtime#83695 (comment)).