Unpin C# compiler version for repo #65317
Comments
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsWe're currently manually pinning the C# compiler version: Lines 55 to 56 in ce13258 as the version currently specified from dotnet/arcade is too old: We need to ensure the compiler bits are flowing appropriately and unpin.
|
dotnet-issue-labeler
bot
added
the
untriaged
jeffschwMSFT
removed
the
untriaged
|
@stephentoub @AaronRobinsonMSFT I see runtime has this pinned at: Line 52 in 85aa052 While arcade is at |
|
When we get the P7 SDK (which I'm upgrading Arcade to as we speak), we can unpin the compiler as it has the final version of 4.4.0-1.xxxxx. |
|
@jkoritzinsky since you are picking up the SDK upgrade after the arcade update, I'll assign this to you (and I'll link it in the PR). |
|
Based on #72145 (comment), we won't be able to unpin the C# compiler upgrade just yet. There's a bug in the P7 Roslyn that wasn't fixed until after P7 was built. |
|
This wasn't able to be fixed in #72145 because of a regression in Roslyn. We'll fix this before we release (likely after RC1). |
|
I don't think we'll be able to do this for the GA release. We recently accepted a change to update the Roslyn compiler for some ref-fields-related work (#75156) that only exists in the RC2 SDK. As a result, we'd need to either update to a nightly SDK for the release/7.0 branch or wait until after RC2 is finalized (so basically right before GA) to fix this. Additionally, there's another fix incoming from Roslyn that might be inserted into release/7.0, which would make it nearly impossible to fix this before GA without updating to a nightly SDK. @stephentoub are we okay with fixing this in servicing when we update the release/7.0 branch to build against the released 7.0.100 sdk? |
|
That's fine from my perspective. I just want to make sure we get onto the official train in both servicing and main as soon as we can so that we stay up-to-date with fixes/improvements that come into the compiler. I think we should also consider flowing compiler updates into dotnet/runtime separate from the rest of the SDK. Updating the compiler once every three months hasn't been a successful strategy. |
|
I fully agree with moving to flowing compiler updates to dotnet/runtime instead of using the LKG version from the SDK. I think that will provide us with a much better experience and it will keep us up to date. It will also help us avoid some of the source-build issues we’ve had this release. I’ll mark this as blocking servicing instead of blocking release. |
|
@jkoritzinsky, this can be closed now, right? |
|
We still need to fix this in 7.0.x. I'll add that to my to-do list for tomorrow. |
Unpin the C# compiler and build our shipping Roslyn components against the released Roslyn components for 7.0.100 instead of against pre-release builds. Also rename the MicrosoftCodeAnalysisVersion_4_X property now that it's pinned to Roslyn 4.4 forever. Fixes dotnet#65317
* Unpin the C# compiler version Unpin the C# compiler and build our shipping Roslyn components against the released Roslyn components for 7.0.100 instead of against pre-release builds. Also rename the MicrosoftCodeAnalysisVersion_4_X property now that it's pinned to Roslyn 4.4 forever. Fixes #65317 * Enable packaging servicing for updated OOB packages * Fixed the servicing versions * Remove packaging changes --------- Co-authored-by: Carlos Sanchez <[email protected]>
|
Fixed by #81247 |
ghost
locked as resolved and limited conversation to collaborators
We're currently manually pinning the C# compiler version:
runtime/eng/Versions.props
Lines 55 to 56 in ce13258
as the version currently specified from dotnet/arcade is too old:
We need to ensure the compiler bits are flowing appropriately and unpin.
The text was updated successfully, but these errors were encountered: