We Keep Coding

Use UWP library in .NET Framework / .NET Standard application

Is there a way to use a C# library written in the UWP framework in a .NET Framework (or .NET Standard) application?
I try to get a Bluetooth (BLE) module working for a .NET Framework application in Windows 11. As far as I know, the native Bluetooth support is only possible using UWP, so I can't switch here. The .NET Framework application is also fixed, it contains external libraries from suppliers that can't be updated to .NET Standard or .NET 6. However, I can write an adapter class that uses .NET Standard 2.0, so I can work with it if a solution for .NET Standard exists.
When I try to reference a UWP class from .NET Framework or .NET Standard, I always get an error like this:
"Project BLE_Module is not compatible with netstandard2.0(.NETStandard,Version=v2.0). Project BLE_Module supports: uap.10.0.17763(UAP,Version=v10.0.17763)"
I know I can reference .NET Standard classes from UWP, but that does not help me, as the UWP module is just an execution module for Bluetooth requests and does not include any business logic.
What can I do to resolve the problem? I could write the BLE_Module as a stand-alone service and interact with the service from the main program during runtime, but before I embark on this journey, I would like to know if there are any possibilities to make it work without such a specific solution (that also reduces testability and increases bug chances).

Is there a way to use a C# library written in the UWP framework in a .NET Framework (or .NET Standard) application?
Short answer: No.
That's why .NET Standard was introduced in the first place, i.e. to be able to share common code between different .NET implementations.
A class library that targets a specific platform, such as UWP, cannot be consumed from an app that targets another platform, such as for example the .NET Framework.

Native Bluetooth support does not require UWP. The Bluetooth libraries are written for the WinRT API, so you can use them from C++ or .NET Framework desktop applications.
See https://learn.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-enhance for more info.
If you however have an additional layer written in UWP on top of the native Bluetooth libraries, then I'm not sure if that can be consumed in a normal .NET Framework application.

how to make UWP class library to support WindowsAppSdk apps

I have developed a UWP class library , and it is already used in various projects.
Now I want to make this UWP class library to support WindowsAppSdk apps too.
When I try to refer UWP Library in WindowsAppSdk app, getting error like "Project is not compatible".
My UWP class library min supported version - Windows 10 fall creators update (16299).
Should I recreate my UWP Library as WindowsAppSdk library ?
Can anyone help me understand this
Thanks
Noorul.

Should I recreate my UWP Library as WindowsAppSdk library ?
No, but you should convert it into a .NET Standard library that can be consumed by both UWP and WinUI (.NET) applications, and any other type of application whose runtime implementation supports the version of the .NET Standard specification that you choose to target.
UWP apps cannot consume librararies that are targeted against a specific platform such as .NET and vice versa. That's where .NET Standard comes in. It enables you to share code across multiple .NET implementations and platforms.

The type or namespace name 'IPAddress' could not be found

I'm writing a Xamarin.Forms application and have added a PCL project into my main solution in Visual Studio 2013. I'm having problems with using several standard .net classes. Here's a list:
System.Net.IPAddress
System.Net.IPEndPoint
System.Net.WebClient
System.Net.Sockets.UdpClient
System.Timers.Timer
System.Timers.ElapsedEventArgs
System.Net.NetworkInformation.UnicastIPAddressInformation
My question is: How do I figure out which of the above are compatable with a Xamarin.Forms app, and how do I get them to work in my project/solution?
I've contacted Xamarin support, but get vague help and not specifics...
Does anybody have a good strategy for figuring out what classes are supported and what .dlls are needed in order to use them with a Xamarin.Forms project?
Thanks a bunch for your help.
PS: I've been given the following sites for reference, but they don't seem to have any concise information:
What is supported
NuGet package info

