Windows Runtime package confusion and corruption.

[Gavin-Williams]

Why are there 3 very similarly named packages?

System.Runtime.InteropServices.Windows.Runtime (4.3.0)
System.Runtime.InteropServices.WindowsRuntime (4.3.0)
System.Runtime.WindowsRuntime (4.7.0)

If System.Runtime.WindowsRuntime (4.7.0) is used, the app will actually crash as events will be wired up to the wrong assembly. The following output will be produced ...

Exception thrown at 0x75864192 in Demo.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x1296D25C.

Exception thrown at 0x75864192 in Demo.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.

Exception thrown at 0x75864192 in Demo.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.

Exception thrown at 0x75864192 in Demo.exe: Microsoft C++ exception: [rethrow] at memory location 0x00000000.

Exception thrown at 0x75864192 (KernelBase.dll) in Demo.exe: WinRT originate error - 0x80131040 : 'System.IO.FileLoadException: Could not load file or assembly 'System.Runtime.WindowsRuntime, Version=4.0.15.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
at Engine.Interaction.MouseEventProcessor.OnPointerMoved(Object sender, PointerEventArgs e)'.

But WindowsRuntime 4.7.0 looks like the current version of WindowsRuntime 4.3.0 - and no idea why there is also a Windows.Runtime 4.3.0 - This is all a big screw-up if you ask me. We have to guess which one to use. Because when a project is setup in VS, they are not automatically added, events just won't compile with red-squigglies. I've just spent a week trying to find this bug.

Oh, and System.Runtime.InteropServices.WindowsRuntime (4.3.0) is only needed if events are used in a DLL (.net standard), because I suppose the Universal Windows package does actually include the right whatever. This is a minefield.

Is there any documentation about this? And no matter, projects shouldn't so easily be led into this situation. These packages need to be renamed if they are actually different packages.

[AaronRobinsonMSFT]

/cc @jkoritzinsky @Scottj1s

[AaronRobinsonMSFT]

These packages will be under going substantial change based on the work described at #35318.

[AaronRobinsonMSFT]

Built in WinRT support has been removed. This package is no longer supported. See #37672.