Support WinRT APIs in .NET 5

[AaronRobinsonMSFT]

We are moving to a new model for supporting WinRT APIs as part of .NET 5.0. This includes calling APIs (in either direction; CLR <==> WinRT), marshaling of data between the two type systems, and unification of types that are intended to be single instance (i.e. "projected types"). We will be removing the existing WinRT interop system from the .NET runtime (and any other associated components) as part of .NET 5.0.

We will rely on a new set of tools provided by the WinRT team in Windows that will generate C#-based WinRT interop assemblies. We are currently working closely with that team. The tools will be delivered for .NET 5.0.

There are several benefits to the new system:

• Can be developed and improved separate from the .NET runtime.
• Symmetrical with interop systems provided for other OSes, like iOS and Android.
• Can take advantage of many other .NET features (AOT, C# features, IL linking).
• Simplifies the .NET runtime codebase.

Goals

• Allow the WinRT ecosystem to move independently of the .NET runtime with respect to WinRT projections.
• Migration of existing applications and libraries to this new model should require minimal code changes. Creating a new project and recompilation is considered acceptable.
• Provide a WinRT solution that is AOT and ILLinker friendly.
• Permit the ability to remove built-in .NET Runtime support of WinRT.
• Provide similar performance to what is available with .NET Core 3.1.

Non-Goals

• Support existing WinMD-based managed WinRT assemblies.
• Replace the MCG tool used by .NET Native.

.NET Runtime/SDK work

• Creation and management of COM wrappers.
  • Support ICustomQueryInterface.
  • Provide a mechanism to determine if ComWrappers are being called from legacy APIs.
  • Ensure IWeakReference continues to interact with the .NET types: WeakReference and WeakReference<T>. See WeakReference and WeakReference<T> should continue to support IWeakReference #35745.
  • Support an ICastable-esque solution.
• C# function pointers to achieve performance goals.
  • This work was already in flight with the C# function pointers proposal.
  • Expose NativeCallableAttribute UnmanagedCallersOnlyAttribute.

CsWinRT work

• Consume the new ComWrappers API.
• Help generate C# source for interop code.
  • Support correct managed object wrapper lifetime management. ObjectReference<T> needs to support the Dispose pattern for correct CCW lifetime microsoft/CsWinRT#37
  • Support default implemented interfaces. Provide method for projections to add "default-implemented" interfaces for CCWs microsoft/CsWinRT#49
  • Marshaling of arrays of interfaces. Marshalling Arrays of Interfaces to ABI selects the incorrect marshaler microsoft/CsWinRT#61
  • Support IRestrictedErrorInfo. Add support for IRestrictedErrorInfo microsoft/CsWinRT#76
  • Support ICustomPropertyProvider. Provide ICustomPropertyProvider interface by default. microsoft/CsWinRT#102

Breaking changes

Removal of built-in WinRT support. See #37672.

• Remove built-in WinRT support from the runtime #36715

/cc @richlander @jeffschwMSFT @jkoritzinsky @elinor-fung

[Nirmal4G]

Does cswinrt derived from xlang? or is it a separate solution?

[AaronRobinsonMSFT]

@Nirmal4G It uses some xlang technology/ideas, but it is an entirely separate code base and unrelated to that effort.

[AaronRobinsonMSFT]

The CsWinRT repo is now public.

[pubtom]

What will be the future of the Microsoft Store?

[richlander]

@pubtom -- this issue is related to a low-level topic. I suggest you reach out to the folks @ https://github.com/microsoft/microsoft-ui-xaml to talk about Microsoft/Windows Store.

[jtbrower]

Hello Team, this weekend I decided to jump from .Net 5 preview 4 to .Net 5 preview 7. The first compilation error I ran into is directly related to these changes. I know you all have plenty of work to do, I don't want to interrupt, but would there currently be smooth way for .Net early adopters to transition from using the <PackageReference Include="Microsoft.Windows.SDK.Contracts" Version="10.0.19041.1" /> projections? Or maybe a procedure somewhere? If I am way too early just let me know and I will head back to preview 4. Thanks -Jason

[AaronRobinsonMSFT]

@jtbrower Thank you for reaching out. The earlier we hear from real users the better. Right now the best place to start looking into where the Windows team is headed is at https://aka.ms/cswinrt. There are links to an issues section on the https://github.com/microsoft/CsWinRT repo. Please let us and them know what issues you hit and how we can help unblock you.

[jkoritzinsky]

@jtbrower the simplest fix for you would be to reference the Microsoft.Windows.SDK.NET package instead of the Microsoft.Windows.Sdk.Contracts package. That should work. If it doesn't, then following the links Aaron mentioned would be the best next step.

[jtbrower]

@AaronRobinsonMSFT @jkoritzinsky thank you both for such a rapid response. Jeremy, I added a reference to the Microsoft.Windows.SDK.NET package and my main goal was achieved. That is, the code compiles again! I have plenty of work to do that does not required the Windows 10 SDK API's, so what I am about to say is by no means urgent for me. Before I go forward I should mention that my main reason for using the Windows SDK was in a quick Sprint I did last year to see how well the PointOfService classes worked as a replacement for a legacy package of mine that works directly with USB HID devices. During that sprint I had the credit card reader up and running in no time at all and put that sprint aside knowing that when I was ready I could dive deeper into a possible migration. I wanted to mention these details because it is worth noting that I really wasn't exercising that functionality anymore, other than to assure it compiled. With that stated, the following issues might have been triggered by versions other than .Net 5 preview 7.

Running a .Net 5 preview 7 application that calls into the Windows.Devices.PointOfService,Windows.Devices.Enumeration and Windows.Foundation namespaces I hit the following exception.

System.MissingMethodException: Method not found: 'Void System.Runtime.InteropServices.ComWrappers.RegisterAsGlobalInstance()'.
   at WinRT.ComWrappersSupport.get_ComWrappers()
   at WinRT.ComWrappersSupport.CreateRcwForComObject(IntPtr ptr)
   at WinRT.MarshalInspectable.FromAbi(IntPtr ptr)
   at ABI.Windows.Devices.Enumeration.DeviceWatcher.FromAbi(IntPtr thisPtr)
   at ABI.Windows.Devices.Enumeration.IDeviceInformationStatics.CreateWatcher(String aqsFilter)
   at Windows.Devices.Enumeration.DeviceInformation.CreateWatcher(String aqsFilter)

It is my belief that this exception is related to the following update #35681. I think I must have a mismatch between the hot-off-the-press preview 7 and the following NuGet package.

<PackageReference Include="Microsoft.Windows.SDK.NET" Version="10.0.18362.3-preview" />

Are there any public "private" feeds to grab packages that coincide with the "preview previews"?

Again, this is not a high priority for me. Between all of the other preview builds I am using, I already have my hands full. I wasn't share if I should put this information over in the https://github.com/microsoft/CsWinRT repo, maybe I should?

[AaronRobinsonMSFT]

to see how well the PointOfService classes worked as a replacement for a legacy package of mine that works directly with USB HID devices

@jtbrower We really appreciate these general details about the why or what .NET customers are trying to accomplish - thank you.

It is my belief that this exception is related to the following update #35681. I think I must have a mismatch between the hot-off-the-press preview 7 and the following NuGet package.

That sounds about right to me.

Are there any public "private" feeds to grab packages that coincide with the "preview previews"?

I don't think so. I would suggest going back to the official Preview 5 release since that is what coincided with the package @jkoritzinsky referenced. As assumed this is a point in time issue so should go away as all the repos/nupkgs align on API surface area.

I wasn't share if I should put this information over in the https://github.com/microsoft/CsWinRT repo, maybe I should?

That would probably be helpful since it will let the CsWinRT team know that an updated package would be helpful for people on the bleeding edge of .NET runtime consumption.

[jtbrower]

Thank you again for the nice and timely response. Before I read your reply, I had rolled back to Preview 4 and tested the PointOfService MageticStripeReader class, and the swipe events were detected. I will try to engage the team over at the CsWinRT repo, one big missing implementation is the fact that the PointOfService APIs do not support USB POS Printers. As I think of this, a feature request like that might belong in a different repo since the CsWinRT is only a set of projections, right?

[AaronRobinsonMSFT]

As I think of this, a feature request like that might belong in a different repo since the CsWinRT is only a set of projections, right?

Yes. I would agree with that. If this becomes an issue with something needed in the runtime they will be able to convey that need to us.

[Scottj1s]

@jtbrower - yes, please open any issues you see on the https://github.com/microsoft/CsWinRT/issues tab. Even if they're point in time, it's friction for early adopters that we'd like to avoid. thx!

[TerryWarwick]

@jtbrower - You are absolutely correct in that the PointOfService.POSPrinter interfaces do not support USB POSPrinters as native devices today. This is largely due to the lack of hardware standards for most POS devices. However, you can use our legacy compatibility support for POSPrinters by installing OPOS and the associated service object for your POSPrinter. Once this OPOS infrastructure is working properly you should be able to enumerate the OPOS device in UWP and use the USB connected POSPrinter.

[jtbrower]

@TerryWarwick thank you for the update. POS is a wildwest of a world that is for sure.

[jkoritzinsky]

With the function pointer work merged in to C#/WinRT and we've gotten all of the big pieces done from the runtime perspective, I'm going to mark this as completed.