It sounds like you don't understand what Portable Class Libraries actually are. When you create a PCL, the subset of the .Net Framework classes that are available for you to use depends on what profile you choose. A profile are the platforms your PCL can support. In Xamarin, the default profile is Profile 78. Profile 78 supports .NET 4.5, WP8, Win8, WP Silverlight 8, Win Store 8, Xamarin.Android, Xamarin.iOS. So the classes that are available to you are the classes that are platform independent, that run on ALL platforms in profile 78.
Example: Take a look at the implementation of System.Net.IPAddress. The implementation makes use of Sockets. Upon further inspection of this implementation, you can see that that System.Net.Sockets is nothing more than a .NET wrapper around the WinSock API. The WinSock API is a Windows only DLL that is specific to the Windows operating family (ws2_32.dll). So, you can now see that System.Net.IPAddress are high level abstractions of Windows Socks (built for the Windows Platform). Since the ws2_32.dll does not exist in Android, nor iOS, etc, this API won't be available to you because Profile 78 specifies that we need to support other non-windows platforms.
Another example is System.Drawing.Bitmap. That's just a .NET wrapper around GDI+, which is based on the Win32 API. Of course Win32 is not available on non-windows platforms (even Windows Phone), which is why you won't see it in a PCL.
Now with that being said, you may think that PCLs are restrictive, but you can create a good PCL library if you think about them the right way. You can also use patterns like Dependency Injection and Bait and Switch.
So in short, don't count on Microsoft "adding support for all the base class libraries" because that's not what PCLs are.

You can still use System.Net.IpAddress in your Xamarin.Forms PCL by using DependancyService. Make an interface in PCL and declare a method "GetIpAddress" in it. Then , in android /iOS project, you can implement that interface in platform specific project and easily access System.Net.IpAddress. After that, Call DependancyService from PCL project to get the result which is IPAddress of your desire.
Cheers !!!

After some additional e-mail from Xamarin Support, and comments on my additional posting, it appears that MS is quite behind in supporting all of their classes via PCL. Some are supported, but not all by a long shot.
Anyway, in order to use my existing code, I would need to put the source .cs files that I would otherwise be using to create my new PCL project directly in the .iOS project and in the .droid project and recompile that way.
This basically defeats the advantage of using a PCL, but does provide an alternative that allows me to use most of my code unchanged. It would just be nicer if all the xamarin libraries were available as PCLs.. Oh well, eventually MS will catch up and get all of their PCLs up to date so that we can use our custom PCLs more often, instead of having to duplicate code all over the place. (Maintenance Nightmare)...
Anyway, thanks to all for the help.
(Working on the bleeding edge of technology is sometimes painful... But that's why we make the big bucks !!!)

How to use TypeForwardedTo in Portable Class Libraries?

I'm trying to build a Portable Class Library which uses implementations from the platform when available. For example, Lazy<T> is available on .NET 4.5, Windows Store Apps, Windows Phone 8, BUT it's not available on Windows Phone 7, Silverlight 4. When my PCL is loaded on one of the platforms that has a Lazy<T> implementation, I want to use the platform's implementation. When it's not available on the platform, I want to use my own implementation. It seems to be possible because the Microsoft BCL is doing it, but I haven't figured out how to implement it.
I've read that by using the TypeForwardedToAttribute, you can redirect the PCL to use the implementation from the platform. I'm not quite sure how to configure my Visual Studio Projects to achieve this result. If CoreLib is my library, and ShimLib contains my implementation of Lazy<T>. Where do I add the TypeForwardedToAttribute? The attribute requires an actual Type reference typeof(System.Lazy<>), which doesn't work when Windows Phone 7 is targeted in the PCL. If I remove Windows Phone 7, then I can't add a reference from CoreLib to ShimLib because ShimLib doesn't support all the platforms that CoreLib does. How do I handle this?
Yes, I know Lazy<T> is super easy to implement, but it's just an example, and my actual situation applies to many more classes that are less trivial to implement.

The way Microsoft.Bcl does this by shipping two assemblies with the same identity; one with the type itself, and one with the type forward. You reference the one with the type when targeting platforms that don't support Lazy (include portable library combinations that include one of these platforms). And reference the one with the type-forward when targeting platforms with Lazy, this enables to consume libraries built against the older platforms.
Make note, Microsoft.Bcl has a little advantage that you don't have. We ship an assembly that has the same identity as one that is already in later versions, which means that when a Windows Phone 7 app runs on Windows Phone 8, they get the version that's built in, not the one in the shim library. You are unable to mimic that, but that's probably something you can live with in your situation.

The principle idea of type forwarding is very well explained in this question and this article and I'm not repeating the details here. In summary, however, the idea is to be able to reuse a library A without recompiling, even though it references a library B that is being replaced by library C. To that end, library B has to be modified such that it forwards the reference to library C, which is exactly what the TypeForwardedTo attribute does.
How does this help you? Well, you could create your ShimLib such that it is referenced by all your projects, but uses conditional compilation and type forwarding to link it to the framework libraries if they exist. Fortunately, someone already did that for you :)
Edit in response to Matt's comment: You're right, I overlooked that Theraot doesn't fall back to the original implementation. And I guess that will be very hard to achieve without recompiling. The best you can do is probably to follow this strategy, i.e. to have different build configurations for the different framework versions. That way, you can conditionally compile the TypeForwardedToAttribute. At least, this saves you from having to duplicate code. If you really don't want to distribute different versions of your code, you might implement a bootstraper that determines the framework version and loads the version of your assembly that has been compiled using the build configuration for this version

