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
.NET Standard msbuild tasks are problematic and just about everyone has converged on multi-targeting instead (including SDK and core nuget tasks). dotnet/msbuild#1309 is one example of the problems that can be hit. There are workarounds, but it is fragile.
Recently, the build task added a dependency on Pipes.AccessControl that is not part of the shared framework, so it needed to be included in the package. To do this, the netstandard1.3 was published dropping a bunch of other unnecessary dependencies next to the build tasks and breaking crossgen upon insertion in to the CLI.
Publishing a netstandard library is basically a broken scenario. See dotnet/sdk#1855 (comment), which goes on to discuss warnings/errors for this case. When you publish, you should really use a "runnable" TFM like net46 or netcoreapp2.0.
For now, CLI is deleting the extra assemblies to unblock the insertion, but this isn't sustainable because it's implemented with fragile wild-cards ("System.*", but not Pipes.AccessControl) that are subject to change at any time.
Assigning to @jaredpar as he asked me to do so offline.
The text was updated successfully, but these errors were encountered:
Changes our task to multi-target between net46 and netcoreapp2.0. This
matches how the rest of the SDK is deploying and makes for a smoother
integration into CLI.
context dotnet#24646
.NET Standard msbuild tasks are problematic and just about everyone has converged on multi-targeting instead (including SDK and core nuget tasks). dotnet/msbuild#1309 is one example of the problems that can be hit. There are workarounds, but it is fragile.
Recently, the build task added a dependency on Pipes.AccessControl that is not part of the shared framework, so it needed to be included in the package. To do this, the netstandard1.3 was published dropping a bunch of other unnecessary dependencies next to the build tasks and breaking crossgen upon insertion in to the CLI.
Publishing a netstandard library is basically a broken scenario. See dotnet/sdk#1855 (comment), which goes on to discuss warnings/errors for this case. When you publish, you should really use a "runnable" TFM like net46 or netcoreapp2.0.
For now, CLI is deleting the extra assemblies to unblock the insertion, but this isn't sustainable because it's implemented with fragile wild-cards ("System.*", but not Pipes.AccessControl) that are subject to change at any time.
Assigning to @jaredpar as he asked me to do so offline.
The text was updated successfully, but these errors were encountered: