Decoupling Visual Studio and the .NET SDK #46477
Conversation
dotnet-issue-labeler
bot
added
Area-Infrastructure
untriaged
| - **analyzers**: this document will use analyzers to refer to both analyzers and generators. | ||
| - **torn state**: when the .NET SDK and Visual Studio are not in sync. | ||
| - **.NET SDK project**: a project that uses the .NET SDK project format. | ||
| - **anaylzers**: refer to both analyzers and generators unless otherwise specified. |
There was a problem hiding this comment.
| - **anaylzers**: refer to both analyzers and generators unless otherwise specified. | |
| - **analyzers**: refer to both analyzers and generators unless otherwise specified. |
There was a problem hiding this comment.
Duplicated with line 17 (and spelled correctly there).
| Design Goals: | ||
|
|
||
| 1. **Consistent Build Experiences**: The `msbuild` and `dotnet build` command line build experience for a solution should be functionally equivalent. | ||
| 2. **Independent Design Time Behavior**: Visual Studio's design-time experience should be independent of the .NET SDK used by the solution. |
There was a problem hiding this comment.
My first reaction to this is "wait, what parts of design time behavior?"
There was a problem hiding this comment.
Ah, later I see you're focusing on Roslyn. That definitely makes sense, it just set off my radar because DTB targets must intermix with SDK stuff.
There was a problem hiding this comment.
I should change this section though to say largely or ideally. It's going to be impossible for DTB to be separated but we should separate the parts that we can.
|
|
||
| When building .NET SDK projects, `msbuild` will load tasks from the .NET SDK instead of Visual Studio. Specifically it will load the Roslyn compiler task from the .NET SDK. That task will then function the same as it does when launched from `dotnet build`. | ||
|
|
||
| To facilitate tasks from the .NET SDK launching .NET Core based processes, the `msbuild` host will [set the environment variable][dotnet-host-path] `DOTNET_HOST_PATH`. This will point to the same .NET Core host that the .NET SDK uses. This will allow tasks to launch .NET Core based processes with the same behavior as the .NET SDK would. |
There was a problem hiding this comment.
Note this isn't what @surayya-MS implemented; instead it sets a property.
There was a problem hiding this comment.
Will update. Either works for us.
|
|
||
| Solutions that mix .NET SDK and Visual Studio projects will end up with multiple compiler servers running. This is a result of the .NET SDK projects using the compiler from the .NET SDK and non-SDK projects using the compiler from Visual Studio. There is nothing functionally wrong with this but it's possible customers will notice this and ask questions about it. | ||
|
|
||
| The compiler will offer an MSBuild property that allows non-SDK projects to opt into using the .NET SDK based compiler: `<RoslynUseSdkCompiler>true</RoslynUseSdkCompiler>`. This can be added to a `Directory.Build.props` file to impact the entire solution. |
There was a problem hiding this comment.
I need more details on this--how's it resolve the SDK to find the compiler?
There was a problem hiding this comment.
Hmm ... maybe this is one where we need to go the opposite direction. Essentially say that if you want to use the same compiler over both you need to use the framework compiler. Either way we pick (use framework or use core) it's going to introduce tearing potential. It's a crutch so maybe go with the simpler option.
The other approach is that we have a NuGet package similar to what we have today that overrides with a single compiler. I'd prefer to start winding down that if possible.
There was a problem hiding this comment.
I think having a toggle in the SDK to go back to the VS-no-SDK behavior makes sense, we'll just have to think through the details on what it means.
| @@ -1,22 +1,36 @@ | |||
| # Torn .NET SDK | |||
| # Decoulping the .NET SDK and Visual Studio | |||
There was a problem hiding this comment.
| # Decoulping the .NET SDK and Visual Studio | |
| # Decoupling the .NET SDK and Visual Studio |
There was a problem hiding this comment.
Bah ... I didn't revert the changes to this doc in my final push. Ignore the changes here. This doc should be unchanged.
There was a problem hiding this comment.
Not sure I get the distinction between these docs now.
There was a problem hiding this comment.
The torn state doc is basically "how does .NET 9" work while the new one is "how does .NET 10 and beyond work". At some point this doc is deleted from the repo when .NET 9 and before go out of support.
There was a problem hiding this comment.
The torn state doc is basically "how does .NET 9" work while the new one is "how does .NET 10 and beyond work". At some point this doc is deleted from the repo when .NET 9 and before go out of support.
Consider writing this reasoning into the docs themselves.
| - **analyzers**: this document will use analyzers to refer to both analyzers and generators. | ||
| - **torn state**: when the .NET SDK and Visual Studio are not in sync. | ||
| - **.NET SDK project**: a project that uses the .NET SDK project format. | ||
| - **anaylzers**: refer to both analyzers and generators unless otherwise specified. |
There was a problem hiding this comment.
Duplicated with line 17 (and spelled correctly there).
|
|
||
| ### NuGet based analyzers | ||
|
|
||
| Analyzers which ship via NuGet will continue to following the existing [support policies][matrix-of-paine]. This means that they will either need to target a sufficiently old version of Roslyn or implement multi-targeting support to function in Visual Studio. |
There was a problem hiding this comment.
matrix-of-paine
Alright, this got me. Jeremy looked over and wondered what I was laughing at.
Co-authored-by: Fred Silberberg <[email protected]> Co-authored-by: Rainer Sigwald <[email protected]> Co-authored-by: Jeremy Koritzinsky <[email protected]>
There was a problem hiding this comment.
The torn state doc is basically "how does .NET 9" work while the new one is "how does .NET 10 and beyond work". At some point this doc is deleted from the repo when .NET 9 and before go out of support.
Consider writing this reasoning into the docs themselves.
|
|
||
| This means that CI systems are updated to the latest .NET SDK virtually as soon as we release them. However the version of Visual Studio is updated much later as CI images usually take several weeks to upgrade to a new Visual Studio version. This is a very common CI setup and means a significant number of our customers end up in a torn state for several weeks. | ||
|
|
||
| Teams also get into this state when the Visual Studio used for developement is older than the .NET SDK they are using: |
There was a problem hiding this comment.
| Teams also get into this state when the Visual Studio used for developement is older than the .NET SDK they are using: | |
| Teams also get into this state when the Visual Studio used for development is older than the .NET SDK they are using: |
|
|
||
| There are a few analyzers which are built against .NET Framework TFMs. That means when loaded in a .NET Core compiler it could lead to compatibility issues. This is not expected to be a significant issue as our processes have been pushing customers to target `netstandard` in analyzers for 5+ years. However it is possible that some customers will run into issues here. | ||
|
|
||
| For those customers we will offer a NuGet package or property that overrides the .NET Core compiler with a .NET Framework based on (at the same version). That will allow customers to upgrade to the new .NET SDK with minimal impact. |
There was a problem hiding this comment.
So this is the existing Microsoft.NET.Compilers.Framework.Toolset package?
|
|
||
| However, it is not our intent to support this in perpetuity. The documentation around this property will make it clear that by .NET 12 we will no longer support this property. By that time such analyzers will need to move to target `netstandard`. | ||
|
|
||
| ## Alternative |
There was a problem hiding this comment.
Another alternative: tell customers to avoid a torn state. For example, pin .NET SDK version in CI.
|
|
||
| This change will allow for `msbuild` to have a more consistent build experience with `dotnet build` for .NET SDK projects. It will have no impact on non-SDK projects as they will continue to use the compiler tasks that come from Visual Studio. | ||
|
|
||
| ## .NET SDK analyzers will load from Visual Studio |
There was a problem hiding this comment.
Should this heading have level 3 to be under the heading "Solution"?
| ## .NET SDK analyzers will load from Visual Studio | |
| ### .NET SDK analyzers will load from Visual Studio |
|
|
||
| - [Roslyn tracking issue for torn state](https://github.com/dotnet/roslyn/issues/72672) | ||
| - [MSBuild property for torn state detection](https://github.com/dotnet/installer/pull/19144) | ||
| - [Long term build-server shutdown issue](https://github.com/dotnet/msbuild/issues/10035) |
There was a problem hiding this comment.
Should build-server shutdown be mentioned as part of Solution or Issues?
|
|
||
| ## .NET SDK analyzers will load from Visual Studio | ||
|
|
||
| Analyzers and generators which ship in the .NET SDK box will change to having a copy checked into Visual Studio. This will occur as part of the .NET SDK insertion process. When .NET SDK based projects are loaded at design time, the Visual Studio copy of the analyzer will be loaded. |
There was a problem hiding this comment.
Should I merge the analyzer redirecting design doc #42437 so we can link it here?
|
|
||
| This also benefits analyzer and generator development models as they can now target the latest version of Roslyn. There is no more need to multi-target because the version of the compiler the analyzer will be used with is known at ship time for all core build scenarios. | ||
|
|
||
| This does mean that our design time experience can differ from our command line experience when customers are in a torn state. Specifically it's possible, even likely in some cases, that the diagnostics produced by design time builds will differ from command line builds. That is a trade off that we are willing to make for reliability. Customers who wish to have a consistent experience between design time should not operate in a torn state. |
There was a problem hiding this comment.
Is it worth providing a way for a user to use the .NET SDK still so that their command-line and VS builds are the same? At least if its opt-in we can have docs that explain why its a bad idea and not to ask for support when they've done this. I worry that preventing it all together only helps us and not our users.
Co-authored-by: Jan Jones <[email protected]>
No description provided.