I know there is a way to use UWP methods from WPF apps.
My question is whether there is a way to use those methods from a .Net Standard library. Just adding the references mentioned here doesn't help. It doesn't recognize them.
Individual Platforms (.NET Framework, .NET Core, UWP, Mono) can reference .NET Standard libraries. But .NET Standard libraries cannot reference other libraries built specifically for a platform (.NET Framework, UWP etc).
Which makes sense since .NET Standard libraries themselves are supposed to be platform agnostic, so you shouldn't be able to add a library that would only work on a single platform.
Related
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.
I want to create some nuget package that contains API compatible with all Xamarin implementations (UWP, iOS, Android), in order to use it across all devices that can run Xamarin apps.
I heard that the System.* namespaces are the ones compatible with them all, but is there any other namespace that is universal? And I think that the Windows.* namespace is the one compatible only with UWP, right?
Would like to have a detailed explanation of this topic.
This is an impracticable question as there are too many to list.
However all .net standard functionality will be cross compatible to some degree
.NET implementation support
The .NET Standard is a formal specification of .NET APIs that are
intended to be available on all .NET implementations. The motivation
behind the .NET Standard is establishing greater uniformity in the
.NET ecosystem. ECMA 335 continues to establish uniformity for .NET
implementation behavior, but there's no similar spec for the .NET Base
Class Libraries (BCL) for .NET library implementations.
Additional Resources
API list in markdown
Also you might look at this
.NET API analyzer
and
The .NET Portability Analyzer
Generally yes, System namespaces should be available for use across platforms; they are part of .Net. Windows would be platform specific.
I'd worry less about namespaces though and create a class library which targets NetStandard 2.0. And then if you need to access some other library functionality, use Nuget to pull in the package you want. Just make sure you're only pulling packages which target NetStandard themselves, and you should be fine, as NetStandard's goal is to define what all implementations of .Net must provide across platforms.
https://learn.microsoft.com/en-us/dotnet/standard/net-standard
If you do need to do UI libraries and controls, then you'll probably want to stick to Xamarin.Forms. XF is meant to provide a common UI framework for iOS, Android, Mac, and Windows UWP. Again, stick to the stock XF libraries and NetStandard 2.0, and you'll have the widest reach there.
When you use a .net standard lib from the full .net framework you end up having to include/deploy .net standard versions of all the System.* assemblies the .net standard library uses.
Now that Xamarin supports .net standard and microsoft is recommending people use .net standard rather than PCL we will soon need to switch (library developers are abandoning PCL support).
My question is does using a .net standard library in a Xamarin for Android project mean that multiple system assemblies will be deployed (the .net standard version and the mono version)?
Xamarin apps are already much bigger than native and having to include duplicates of all the system assemblies we need could be a deal breaker going forward.
The .NET Standard(s) define the API surface of each version. The implementation of the API surface lies with the platform.
In the case of Xamarin the surface is implemented in the Mono framework which is deployed with every app. (And has been before)
If you reference nothing but the NETStandard Library the final .apk file will not increase.
Additional NuGet packages might bring in extra NetStandard specific dependencies (which could previously have been handled by the .net / mono framework itself)
I have PCL Library and I want to add it to standard (.net 4.6) C# console application. Everything is fine as long as I don't use any PCL specific classes inside the library. And if I do, I get an error "unsupported PCL profile". This error is not googlable. But the same library works fine in UWP application. I am searching for a solution or official explanation why I can't use PCL in non UWP application.
Yes you can. PCL is basically intersection of available API's across different platforms. The disadvantage is that the more target platforms you choose the smaller is the intersection:
Another disadvantage of PCL is that it generates separate assembly for each platform.
That's why Microsoft comes with .NET Standard - a replacement of PCL that uses different approach.
Think about .NET Standard as an interface, that defines set of API's. Then the platforms like .NET Framework, .NET Core, Xamarin.iOS, Xamarin.Android will implement the .NET Standard.
interface NetStandard1_0 {
}
interface NetStandard1_1 : NetStandard1_0{
}
interface NetStandard1_2 : NetStandard1_1{
}
net46: NetStandard1_6 {
}
dnxcode46: NetStandard1_6 {
}
As a result, you won't target specific platforms, but a version of .NET Standard instead. When your library targets .NET Standard, it can be used in any platform that implements the .NET Standards. Another advantage is you wont need separate assemblies for different platforms anymore. There will be single assembly that runs just everywhere.
However, I recommend you to wait until April 2017 when .NET Standrard 2.0 should be released. Microsoft promised that all platforms (.NET Framework, .NET Core, Xamarin.iOS, Xamarin.Android) will support this version of .NET Standard and it will have official support in Visual Studio. Also, Visual Studio projects using project.json will be converted to .csproj, so all Visual Studio projects will use the same format and it will solve a lot of compatibility issues. Cleanning of the mess that appeared in .NET last years was absolutelly necessary
Sure you can.
Just add .NET 4.6 to selected platforms:
It's appears at time when you create PCL.
More information here:
Cross-Platform Development with the Portable Class Library
Or you can change platforms in existing PCL. Just go to properties page and you will see:
Here is a good blog post about how to call UWP API from desktop App:
How to call UWP APIs from a desktop VB/C# app
I was writing up the supported platforms for my PCL recently, one of which is other PCLs. I was confused if my library (which targets .NET Framework 4.5 and Windows/Phone 8.1) can be used in .NET Core projects as well.
As I understand it, PCLs allow you to share code across multiple platforms without recompilation, while .NET Core does that as well. The only difference is that .NET Core targets a few more platforms, i.e. OS X and Linux, and is open source.
So essentially, I don't see how .NET Core is any different than Microsoft rebranding the PCL and saying "PAY ATTENTION we're going open source and targeting non-Windows platforms!"
So the bottom line is, are PCLs compatible with .NET Core, and vice versa? What's the difference between them?
There is a beautiful article series about it which solved my questions around it ...
https://oren.codes/2015/06/16/demystifying-pcls-net-core-dnx-and-uwp-redux/
https://oren.codes/2015/07/29/targeting-net-core/
.Net Core has all his libraries (e.g. System.IO) in separate NuGet packages (each of them available for the SDKs DNX, UWP and .Net 4.6). Third party libraries target dnxcore50 (DNX) or uap10.0 (UWP) if they access the platform natively or rely on their features. If they do not access the platform but only rely on other packages, they should target dotnet.
dotnet effectively means: I am compatible with any platform which satisfy my dependencies (your library XYZ "dotnet" which uses System.Reflection dnxcore5+net45 could not be used by a UWP uap10.0 app). This effectively ends the combinatoric nightmare of the platforms. The previous target combination dnxcore5+net45 created an intersection between the platforms libraries and each addition would make the situation even worse. dotnet on the other side does not restrict the library on a target but instead forwards this restriction decision to its dependencies (where suddenly new restrictions like the famous unicorn platform can show up).
Therefore as a library author you can target dotnet if you just need other libraries.
Answering your question:
Your PCL is compatible with .Net Core style environments like DNX and UWP if you add the target dotnet, dnxcore50 or uap10.0 depending on the need of your library (see Owen's article for same basic compatibility with the contract Profile 259).
.Net Core is much more than a set of PCLed libraries. It is a new CLR, a new organized framework (packaged in small parts) and the infrastructure for new .Net SDKs (DNX, UWP, and whatever comes next). The term ".Net Core" targets both, the base class library "CoreFx" and the CLR "CoreCLR". But the real platforms are in reality DNX (by ASP.Net team) and UWP (by Windows team).
All of that answer is my current understanding of the .Net Core library situation. It is work in progress, and like mentioned in the posts, not yet public documented.
NOTE DEC 2016: Be aware, dotnet as the predecessor to netstandard1.x has changed in its concept starting with netstandard2.x (.NET Core 2.0; ~JUN 2017). Beginning with netstandard2.0 there will be one common contract (the netstandard.dll) which all platforms (.NET Core, .NET Framework, Xamarin, Mono, Unity3D) implement. This contract will be extended over time and the platform have to either drop support for the latest standard, throw NotImplementedException or implement it.
My understanding is they both are in concept different.
.NET Portable built upon the .NET Full, .NET Core, Windows Phone,etc, as sort of 'bridging layer'.
It actually has no concrete implementation, consider it a 'Package' of assemblies of the 'Interfaces'(contracts).
The scope of .NET Portable 'Package' is dynamic, depends on what 'Targets' platforms you are going to 'bridge'. It's a intersection of the platforms you target, the more platforms the smaller package.
During runtime, this Portable layer is hooked/adapted to the real implementation of .NET full, .net core or...