Xamarin form: Does this give limitation access the libraries - xamarin

I have a problem with these packages which I wanted to use on my Xamarin form using .net standard 2.0
Package 'ExifLib.PCL 1.0.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Microsoft.Bcl 1.1.6' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Microsoft.Bcl.Async 1.0.165' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Mobilist.AdvancedTimer.Forms.Plugin 1.0.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'PCLStorage 1.0.2' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Package 'Rg.Plugins.Popup 1.0.4' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.
Does that mean I can't use this library any more?

Does that mean I can't use this library any more?
No, you should be able to use nearly all libraries that are PCL spec compliant inside of a .NET Standard 2.0 class library. You can checkout the .NET documentation to see list of PCL profiles with their supported platform and their corresponding .NET Standard supported version.
Package warning explanation
With .NET Standard 2.0 and the updated tooling in .NET Core SDK 2+ the .NET team wanted to make it easier to update or make use of .NET Standard libraries. The issue is that not all NuGet packages have been updated to support a version of .NET Standard. So they introduced a fallback targeting .NET Framework 4.6.1 which is nearly 100% compliant with .NET Standard (There are some API that are in the .NET Standard 2.0 spec that are not in .NET Framework 4.6.1 but they can be brought in via NuGet packages if required). So the warning you see is to inform you that the packages do not conform to a .NET Standard version you are targeting and as such may contain API's that are not executable in your runtimes making use of your .NET Standard 2.0 library.
Once you have tested that everything is working as expect you can add the NoWarn="NU1701" to your PackageReference in your csproj which will remove the warning. One thing to note adding NoWarn="NU1701" to a individual package does not remove the warning for dependencies. To remove those warning you must either include them as PackageReferences (via NuGet) or ignore NU1701 warning at a project level.
If you run into fallback issues you can adjust the target framework fallback via overriding the AssetTargetFallback in your csproj to something like:
<AssetTargetFallback>$(AssetTargetFallback);portable-net45+win8+wpa81;</AssetTargetFallback>

Related

What Non-4.* .NET App Versions play well with Standard?

