I understand that .Net Core 2 has a compatibility shim that allows it use Nuget packages that don't specifically target .Net Core/Standard 2. This gives it access to 70% of Nuget. Great - nice feature.
How do I prevent installing nuget packages that aren't fully compatible with .Net Core 2/.Net Standard 2? Or warn me at point of installing that it is being used with the shim?
I created a new .Net Core 2.0 project installed EF 6.1.3 (which I knew didn't work) and nothing prevented me or warned that it didn't target .Net Standard <=2 at the point of install.
I am happy to "run with scissors" but I kind of feel I should be getting a warning before I install MVC5 and EF 6.1.3 into a .Net Core 2 application. I would really like to prevent junior devs from installing unsupported packages etc.
I guess further to Matt Ward answer - my main point is - can it be detected that something is actually 100% compatible at install or are we always just in the situation where we need to make determination ourselves that package works "well enough". I hoped that there was a technical mechanism that detected missing coverage API coverage and could tell us that the nuget package may not operate as it did before. So I guess MS say 70% compatibility - I want to fail if I try to install the 30%
Installing Entity Framework 6.1.3 into a .NET Core 2.0 project there is a NU1701 warning in the Errors window about Entity Framework 6.1.3 being restored using .NET Framework 4.6.1 and that it may not be fully compatible.
You could turn the NU1701 warning into an error in the project so you could not install any NuGet package that does not explicitly support .NET Core 2.0. This can be done by adding the WarningAsErrors property to the project.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<WarningsAsErrors>NU1701</WarningsAsErrors>
</PropertyGroup>
Then if you try to install Entity Framework 6.1.3 the restore will fail, the changes will be rolled back, and the NuGet package will not be installed.
You can also set the DisableImplicitAssetTargetFallback property to true which will prevent .NET 4.6.1 being added to the AssetTargetFallback property which is used when checking NuGet package compatibility with .NET Core 2.0 projects.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<DisableImplicitAssetTargetFallback>true</DisableImplicitAssetTargetFallback>
</PropertyGroup>
If you wan to be 100% sure, run the package against .NET Portability Analyzer and .NET Standard 2.0 profile.
It won't tell you if the API will be called or not (and is in no way an automatic process), just if the Assembly contains any API which is not .NET Standard 2.0 compatible.
However, you can also only run your application against the Analyzer, as the .NET Portability Analyzer should be able to follow any references made from the application and check these too.
Update
You can als build this into your build server pipeline, to get a more automatic guarantees.
The .NET Portability Analyzer Docs.
Visual Studio is not required for this, just download it from https://github.com/Microsoft/dotnet-apiport/releases and run
From the docs:
Type the following command to analyze the current directory: \...\ApiPort.exe analyze -f .
To analyze a specific list of .dll files, type the following command: \...\ApiPort.exe analyze -f first.dll -f second.dll -f third.dll
Old Answer (may be useful in conjcution with Matt's answer)
Untested, but give it a try:
<!-- old dotnet tooling/.NET Core 1.x -->
<PackageTargetFallback>netstandard2.0;portable-net45+win8</PackageTargetFallback>
<!-- new dotnet tooling/.NET Core 2.0 -->
<AssetTargetFallback>netstandard2.0;portable-net45+win8</AssetTargetFallback>
Typically you want to have it like
<!-- old dotnet tooling/.NET Core 1.x -->
<PackageTargetFallback>$(PackageTargetFallback);dotnet5.6;portable-net45+win8</PackageTargetFallback>
<!-- new dotnet tooling/.NET Core 2.0 -->
<AssetTargetFallback>$(AssetTargetFallback);dotnet5.6;portable-net45+win8</AssetTargetFallback>
Where $(PackageTargetFallback) will tell MSBuild to keep the old values and append the values after that to it. But since $(PackageTargetFallback) probably (can't look/dig deeper in right now) have the .NET Framework moniker there, you'll override it with your own values.
Additionally
Given that PackageTargetFallback is now deprecated, one should use AssetTargetFallback instead.
As far as I know .Net portability analyzer tool can not 100% determine the platform that does not support installation, such as system.runtime.Loader, after tool analysis, 100% supports the framework platform, but it does not
Screenshot of analysis results:analyse System.Runtime.Loader
Related
I have a question about .net Core project.
I have a .Net Core Project referencing other projects.
The problem is that a few projects show the warning saying that "Package 'XXXXX' was restored using .NetFramework, Version=v4.6.1.... instead of targer framework .NetCoreApp".
What kind of problems could I have?
Also can I deploy this in Linux for instance and still working fine?
warning showed
Thanks guys
Look at this thread - For a .Net Core 2.1 project, Why does Nuget restores .Net 4.6.1 packages?
What it basically means is the package you have loaded not suitable for .NET CORE, and was restored using a different version of .Net Framework.
Check if the package exists for .NET CORE (search thru NuGet Manager)
Regarding whether it will work on Linux or not - it depends on the package dependencies (e.g. if it is depending on WinForm for example, it probably won't work on Linux).
Even if it will work, I suggest finding a package suitable for .NET CORE.
i was able to get the sample asp.net embedded powerbi to work with my reports
now i have to migrate it aspnetcore
i was hopeful when i saw this post - seeing that someone was able to get it done
Embed Power BI Report In ASP.Net Core Website
so i:
started a new project with the aspnetcore
installed the powerbi package
now when compiling im getting this warning:
Package 'Microsoft.PowerBI.Api 2.0.11' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.0'. This package may not be fully compatible with your project.
i searched and couldnt find a powerbi package that was specific to aspnetcore
is there one? will there be a conflict crossing cores? or does it not matter?
UPDATE:
4.6.1 powerbi package does indeed work with aspnetcore 2
but looking forward to a powerbi package specifically coded for core
As you can see this is just a warning, not an error. That warning appears because .NET Core 2.0 applications can use some Nuget packages which target .NET Framework 4.6.1 (or less). However, this inclusion might fail if the referenced .NET 4.x package contains some API not included into .NET Core/.NET Standard 2.0
So, my advice - try to run your application. If it works well at the first glance - then, most probably that PowerBI package does not contain any not supported APIs and will work well further. If it fails right at start - then you will need to wait for the release of the new version of that package which targets .NET Standard 2.0.
I would like to write Microsoft event log in my application using Asp.net core 1.1. I have searched and got the extension "Microsoft.Extensions.Logging.EventLog". But I am unable to install on my application due to compatibility.
Is there any other possible solution to achieve event log in asp.net core 1.1?
Thanks in advance.
The compatibility problem you hit likely appears because you attempted to install the 2.0.0 version of Microsoft.Extensions.Logging.EventLog for your ASP.NET Core 1.1 application.
In preparation for the final release of ASP.NET Core 2.0, it appears that the NuGet packages were published early, which makes those the newest stable versions on NuGet causing the NuGet package manager in Visual Studio to pick those by default.
You have to be careful with which versions you pick when installing dependencies for ASP.NET Core. Especially soon, when 2.0 releases, you have to make sure to always pick the latest 1.x release for as long as you stay on ASP.NET Core 1.x.
In your case, you need version 1.1.2 of Microsoft.Extensions.Logging.EventLog which is the latest 1.x version for the dependency. So either pick that in the NuGet package manager, or change your .csproj to include the proper version:
<PackageReference Name="Microsoft.Extensions.Logging.EventLog" Version="1.1.2" />
I know VS 2017 is only RC but there seem to be some major issues with migrating an ASP.Net Core 1.0 project to 1.1. The migration tool fails converting 2 of my 8 projects in the solution (I prefer to adopt a layered architectural approach for my projects) the sample project is located here. One project in particular is the class library I moved my web api controller methods into. In trying to re-create this class library it doesn't seem one is able to declare a controller class after installing Microsoft.AspNetCore.Mvc nuget. It is installed but the compiler is not finding the Controller, RouteAttribute classes, etc. The same issue occured with trying to setup a DI layer IServiceCollection. Nuget Microsoft.Extensions.DependencyInjection doesn't seem to be doing it.
The migration log quite honestly isn't really helping me. It seems to indicate an issue with my service project and the project.json file but as you can tell it is in the repository.
It feels like Microsoft is forcing us down the path of cramming all the "web" stuff into a single project file. Maybe these tools aren't far enough along yet but an RC would indicate they should be closer to ship ready?
ReciPiBook.Api
Message
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Failed to migrate XProj project ReciPiBook.Api. 'dotnet migrate -s -p "C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api" -x "C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\ReciPiBook.Api.xproj"' exited with error code 1.
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Could not find file 'C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Services\project.json'. Migration failed.
src\ReciPiBook.Api\ReciPiBook.Api.xproj: Backing up C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\ReciPiBook.Api.xproj to C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\Backup\src\ReciPiBook.Api\ReciPiBook.Api.xproj.
src\ReciPiBook.Api\project.json: Backing up C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\src\ReciPiBook.Api\project.json to C:\Users\xxx\Documents\Visual Studio 2015\Projects\ReciPiBook2017\ReciPiBookCore\Backup\src\ReciPiBook.Api\project.json.
I can't directly speak to VS2017 as I'm staying away from it as even though it's a RC, the core tooling is in ALPHA. The VS 2015 core tooling is at least in a "RC" state (actually only preview).
In VS2015 I migrated from 1.0.x to 1.1 manually (per https://blogs.msdn.microsoft.com/dotnet/2016/11/16/announcing-net-core-1-1/):
Download the 1.1 sdk
Change your global.json "sdk":{"version": "1.0.0-preview2-1-003177"} (yes it's a different version string).
Update all the project.json package versions from 1.0 to 1.1 (some are preview some arn't). Just open up the nuget package manager, allow preview versions, then install all the updates.
Fix any of your project.json tool entries as the package manager clobbers those.
I started programming with .NET Core and ASP.NET Core and after reading many Docs/Tutorials i still am not sure of how to realize if a Nuget-(Meta-)Package is comptabile/usable within my .NET-Core-App.
How to check if a NuGet-Package is compatible with .NET Core.
E.g. the often recited Newtonsoft JSON. Is it compatible/usable - and how to see this?
Is there a list of all the available .NET Core packages?
(Like here it lists a few
key NuGet packages for .NET Core
). But since they say those are "key" packages i would assume there are more. But which?
The best way to understand compatibility is table here
In this table you can check what API version support NuGet package. If it is standard 1.0+ - it works with .Net Core
For checking (supported API version) dependencies on your package, you can check page of package on nuget.org or in your package manager
Here is an example for Rider
maybe that will be helpful - lots of popular packages https://github.com/thangchung/awesome-dotnet-core
I also don't see nuget.org mentioned anywhere so:
https://nuget.org
General rule of thumb for me is:
if package has a dependency on net standard or .net core, it will run with .net core(mind the versions also)
https://packagesearch.azurewebsites.net
Go to site and search for package to find its compatibility
Well, in fact you don't have to worry, the NET core application will indicate you if the package is compatible or not when you will run a dotnet restore command in your project.
Let say that you have the famous CSVHelper package registered in your csproj file :
<PackageReference Include="CsvHelper" Version="0.12.0"/>
Then, when you'll run any dotnet command such as build or run, you'll have the following input in the console in case of, here, cross-compatibility:
YourProjet/aspnetapp.csproj : warning NU1701: Package 'CsvHelper 0.12.0' 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 '.NETCoreApp,Version=v2.2'. This package may not be fully compatible with your project.
Basically, it mean that NET Core application can use ASP.NET NuGet package, and so far, I've never cross on a non-compatible package. Even if version is incorrect, the build will get the most recent matching version of the NuGet package.
Hoped it answer your question.