You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: documentation/general/decouple-vs-and-net-sdk.md
+15-6Lines changed: 15 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -119,12 +119,6 @@ Solutions that mix .NET SDK and Visual Studio projects will end up with multiple
119
119
120
120
The compiler will offer a property that allows SDK projects to use the MSBuild version of the compiler when being built with `msbuild`: `<RoslynCompilerType>Framework</RoslynCompilerType>`. This can be added to a `Directory.Build.props` file to impact the entire solution. This is not expected to be a common scenario but is available for customers who need it. This property will be ignored when using `dotnet build` as there is no way to fall back to the Visual Studio compiler in that scenario.
121
121
122
-
> [!NOTE]
123
-
> These values are recognized for property `RoslynCompilerType`:
124
-
> -`Core`: use the compiler that comes with the .NET SDK
125
-
> -`Framework`: use the compiler that comes with .NET Framework MSBuild
126
-
> -`FrameworkPackage`: download the Microsoft.Net.Sdk.Compilers.Toolset package which contains the .NET Framework compiler corresponding to the .NET SDK version
127
-
128
122
### .NET Framework based analyzers
129
123
130
124
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.
@@ -137,6 +131,20 @@ Today there is not a 100% reliable way to shutdown the VBCSCompiler process. The
137
131
138
132
To mitigate this we will be fixing the `build-server shutdown` command to be reliable across all the scenarios we care about. The details of this are captured in [issue 45956](https://github.com/dotnet/sdk/issues/45956).
139
133
134
+
## RoslynCompilerType
135
+
136
+
Based on the value of the `RoslynCompilerType` property, the SDK sets property `RoslynTasksAssembly` to a full path to a [Roslyn build task DLL][roslyn-build-task],
137
+
and the SDK targets use `$(RoslynTasksAssembly)` to load the build task.
138
+
139
+
The SDK also sets `RoslynTargetsPath` to the directory path of the roslyn tasks assembly. This property is used by some targets
140
+
but it should be avoided if possible because the tasks assembly name can change as well, not just the directory path.
141
+
142
+
These values are recognized for property `RoslynCompilerType`:
143
+
-`Core`: use the compiler that comes with the .NET SDK
144
+
-`Framework`: use the compiler that comes with .NET Framework MSBuild
145
+
-`FrameworkPackage`: download the Microsoft.Net.Sdk.Compilers.Toolset package which contains the .NET Framework compiler corresponding to the .NET SDK version
146
+
-`Custom`: the SDK will not override `RoslynTasksAssembly` - used for example by Microsoft.Net.Compilers.Toolset package which injects its own version of the build task
147
+
140
148
## Alternative
141
149
142
150
### Make the compiler in Visual Studio pluggable
@@ -189,6 +197,7 @@ There is only one version of the DevKit extension. It is released using the late
0 commit comments