ASP.NET Core - 2.1 to 2.2 Issue - asp.net-core

Visual Studio 2017 15.9.18 on Windows 10
I have an ASP.NET Core Project that I need to update the Target Framework from 2.1 to 2.2
After changing the Target Framework, I cleaned an re-built the project.
I now get a compile error saying that says one of the assemblies in my project uses 'Microsoft.AspNetCore.Http.Abstractions, Version=2.1.1.0 which has a higher version than referenced assembly 'Microsoft.AspNetCore.Http.Abstractions' with identity 'Microsoft.AspNetCore.Http.Abstractions, Version=2.0.1.0
In my project dependencies I have Microsoft.NETCore.App 2.2.0 installed. I was going to update this but in package manager the Update button is disabled, saying "Implicitly referenced by an SDK. To update the package, update the SDK to which it belongs." The versions available show they go up to 2.2.8
Using Nuget Package Manager I installed Microsoft.AspNetCore.Http.Abstractions 2.1.1.0 and that seemed to work in debug, but after publishing, my site fails to load.
Should I be manually updating the version of Microsoft.NETCore.App, or is it fine to just update the Microsoft.AspNetCore.Http.Abstractions?
I added the following to my project file:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<RuntimeFrameworkVersion>2.2.0</RuntimeFrameworkVersion>
</PropertyGroup>
I also noticed some invalid sections in my publish profile:
I also read somewhere that I should add:
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
but SetCompatibilityVersion does not appear as a method.

I would discourage upgrading from .NET Core 2.1 to .NET Core 2.2 at this time.
Today's date is 1/4/2020 and as of December 23, 2019 .NET Core 2.2 is at the End of Lifecycle (EOL)
If you're going to spend the time migrating your code at this time, you should move to a version of .NET Core that is going to receive patches if there is anything broken or there are any vulnerabilities.
You can see the EOL dates here https://dotnet.microsoft.com/platform/support/policy/dotnet-core

Related

How to update from Microsoft.NetCore.App 2.0 to 2.1.4

I created an ASP.NET Core Web API project in Visual Studio 2017 version 15.7.2.
When I created it, it was Microsoft.NetCore.App 2.0.
Now I want to update to Microsoft.NetCore.App 2.1.4 but I can't because Visual Studio tells me:
Implicitly referenced by an SDK. To update the package, update the
SDK to which it belongs
I download the latest version of .NET Core and I installed it, but I got the same issue.
Any ideas?
Don't confuse SDK (=> Build tools) versions with .NET Core versions.
The 2.1.* SDK versioning was unfortunate, the versioning scheme has since been changed and the scheme transition will be (mostly) complete with the release of .NET Core 2.1.
You don't need to update the Microsoft.NETCore.App NuGet package as it only contains build references needed to build your application.
For self-contained applications, you can also set the <RuntimeFrameworkVersion> property inside the csproj file, but starting with the .NET Core SDK 2.1.300, you no longer need to as it will know about the latest versions.
As Martin points out above, the SDK and .Net Core Runtime are separate entities.
I went to https://www.microsoft.com/net/download/windows and downloaded the latest SDK (2.1) and installed it on my local machine. You'll need to close any open VS instances to complete the SDK installation.
Open your project's csproj file and update netcoreapp2.0 to netcoreapp2.1 and while you're at it you can update the "Microsoft.AspNetCore.All" to version 2.1. This will save you from having to update the nuGet package.
Worked for me. Best of luck.

Visual Studio 15.3.1 can't find core DLLs after update

I'm getting the runtime error:
InvalidOperationException: Can not find assembly file mscorlib.dll at '...\bin\Debug\net462\refs,...\bin\Debug\net462\'
This had not been a problem until I updated to version 15.3.1 this morning, and installed the .Net Core 2.0 SDK.
The DLL's are present in my ~\.nuget\packages folder. I'd had the same issue with the "Microsoft.Csharp.dll" assembly until I copied and pasted it into the stated folder.
I tried specifying to use .Net Core 1.1.0 via a global.json file, but then I get the build error:
The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK.
This error goes away if I clean the solution then restore Nuget packages via Command Line- not via the GUI. However it comes back if I change the version of a nuget package.
OK, this seem slightly different to my issue here: Visual Studio update 2017 15.3.1 forces ASP.NET Core SDK 2.0, which then doesn't find "reference assemblies"
If you install the SDK 2.0 from https://www.microsoft.com/net/download/core
You will then "probably" be able to build and run the project again but you'll be back to having the missing Microsoft.CSharp.dll / mscorelib.dll error.
If you then make sure the dependency is correct for the netstandard version:
<DependsOnNETStandard>netstandard1.5</DependsOnNETStandard>
See here: https://learn.microsoft.com/en-us/dotnet/standard/net-standard for the right version for you. My project is using core 1.1 targeting the full framework 4.6.1 and targeting netstandard1.6 has worked for me.
The final piece of the puzzel, was found on the GitHub issues here: https://github.com/dotnet/sdk/issues/1488
Add the following to your references in the .csproj file:
<PackageReference Include="Microsoft.Extensions.DependencyModel" Version="2.0.0" />
This will then build the project as a 1.1 project, but using the 2.0 SDK (which from what I can tell, it's supposed to do!). I can now run the project, update packages and generally got on with my work!

How do I prevent installing nuget packages that aren't 100% .Net Core 2.0 compatible?

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

How to write microsoft event log in asp.net core 1.1?

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" />

When updating to .NET Core 1.0 RC2 should "/Program Files/DNX/" be deleted?

These instructions https://www.microsoft.com/net/core#windows indicate that all previous version of .NET Core should be removed from Windows via the Add/Remove Programs before installing .NET Core SDK 1.0 RC2 on Windows.
However after running the uninstall from Add/Remove Programs in Windows 7 and installing .NET Core SDK I see that my /Program Files/DNX/ folder still exits.
This makes me wonder if I should delete it to clean up the system. But perhaps it's needed when working with older projects that were created with RC1 under DNX.
I'd like to know if it's ok to delete the dnx folder and it associated runtimes?
It's up to you. If you leave them there nothing bad will happen because the executables have different names (dnx/dotnet).
You can have dnx and dotnet side by side.
You should not delete this folders if you have old (DNX-based) projects that you still want to run. Otherwise, you will need to reinstall the dnx runtimes again to work with your old (RC1) apps.
Your new (RC2, dotnet cli) projects will known nothing about this old dnx-based folder and will ignore it completely.
Microsoft advise you to remove any old version of .Net Core. The DNX was the runtime and toolset used to build .Net Core and .Net Core apps as per Microsoft. It was consisted of DNVM, DNX and DNU.
With the .Net Core CLI all above (DNVM, DNX and DNU) are part of a single toolset.
You'll may find some issues when removing DNX, also when migrating a existing solution on any beta/rc version of clr or coreclr which were (dnxcore50 or dnx46) and others deprecated now.
NOTE: when uninstalling MS ASP.NET 5 RC1 Update 1 (old version), you
may have issues on your VS 2015 regarding to some projects templates,
existing MVC or WebAPI projects may not load.
I'd suggest you to migrate to .Net Core 1.0 as I did in my side, it was a little pain but you won't go anywhere with a project target to a deprecated version.
You can follow these links to migrate your app:
1) https://chsakell.com/2016/05/21/migrating-asp-net-5-rc1-apps-to-asp-net-core/
2) http://dotnet.github.io/docs/core-concepts/dnx-migration.html