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).
Related
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.
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.
This must be a bug of the NuGet Package Manager I'm using (version 4.6.0). I used the option DependencyVersion highest but it always picks the lowest version for dependencies.
Like this (I'm trying to install Serilog.AspNetCore with dependencies of 2.2.0 - the latest but 2.0.0 is always picked).
install-package Serilog.AspNetCore -DependencyVersion highest
One dependency it picks is Microsoft.AspNetCore.Http.Abstractions 2.0.0 but I expected it to pick Microsoft.AspNetCore.Http.Abstractions 2.2.0.
It's important because in my project the version 2.2.0 is required, Serilog should adapt that requirement by installing with that correct version of dependencies. But here I could not do anything to help it understand what I want.
Also the Install and Update options are not shown in the UI of NuGet Package Manager (the DependencyVersion could be selected there as well when using UI to install packages). So this appears to be some bug at least in the specific version of Nuget package manager I'm using.
What could I do to solve this issue? Can I try fixing the installed nuget manager (there is not any update in the Updates window). Thanks!
UPDATE
I've just tried a traditional .NET project, it works. But the problem raised when my projects target .NET Core (ASP.NET Core)? Looks like it does not support that feature for .NET Core projects?
The DependencyVersion switch is something used to control the behavior when NuGet looks for patch versions. It seems to be introduced after NuGet 2.8, but one point we should know is this option only supports packages.config format.
There are two package management formats:Projects.config and PackageReference.
1.For traditional .net project:It can use Packages.config or PackageReference to manage its nuget packages.But by default it uses packages.config.
2.For .net core projects(which uses new SDK-format project file):It uses new PackageReference format as its Package Management format.
More details about it see: Project Type Support
And someone had post this feature request in github, see the issue here.Hope it helps.
Update:
I expected it to pick Microsoft.AspNetCore.Http.Abstractions 2.2.0
Trying deleting the bin and obj folder first,
Then go Tools menu=>Nuget Package Manager=>Package Manager Settings=>Clear All Nuget Caches.(Sometimes it will delete the packages folder in C:\Users\lancel\.nuget\packages, we need to manually create a new packages folder)
Then install the Microsoft.AspNetCore.Http.Abstractions 2.2.0 package separately before installing the Serilog.AspNetCore package. Builds the application and you can check the output .dll by setting the CopyLocalLockFileAssemblies. In my machine it references 2.2.0 version of Microsoft.AspNetCore.Http.Abstractions.dll successfully. Hope it helps:)
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 using SignalR 0.5.3, installed via NuGet, for my .NET 4.5 Web Application - now, since I need to push data from SQL SERVER 2008R2 (supporting only the .NET Framework up to 3.5), I need to create a library using the SignalR .NET 3.5 Client.
I have seen in the project website that there is probably a SignalR.Client.NET35 version but (being not very familiar neither with github nor with NuGet) I have no clue how to install that client for the library project I have to work on.
I have tried installing with the std command install-package SignalR.Client but the message i get is:
Install-Package : Could not install package 'SignalR.Client 0.5.3'.
You are trying to install this package into a project that targets
'.NETFramework,Version=v3.5', but the package does not contain any assembly
references that are compatible with that framework.
For more information, contact the package author.
so it looks like the right .NET version is not picked correctly/out of the box.
Before bothering the author, i thought to give a try round here.
Any suggestions?
We haven't packaged the 3.5 client into the package as yet. You'll need to build from source.
I backported the v1.x and v2.x SignalR clients to NET 3.5. Available as NuGet packages here: http://www.nuget.org/packages/Nivot.SignalR.Client.Net35/