Hollowed out public types extending from System.Security.Permissions types

[ojhad]

Currently this PR does not include Type Forwarding of these types

Part of Issue #241
Hollowing out public types that should be moved out of WPF to System.Security.Permissions.dll

[dnfclas]

All CLA requirements met.

[vatsan-madhavan]

Your build is passing, but tests are failing (so, well, the build is not passing, really). Do you have a sense for what's going on?

   at DRT.DrtBase.ReportException(Object o) in /_/src/Microsoft.DotNet.Wpf/test/Common/TestServices/DrtBase.cs:line 2102
   at DRT.DrtBase.Run(String[] args) in /_/src/Microsoft.DotNet.Wpf/test/Common/TestServices/DrtBase.cs:line 296
   at DrtXaml.XamlDrt.RunTests(String[] args) in /_/src/Microsoft.DotNet.Wpf/test/DRT/DrtXaml/DrtXaml/DrtXamlBase.cs:line 99
   at DrtXaml.TestFrontEnd.<>c__DisplayClass1_0.<RunSuite>b__0() in /_/src/Microsoft.DotNet.Wpf/test/DRT/DrtXaml/DrtXaml/DrtXamlBase.cs:line 70
   at DrtXaml.TestFrontEnd.<>c__DisplayClass2_0.<StartSTATask>b__0() in /_/src/Microsoft.DotNet.Wpf/test/DRT/DrtXaml/DrtXaml/DrtXamlBase.cs:line 80
--- End of stack trace from previous location where exception was thrown ---
   at DrtXaml.TestFrontEnd.RunSuite(String[] data) in /_/src/Microsoft.DotNet.Wpf/test/DRT/DrtXaml/DrtXaml/DrtXamlBase.cs:line 70
--- End of stack trace from previous location where exception was thrown ---

[vatsan-madhavan]

@ericstj , We'd like to move these types to System.Security.Permissions, and type-forward to it. I think we'd want to also make these dangling-references from WindowsDesktop. App. Thoughts?

[ericstj]

We'd like to move these types to System.Security.Permissions, and type-forward to it

Excellent, please open a PR.

make these dangling-references from WindowsDesktop. App

What kind of dangling-references? Dangling type-forwards: sure. We do the same for our mscorlib.dll facade. Dangling type-refs from attribute applications / actual usage: no-go : JIT would throw.

[vatsan-madhavan]

What kind of dangling-references? Dangling type-forwards: sure. We do the same for our mscorlib.dll facade. Dangling type-refs from attribute applications / actual usage: no-go : JIT would throw.

Dangling type-forwards only.

The goal is to eliminate all actual type-refs before RTM and end up with ref assemblies that didn't require S.S.Permissions to build (module type-forwards). You'll start seeing a related PR's to get to this shortly (I'll cc you)

[vatsan-madhavan]

@ojhad, once the changes are made and the test failure is figured out, let's merge the changes into WPF and then move the dummied-out impl. to corefx s.s.permissions.

[ericstj]

Be aware that we're trying to lock down all API changes in CoreFx by Preview7 which means this would need to make it into corefx in the next couple weeks. For a move like this, I'd recommend adding types in CoreFx, letting them flow upstack, then swap from type-def to typeforward when the packages reach WPF. It does mean that we'll have a couple SDK builds with the types in both places, but that only breaks apps trying to compile against them which we don't expect a lot of folks to need to do.

[weltkante]

This is not a valid implementation because x.Equals(x) returns false, which will cause all sorts of bugs if anyone calls this method. You should use ReferenceEquals(this, obj) or throw an exception if you don't want to support equality.

[vatsan-madhavan]

This impl. will get deleted from dotnet/wpf shortly, and we'll consume the one from dotnet/corefx#38405. Let's make sure we get the corefx PR right.