Decoupling Visual Studio and the .NET SDK#46477
Conversation
ghost
added
documentation/general/torn-sdk.md
Outdated
| @@ -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.
|
|
||
| ### 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 <fred@silberberg.xyz> Co-authored-by: Rainer Sigwald <raines@microsoft.com> Co-authored-by: Jeremy Koritzinsky <jkoritzinsky@gmail.com>
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 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.
There was a problem hiding this comment.
We don't prevent it, we just say if you want tthe builds to be the same then use the .NTE SDK that comes with Visual Studio.
Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
|
Apologies for losing track of this PR for so long. Addressed feedback. |
Co-authored-by: Fred Silberberg <fred@silberberg.xyz> Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
6 participants
No description provided.