Time to clean up 2.0

[dotMorten]

Now that 2.0 experimental has become official, can we start considering that since it's a major version to do some light house-cleaning?

For instance:

• Remove the broken/unusable/replaced Dispatcher properties
• Remove Window.Current that always returns null
• Make Window inherit from DepedencyObject
• In general clean up all these APIs that aren't usable: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

Also see #1660

[DarranRowe]

For the last one in particular, cleaning up the unusable API. Isn't that outside of the scope of this project? Those APIs would be exposed to the developer via the projection, so this means that CsWinRT or CppWinRT should be responsible for this.

CsWinRT uses Microsoft.Windows.SDK.NET.Ref for the projection. CppWinRT grabs the list of .winmd files that it needs to use from the Windows SDK. The .winmd files (which CsWinRT must use to generate the projection) don't really provide any information on what is unusable in a purely desktop environment.

[dotMorten]

@DarranRowe No the unusable APIs are also available to C++ developers. For instance Window.Current or DependencyObject.Dispatcher always returns null, and are common pitfalls when porting code from UWP, because your code compiles but crashes at runtime.

[DarranRowe]

That isn't what I was referring to. Specifically, I was referring to:

In general clean up all these APIs that aren't usable: https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-supported-api

The unusable APIs specified in that link are part of the Windows projection.

Although, it is possible that I misread this and what you really meant to say is that if the UWP only APIs are exposed on any Windows App SDK interfaces, then they should be removed, then I misunderstood and I apologise.