-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update CodeStyle/format/SDK versions #59903
Conversation
"allowPrerelease": true, | ||
"rollForward": "latestPatch" | ||
}, | ||
"tools": { | ||
"dotnet": "6.0.100", | ||
"dotnet": "6.0.200", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❔ Why update this instead of just updating to Microsoft.Net.Compilers.Toolset package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might be teaching me something. If we set the Toolset package version will the SDK pick that up and use those compilers for the build?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we set the Toolset package version will the SDK pick that up and use those compilers for the build?
Yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❔ Why update this instead of just updating to Microsoft.Net.Compilers.Toolset package?
This would also be a reasonable way of doing it. It seems also beneficial to move forward to stable SDKs as they come out (finding out earlier if there are issues adopting it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JoeRobich to verify the dotnet-format version matches the compiler version used by the build
Will this also allow us to use raw strings?
It looks like no. That only shipped in 17.2/.NET 7 preview 1. Should we move further forward now in order to get raw strings? |
My preference would be to move the toolset forward to get raw strings support (since we want to dogfood the upcoming IDE features), but not move the SDK more than necessary. |
We need to wait for 17.2p2 being made public before we can start dogfooding raw strings. |
I've made a calendar appointment to address this once that preview is released :) |
…ures/required-members * upstream/main: (78 commits) [main] Update dependencies from dotnet/roslyn (#59792) Annotate BreakpointSpans and fix NREs (#59846) Editor namespaces refactoring - part 1 (#59907) [main] Update dependencies from dotnet/source-build-externals (#59845) Update PublishData.json (#59952) ...and the comment Revert the last change in the compiler layer Force SVsExtensionManager to load before InProcComponent creation Handle nameof situation, moved logic back to workspaces layer Add back OmniSharpInlineHints (#59941) Initialize AsyncCompletionTracker in a fire-and-forget manner Try to load the extension manager from the main thread as well Use the correct GUID for SVsUserNotificationsService Update CodeStyle/format/SDK versions (#59903) Create attribute default arguments during binding (#59750) Undo refactoring part 2 Undo refactoring Move logic of symbol filtering to compiling layer. Refactoring Clean up diagnostic and solution crawler options - take 2 (#59233) Add quotes in string for clarity ...
…o enforce-setting * upstream/features/required-members: (78 commits) [main] Update dependencies from dotnet/roslyn (dotnet#59792) Annotate BreakpointSpans and fix NREs (dotnet#59846) Editor namespaces refactoring - part 1 (dotnet#59907) [main] Update dependencies from dotnet/source-build-externals (dotnet#59845) Update PublishData.json (dotnet#59952) ...and the comment Revert the last change in the compiler layer Force SVsExtensionManager to load before InProcComponent creation Handle nameof situation, moved logic back to workspaces layer Add back OmniSharpInlineHints (dotnet#59941) Initialize AsyncCompletionTracker in a fire-and-forget manner Try to load the extension manager from the main thread as well Use the correct GUID for SVsUserNotificationsService Update CodeStyle/format/SDK versions (dotnet#59903) Create attribute default arguments during binding (dotnet#59750) Undo refactoring part 2 Undo refactoring Move logic of symbol filtering to compiling layer. Refactoring Clean up diagnostic and solution crawler options - take 2 (dotnet#59233) Add quotes in string for clarity ...
Goal is to get us able to dogfood
!!
. Demo in #59904.