WPF must remove all calls to obsolete .NET 5 APIs before GA

[ryalanms]

WPF must remove all calls to obsolete .NET 5 APIs before GA.

The obsolete API warnings were temporarily disabled here:
dc7669e

The full list of .NET 5 obsolete APIs is here:
https://github.com/dotnet/designs/blob/master/accepted/2020/better-obsoletion/obsoletions-in-net5.md

[vatsan-madhavan]

What is the alternative to CER then? /cc @terrajobst

[miloush]

I also want to point out that the Assembly.CodeBase which WPF uses was marked as obsolete (dotnet/runtime#31127). I am a bit worried about that, does it not affect loading site of origin and/or other components based on uri?

[ryalanms]

/cc @dotnet/wpf-developers @jeffhandley @danmosemsft

[ryalanms]

Adding guidance from @jeffhandley. Thanks.

1. There were no runtime behaviors changed with any of these obsoletions
   a. For everything except BinaryFormatter, these obsoletions are advertising that features that existed in .NET Framework do not function as expected in .NET Core
   b. The obsoletions are therefore mostly aimed at folks migrating from .NET Framework to .NET Core and alerting them to code that now simply no-ops in .NET Core
   c. But for code already running against .NET Core, there will be no behavioral difference
2. You should suppress all of these obsoletions; here are some details for each of the obsoletions affecting you:
   a. BinaryFormatter
   i. This one has lots of guidance written up: https://aka.ms/binaryformatter
   b. System.Xaml.Permission.XamlLoadPermission
   i. This was obsoleted as part of Code Access Security (CAS) being obsoleted
   ii. CAS is not enforced on .NET Core
   iii. I recommend suppressing this in .NET 5 and removing references to XamlLoadPermission in .NET 6
   c. Assembly.GlobalAssemblyCache
   i. GAC is not available on .NET Core; this property will always return false
   ii. I recommend suppressing this in .NET 5 and removing references to GlobalAssemblyCache in .NET 6
   d. ResourceAssembly.CodeBase
   i. Assembly.CodeBase was used for Code Access Security (CAS), which is not enforced in .NET Core
   ii. You could consider changing uses of CodeBase to use Location instead, but suppressing in .NET 5 and changing the code in .NET 6 is perfectly fine
   iii. For more info: Mark Assembly.CodeBase as obsolete runtime#31127
   e. Constrained Execution Region (CER)
   i. CER is not respected in .NET Core and does not provide the guarantees that could be expected
   ii. I recommend suppressing this in .NET 5 and removing references to CER APIs in .NET 6

[miloush]

Assembly.CodeBase was used for Code Access Security

That's by runtime. I was trying to suggest WPF is using it for other purposes too. While I understand CAS has been obsoleted, I don't see why if you want the assembly location as Uri you should do extra work with Location, prone to bugs, when there is perfectly working CodeBase property already that does the job. The CodeBase property documentation mentions nothing about CAS, so the relevance for obsoleting it is not clear (and unnecessarily fractures code that targets both FW and Core). I accept though that the decision has been already made; hopefully we can adapt without breaking changes.

[terrajobst]

@vatsan-madhavan

What is the alternative to CER then? /cc @terrajobst

There is none. You just delete the calls/attribute applications. The feature has never been supported on .NET Core and we don't plan on adding it.

@miloush

Assembly.CodeBase was used for Code Access Security

That's by runtime. I was trying to suggest WPF is using it for other purposes too.

Any reason WPF can't use Assembly.Location instead?

[vatsan-madhavan]

There is none. You just delete the calls/attribute applications.

Simply removing the attributes, suppressing warnings etc. and hoping all would work out well sounds a bit too easy to me.

If CER is not supported, then the code that relied on CER must surely be rewritten in a way that no longer relies upon the guarantees originally promised by CER, wouldn't it? I was expecting this type of guidance to be elaborated as part of the obsoletion docs.

[danmoseley]

@jkotas do you expect that code written to assume CER may need modification on Core?

[jkotas]

The primary reason for CER in .NET Framework was robustness against ThreadAbort. We do not have ThreadAbort in .NET Core. It makes CER unnecessary.

[vatsan-madhavan]

thanks @jkotas & @danmosemsft

[ryalanms]

Thanks, everyone.