Moving System.Security.Permissions Types from WPF

[ojhad]

In order to break the System.Security.Permissions dependency WPF has, we need to move the public types defined in WPF into the System.Security.Permissions.dll. All the types are hollowed out with the exception of XamlAccessLevel since there is data being stored and retrieved there that isn't purely about permissions, so this is done to avoid potential breaks.

[vatsan-madhavan]

Related: dotnet/wpf#241

[vatsan-madhavan]

Can you help us understand your comment about XamlAccessLevel ? In particular, is there a specific reason why we can't be more aggressive about removing the functionality exposed by this type?

What happens if AssemblyAccessTo always returned null, for e.g.?

[ericstj]

Fix up the netfx / package build

[ojhad]

Can you help us understand your comment about XamlAccessLevel ? In particular, is there a specific reason why we can't be more aggressive about removing the functionality exposed by this type?

What happens if AssemblyAccessTo always returned null, for e.g.?

When attempting to hollow out this type in WPF, I discovered that XamlAccessLevel was actually not being exclusively used with XamlLoadPermission. As one specific example, XamlAccessLevel was actually being used to pass the name of an assembly which in turn was used to load an assembly by the XamlRuntime. Here's what I am referring to:
https://github.com/dotnet/wpf/blob/ed9f2dabfde96104e13b91108ae186ffa336acae/src/Microsoft.DotNet.Wpf/src/System.Xaml/System/Xaml/Runtime/DynamicMethodRuntime.cs#L159

While this will need to be fixed in WPF regardless, I decided to keep the functionality intact since this could be a potential breaking change in other places where this type was used to pass contained data.

[stevenbrix]

Can you explain more on what the end user experience here is? When we spoke offline it seemed that hollowing out these types broke their core functionality, and so any app that was using them would be broken moving to .NET Core. Is that the experience we will still have now? Or is this what you are referring to with XamlAccessLevel?

[ericstj]

You don’t need to spend a time of effort on these. We don’t want to give folks any illusion that these types are functional. For details you can see https://github.com/dotnet/corefx/issues/9482 and related commits.

[ojhad]

Can you explain more on what the end user experience here is? When we spoke offline it seemed that hollowing out these types broke their core functionality, and so any app that was using them would be broken moving to .NET Core. Is that the experience we will still have now? Or is this what you are referring to with XamlAccessLevel?

When we spoke offline, I was specifically referring to what I mention above with XamlAccessLevel. Hollowing out the other permission types should not break any of the core functionality as they now are essentially no-ops.

[vatsan-madhavan]

See comments re PublicKeyToken

[ericstj]

Please add basic tests along the same line as what already exists for the other dummy types.

[ericstj]

Thanks!

[ghost]

Hello @ericstj!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[stevenbrix]

You don’t need to spend a time of effort on these. We don’t want to give folks any illusion that these types are functional. For details you can see #9482 and related commits.

@ericstj yeah I understand that. I was trying to understand what the developer experience is for porting an app to .NET Core when their app uses these types. Is it expected that the app just breaks when the developer presses F5? Does the developer get an exception with an error message, or does some functionality in their app that was depending on these just no longer work?

[danmoseley]

I was trying to understand what the developer experience is for porting an app to .NET Core when their app uses these types. Is it expected that the app just breaks when the developer presses F5? Does the developer get an exception with an error message, or does some functionality in their app that was depending on these just no longer work?

I assume the expectation is that everything works essentially as if the app was running in full trust, ie., all demands always succeed. Is that not what will happen?

[vatsan-madhavan]

I assume the expectation is that everything works essentially as if the app was running in full trust, ie., all demands always succeed. Is that not what will happen?

That's the expectation, modulo the fact that CAS-the-functionality in itself will no longer work - which is old news for .NET Core (and really, old news even for .NET Framework), but this will be the first time many WPF developers will encounter this shift. All first-order breaks would be graceful-degradations (like demands silently succeeding as a no-op behind the scenes)

There can be second order breaks that only affect niche/advanced scenarios. For e.g., say someone has implemented a type that is similar to XamlLoadPermission (this one is sealed, so they couldn't have derived from it) that uses/depends on XamlAccessType. They'd have to adjust their implementation a bit to successfully port (preferably, throw away their *Permission type entirely). These sorts of "breaks" are edge cases.