I am building an MVC Web API (Service) with Views returned in specific cases. As an architectural decision, I've been directed to NOT build the service project in .NET Framework 4.*. Rather, I am to attempt .NET 5.0 first, and then Core 3.1 if 5.0 doesn't work.
This service project in my solution will depend on a few class library projects, call them DataLibrary, ComplexLibrary, and DocLibrary. DataLibrary will depend on a Nuget package of Oracle, be it ODP or Oracle Managed Data, in order to query an Oracle database via an Oracle Package on that database. DocLibrary will depend on a Nuget package of Aspose Word & Aspose PDF. ComplexLibrary will depend on Oracle AND Aspose.
Here's my dilemma:
Aspose Word's latest stable release (21.6) will report that it is compatible with 5.0 and Standard 2.0, but not .NET Core.
Oracle Managed Data reports that it is compatible with Standard 2.1 or Standard 2.0, but not 5.0 or .NET Core.
My own libraries have reported that they are not compatible with my API .csproj if...
3a. The API is 5.0 and the libraries are .NET Core or .NET Standard
3b. The API is Core 3.1 and the libraries are .NET Standard.
Since my compile script naturally requires a run of Nuget to retrieve all the necessary dependencies, I cannot get a clean compile because I seemingly have no combination of versions for my WebAPI and libraries that satisfy each others' compatibility needs. Since Standard libraries are the only common .NET version that satisfy the needs of both Aspose & Oracle, What available version for my WebAPI (i.e. I don't believe that Standard is an option for anything other than a class library) is compatible with .NET Standard libraries?
Thanks.
Please see the following article https://learn.microsoft.com/en-us/dotnet/standard/net-standard.
.NET Standard is not a framework it is kind f specification and .NET Core, .NET 5, Mono framework etc are .NET Standard implementations.
So for library projects I would select .NET Standard and for the service .NET Core or .NET 5 (which is actually the next version of .NET Core)
Well, don't I feel silly.
Turns out, the issue wasn't incompatibilities within Aspose, Office, .NET Core, 5.0, and Standard, but a failure of a prior version of NuGet to handle the different versions.
While my VS 2019 install was able to compile the whole solution effectively, my local install of NuGet was not. This was due to VS2019 likely using the most up-to-date version as of this post (5.9.#), while my locally installed version was 4.9.#. Thus, VS was able to sail through while my compile script kept failing at the NuGet stage (which I have included prior to the actual compile.) Once I ran a NuGet update, everything was good to go.
Long story short: KEEP YOUR NUGET VERSION UP-TO-DATE!!!

How to run dotnet restore forcing the restore to come from .NETStandard instead of .NETFramework?

I had a project which was created in .NETFramework. I have followed the steps on https://learn.microsoft.com/en-us/dotnet/core/porting/ to convert the solution to .NETStandard. In particular all projects in the solution have .NETStandard as the Target Framework There are several packages that are restored using .NETFramework when I clean and build the projects I get errors/warnings like the following:
Warning NU1701 Package 'EntityFramework 6.1.3' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8' instead of the project target framework '.NETStandard,Version=v2.1'. This package may not be fully compatible with your project.
Is there a way in the Package Manager console to run dotnet restore forcing the restore to come from .NETStandard?
Entity Framework 6.1.3 does not support .NET Standard at all, it only supports the .NET Framework; this is because EF 6.1.3 was released in 2015 before .NET Standard was even a thing.
You need to use Entity Framework 6.3.0 or later for compatibility with .NET Standard.
You should use the latest version: Entity Framework 6.4.4.

What is the relationship between the NetStandard.Library NuGet package and the Target Framework in project properties?

I have a .NET Standard class library project. I want the library to be available to the broadest array of consuming applications, so following Microsoft's advice here, I am targeting .NET Standard 1.3 in my project properties.
However, there is also a NuGet package called NetStandard.Library. And somewhere along the line, my project got a reference to this as well. What's more, it's a different version (1.6). I'm confused. Is this okay?
What is the relationship between these?
And somewhere along the line, my project got a reference to this as
well. What's more, it's a different version (1.6). I'm confused. Is
this okay? What is the relationship between these?
I think you should not worry too much about that.
1.6.1 is just the version of NetStandard.Library nuget package and it has nothing to do with the version of the target platform, and they don't interfere with each other.
The NetStandard.Library nuget package just service the related net standard project and provide any libs and apis to develop,build, debug the current project.
Besdies, NetStandard.Library 1.6.1 service net standard 1.x project while NetStandard.Library 2.0.3 services net standard 2.x projects.
So when you finishing developing it and pack your net standard 1.3 lib project as nuget package and then use it in target platform, actually, NetStandard.Library nuget package already finish its job and it is irrelevant in this step.
When you use such net standard project into other target platform projects, you only need to consider that whether the net standard version and the target platform version are within the scope of support as your linked document describes.
--------------Update 1-------------
Actually, sure.1.6.1 version is just only the nuget package version. NetStandard.Library 1.6.1 nuget package defines one or more standard.net version libraries.
And as far as I know, 1.6.1 version supports net standard 1.0~1.6 class library projects and the nuget package services for those net standard version.
And then it will direct the current project to the corresponding target platform projects.
Hope it could help you.

Using Microsoft.CrmSdk.XrmTooling.CoreAssembly in .netstandard1.6 class library

Are Dynamics CRM SDK assemblies compatible with the new .netstandard1.6 or older standards? I'm trying to use the Microsoft.CrmSdk.XrmTooling.CoreAssembly nuget package in a .netstandard class library. Are there any plans to make those libraries compatible with .netstandard 1.6 or 2.0 in future. Could not find the answer anywhere.
Currently no they only support .net 4.5. They may support .netstandard at some point in the future, but that would be speculation.
An easy way to tell currently is by looking at the NuGet package page and checking dependencies. For example another package CSVHelper supports .netstandard
While the SDK tooling package does not

Cannot import Oracle Client in ASP.NET Core RC2

With the new dotnet core, we can no longer import our referenced dlls externally, and instead have to get through a Nuget feed. I am trying to get Oracle.ManagedDataAccess Nuget package to work with my project, but no luck so far.
Here's the error in my project.json file:
Says The dependency Oracle.ManagedDataAccess >= 12.1.24160419 could not be resolved.
This is the error from Package Manager output:
Project Oracle.ManagedDataAccess is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Project Oracle.ManagedDataAccess supports: net451 (.NETFramework,Version=v4.5.1)
Does this mean I can no longer use this package? From what I've read so far, dotnet core does not support .net framework v4.5.1. If that is indeed the case, what are some alternatives I can use to connect to Oracle database?
I just looked at Oracle.ManagedDataAccess NuGet package and I don't think it can run on CoreClr. First, it has a dll that targets only net40 so it is likely it uses some APIs not available in CoreClr/CoreFx or relies on things being in the box/GAC. Second, it has native binaries in bin\x64 and bin\x86 subfolders. I think even if you forced this package into a netcoreapp1.0 it may not work. If they use DllImport attribute to import these dlls CoreClr will not be able to find them because the structure of a package containing native assets is a bit different in the new world. In my opinion because of this dependency your application should just target full .NET (e.g. net451 or newer).

Resources