-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Prefer compiler toolset package if installed over the default RoslynCompilerType=Core
logic
#48837
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
base: main
Are you sure you want to change the base?
Conversation
@jaredpar for a review, thanks |
<PropertyGroup Condition="'$(RoslynCompilerType)' == 'Core'"> | ||
<!-- If Microsoft.Net.Compilers.Toolset package is referenced (which we can tell by RoslynTasksAssembly being non-empty), | ||
don't overwrite target paths - the toolset package should always take precedence. --> | ||
<PropertyGroup Condition="'$(RoslynCompilerType)' == 'Core' and '$(RoslynTasksAssembly)' == ''"> |
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.
In this new world though do we still want to keep preferring this package? Instead should we consider simplifying by saying that we only support Microsoft.Net.Sdk.Compilers.Toolset? Customers who previously used MS.Net.Compilers.Toolset can use the SDK version and then just control the version?
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.
The Sdk toolset is built from the sdk repo though, so we couldn't quickly create a toolset package (e.g., to ship hotfixes) from roslyn, we would need to insert to sdk first (with one more hop through vmr nowadays).
Also the Sdk toolset is framework only I think.
This PR is adding compiler toolset package tests and fixing one bug here in sdk and another bug fix should flow here from roslyn (the tests verify both fixes).