Is it possible to create a Mono bundle that includes WPF libraries?

I know WPF libraries aren´t implemented by mono class library, however(as far as I know) the mono 2.6 runtime is fully compatible with the .NET 2.0/3.5 runtime, so if the WPF libraries only make PInvoke calls to windows api it is theoretically possible to run a wpf application on windows using the mono runtime.
The reason for wanting that is deploying a wpf application as a standalone executable for windows. Has anyone tried something like that before? If so, what were the results?

In short... No
At this point, the Mono project does not have plans to implement Windows Presentation Foundation APIs as part of the project
Mono will provide Moonlight support which, from what I understand, would also use a subset of XAML to create its UI (the same as Silverlight does) but there are legal complications involved. Such as, it's limited to non-microsoft and non-mac platforms.
If you want to find a list of open-source cross-platform alternatives to WPF/XAML I'm working to compile a list of viable alternatives.

Well I did give it a try with little success. I first checked with corflags if required dll-s are implemented in mixed mode (PresentationFramework, PresenationCore, WindowsBase, System.Xaml). They are all pure CIL implementations so that should work fine with mono. Next I installed mentioned DLLs into mono's GAC and tried running a very simple WPF application. This is what I got:
Assertion at mini-codegen.c:1186, condition `reginfo [sreg].born_in
0' not met
This application has requested the Runtime to terminate it in an
unusual way. Please contact the application's support team for more
information.
So although in theory this should all work, WPF is probably way to complex to run out of the box on mono, it would be cool if there was a pure CIL implementation of WPF that was compatabile with both mono and .NET Framework.

As much as I know, Mono does not support WPF.
Also, WPF uses graphics modules and interacts directly with the GPU. So I can't see how u can use WPF with no hidden pinvokes.

Sounds like you need to read about WPF architecture to better understand it.
http://msdn.microsoft.com/en-us/library/ms750441.aspx
Many pieces are missing in Mono and solely available in .NET. Therefore, your "theory" is not correct, and you cannot run WPF applications on Mono, even on Windows.

At MIX 2010 Miguel de Icaza said in his session that Mono isn't going to support WPF. Anything tangentially related to WPF-like support is only to provide what is needed for Moonlight.

Not fully, but..
You can use Moonlight 4 ( silverlight 4 ) in a desktop mode:-
https://github.com/inorton/MoonBase - MVVM helpers
https://github.com/inorton/XamlPreviewer - XamlPad clone