Removed Security.Permission reference#9055
Conversation
JanKrivanek
left a comment
There was a problem hiding this comment.
This looks good, however I believe that we'll unfortunately need to hunt and kill all the transitive dependencies as well :-/
You can use the project.assets.json files to find them and untagle the transitivity chain:
> \.build.cmd
...
> cd artifacts\obj
> findstr /spin /c:"System.Security.Permissions" project.assets.json
One example is System.Configuration.ConfigurationManager
|
This would've helped with dotnet/source-build#3571 / #9158. @maridematte do you plan on updating the PR? I can help address the PR feedback if you don't have time. |
|
@akoeplinger Unfortunately the Is this blocking you anywhere? The bug and PR you mentioned are both closed - so I'm trying to see what's the priority of this one |
|
@JanKrivanek the problem in dotnet/source-build#3571 was that a type from As for This is not blocking for me, I just noticed this while looking at related PRs. But I think #8962 looks quite important if the msbuild package now can't be used on Mac/Linux. |
|
IMO this PR is goodness as it is. If consumers want, they can also reference the latest ConfigurationManager package from 8.0 to lift up the dependency that MSBuild has on it and eliminate all references to SSP. @rainersigwald let me know the SDK will do this so this should remove the file from the final layout. |
|
In an offline discussion we decided to not upgrade |
### Context Since #6148 we produce only reference assemblies for .NET Standard 2.0, which means that several of the our NuGet packages' dependencies when targeting .NET Standard 2.0 are unused. ### Changes Made The project files for `Microsoft.Build.Framework`, `Utilities.Core` and `Tasks` were updated to apply `PrivateAssets="all"` to all package references that are not exposed in the package's public API, when targeting .NET Standard 2.0. ### Testing I ran `dotnet pack` on these projects and validated manually that on .NET Standard 2.0, `Microsoft.Build.Framework` has zero dependencies, `Utilities.Core` depends only on `Framework`, and `Tasks` depends only on the previous two. Because Roslyn [keeps some internal APIs in reference assemblies](https://github.com/dotnet/roslyn/blob/main/docs/features/refout.md#definition-of-ref-assemblies), these reference assemblies still reference some assemblies whose respective package is not depended upon. I manually validated with ILSpy that the types in these assemblies are used only by internal APIs. ### Notes This is going to be a (minor) source-breaking change if a .NET Standard 2.0 project uses APIs from on one of the removed packages and transitively depended on it. They will have to directly depend on them, and it's not the first time we do a change like this (#9055). I don't think that this is a binary-breaking change because the .NET Standard 2.0 binaries are not being used at runtime. --------- Co-authored-by: Jan Provazník <janprovaznik@microsoft.com>
Fixes #8962
Changes Made
Moved some refences for exception handling so
System.Security.Permissionsis not referenced in 8.0.Removed
System.Security.Permissionsfrom the package list in files.Testing
N/A