-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support WinRT APIs in .NET 5 #35318
Comments
Does cswinrt derived from xlang? or is it a separate solution? |
@Nirmal4G It uses some xlang technology/ideas, but it is an entirely separate code base and unrelated to that effort. |
The CsWinRT repo is now public. |
What will be the future of the Microsoft Store? |
@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. |
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 |
@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. |
@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. |
@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.
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.
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? |
@jtbrower We really appreciate these general details about the why or what .NET customers are trying to accomplish - thank you.
That sounds about right to me.
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.
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. |
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? |
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. |
@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! |
@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. |
@TerryWarwick thank you for the update. POS is a wildwest of a world that is for sure. |
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. |
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:
Goals
Non-Goals
.NET Runtime/SDK work
ICustomQueryInterface
.ComWrappers
are being called from legacy APIs.IWeakReference
continues to interact with the .NET types:WeakReference
andWeakReference<T>
. See WeakReference and WeakReference<T> should continue to support IWeakReference #35745.ICastable
-esque solution.NativeCallableAttribute
UnmanagedCallersOnlyAttribute
.CsWinRT work
ComWrappers
API.IRestrictedErrorInfo
. Add support for IRestrictedErrorInfo microsoft/CsWinRT#76ICustomPropertyProvider
. Provide ICustomPropertyProvider interface by default. microsoft/CsWinRT#102Breaking changes
Removal of built-in WinRT support. See #37672.
/cc @richlander @jeffschwMSFT @jkoritzinsky @elinor-fung
The text was updated successfully, but these errors were encountered: