-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.Windows.Extensions.dll included in Linux SDK output #9213
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
One question is why there is no Windows-based condition check for this reference: |
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsThe Linux version of the SDK is including the System.Windows.Extensions.dll file in the following paths:
There are other files existing in this
|
cc @dotnet/area-system-security for the above System.Security.Permissions question.
System.Security.Permissions doesn't target any RIDs. It provides RID agnostic TFMs: https://github.com/dotnet/runtime/blob/b9b51d3bbdd547a2542720c772d7e85fa6a82837/src/libraries/System.Security.Permissions/src/System.Security.Permissions.csproj#L3 If we would want to only include that reference for Windows, we would need to start targeting RIDs which has drawbacks (package size, build complexity, ...). From what I can see, the S.W.E. reference is necessary because of As that type is already marked as obsolete on .NETCoreApp and was only brought back for WPF, it might be interesting to discuss if we can actually remove it as part of a breaking change. |
The whole S.S.P is obsolete. I do not think it is worth doing anything with it. People should be deleting references to it as part of modernizing their projects.
This is dotnet/sdk#16895 |
We ourselves also reference S.S.P. Should we stop doing that as part of a bigger breaking change and delete S.S.P eventually? |
S.S.P is part of .NET Framework compat. I think it needs to exist in this repo as long as we are building the .NET Framework compat live. Cleaning it up from dependencies of assemblies that end up in .NET SDK would be nice. I expect that most of the work for that would be outside of this repo. |
We've actually removed most of these references in dotnet/runtime - making them private to exclude the package reference. Keeping the type forwards (dangling) for compat. I think I had a look at MSBuild and I'm not sure it even uses System.Security.Permissions. Most that code looks to me like it's under ifdef that's only defined for NetFX - one exception seems to be XmlSyntaxException which needs an ifdef. It seems that it does still pull in SSP through a reference to 7.0 ConfiugrationManager, when updating to 8.0 we can remove this completely. I was able to update to 8.0 packages and remove SSP completely and it no longer shows up in the output. #9212. EDIT: Looks like a similar PR was already raised: #9055. I think that PR should be driven in. |
Let's check that it was fixed. |
Yes, I think this got resolved. |
The Linux version of the SDK is including the System.Windows.Extensions.dll file in the following paths:
This is a regression as a result of the change in #9158. That change caused the live version of System.Security.Permissions to be used. That version has a dependency on System.Windows.Extensions, even when targeting Linux. So System.Windows.Extensions is being built and included in the output of the SDK.This is not a regression from #9158 because this change also exists in Microsoft-built SDK for Linux. The change from #9158 just made it visible in the source-build SDK diff tests.There are other files existing in this
runtimes/win
path as well, which is a suspicious path when targeting Linux:The text was updated successfully, but these errors were encountered: