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
Related
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!!!
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.
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>
I am planning to use Enterprise Library for database access on a Web API project which is going to be built using .Net core app.
But I am unable to install Enterprise library using NuGet as the latest version of Enterprise Library is not compatible with.Net core app framework.
Note, I don't want to use Entity Framework.
Appreciate if the community can help on this.
If you can migrate your application to .Net Core 2.0 which is still in preview mode, but Microsoft promised to release it by Q3 2017, I have forked out the Enterprise Library project and ported that to .Net Core 2.0 which you can find it under this repository:
https://github.com/Chavoshi/EnterpriseLibrary.NetCore
And also this is the Nuget package for Data Application Block:
https://www.nuget.org/packages/EnterpriseLibrary.Data.NetCore
Still there are some missing parts such as OdbcFactory and OleDbFactory which they are not available in .Net ported APIs (Or Nuget package is not published yet), but I am keep working on them to maybe port them by myself or update it since the API will be available. I appreciate anyone who can contribute on this project as well. :)
Basically my question boils down to if SQLite-Net Extensions (NuGet Link) is compatible with Frank A. Krueger's SQLite-net PCL. As I understand it, at some point Oystein Krog created a fork to improve things in the past (possibly before Frank updated things?), so SQLite.Net PCL came into existence.
Now that there's an "official" PCL version by Frank, I'd like to stick to it instead of the fork. However, it's unclear if SQLite-Net Extensions actually only supports the fork or not. The site says it supports SQLite-net but the dependencies say SQLite.net. Any clarification for my (and future people's) sake would be extremely appreciated!!!
Edit: I know that "SQLite-Net PCL" is just the name of the NuGet package, not actually a standalone PCL. I have this (without SQLite-Net Extensions) fully working in my code within an actual PCL.
There's already a prerelease version (last updated on Saturday, August 13, 2016) for SQLite.Net Extensions-PCL (2.0.0-alpha1) that depends on sqlite-net-pcl (>= 1.1.2) from Frank A. Krueger
https://www.nuget.org/packages/SQLiteNetExtensions/2.0.0-alpha1
According to SQLite-Net Extensions documentation there is a flavor which is compatible with Frank A. Krueger's library but there is no nuget package that depends on Frank A. Krueger's nuget package
There is SQLite.Net Extensions-MvvmCross package which doesn't depend on SQLite.Net PCL but it depends on MvvmCross SQLite plugin which is unlisted from nuget.
SQLite-Net Extensions is provided in three different flavours,
depending on the SQLite-Net version that you are using:
SQLite-Net PCL version (also as NuGet package)
SQLite.Net.Async-PCL version (also as NuGet package)
MvvmCross SQLite Community version (also as NuGet package)
SQLite-Net standard version (also as NuGet package)
I think that there's a little confusion here, because Frank Krueger nuget package is not a PCL. You can't deploy a PCL library depending on a platform-specific library. Therefore you won't find a SQLite-Net Extensions package that uses that platform specific SQLite.Net nuget package.
However, you can just download the SQLite-Net Extension sources and copy the source files to your project. If you take a look at the sources, you'll see that, unless defined otherwise, it will use the Frank's SQLite package.
#if USING_MVVMCROSS
using SQLiteConnection = Cirrious.MvvmCross.Community.Plugins.Sqlite.ISQLiteConnection;
#elif PCL
using SQLite.Net;
using SQLite.Net.Attributes;
#else
using SQLite;
#endif
I haven't tested in some time, but it should work.
However I'd recommend you to stick to SQLite-Net PCL as it's actively maintained and currently evolving with more features (like asynchronous operations).