Microsoft.EntityFrameworkCore.Tools.DotNet v2.0.1 - entity-framework

Currently Microsoft.EntityFrameworkCore.Tools.DotNet V2.0.1 is showing a dependency of .NetCoreApp Version = 2.0
Any reason why that isnt version >=2.0 ?
Any idea when support for the more recent versions of
.NetCore SDK will be available
EDIT: Added screenshot
See dependency listed as .NetCoreApp = v2.0 and not .NetStandard = V2.0 or >= CoreApp V2.0 for similar packages.
edit2:
I ran the following new Project tests:
i still think there is an issue here.
I have .netcore sdk 2.1.4 installed
I started with brand new solution in VS2017 15.5.5
I create a new core project
netcoreapp2.0
and a new standard project
netstandard2.0
These packages
o Microsoft.EntityFrameworkCore.tools v2.0.1
o Microsoft.EntityFrameworkCore.design v2.0.1
o Microsoft.EntityFrameworkCore v2.0.1
o Microsoft.EntityFrameworkCore.Sqlite
can all be successfully installed in both projects
netstandard2.0
and
netcoreapp2.0
However:
Microsoft.EntityFrameworkCore.Tools.DotNet v2.0.1
can not be installed in netstandard2.0 project, which I can live with and the error makes some sense.
Restoring packages for C:_Dev\PJSTest\PJSStd\PJSStd.csproj... Package
Microsoft.EntityFrameworkCore.Tools.DotNet 2.0.1 is not compatible
with netstandard2.0 (.NETStandard,Version=v2.0). Package
Microsoft.EntityFrameworkCore.Tools.DotNet 2.0.1 supports:
netcoreapp2.0 (.NETCoreApp,Version=v2.0) Package restore failed.
Rolling back package changes for 'PJSStd'. Time Elapsed:
00:00:00.1634807
========== Finished ==========
BUT
Microsoft.EntityFrameworkCore.Tools.DotNet v2.0.1
can not be even be installed in a netcoreapp2.0 project
Restoring packages for C:_Dev\EFTEST\EFCore\EFCore.csproj... Detected
package downgrade: Microsoft.NETCore.App from 2.0.3 to 2.0.0.
Reference the package directly from the project to select a different
version. EFCore -> Microsoft.EntityFrameworkCore.Tools.DotNet 2.0.1
-> Microsoft.NETCore.App (>= 2.0.3) EFCore -> Microsoft.NETCore.App (>= 2.0.0) Package restore failed. Rolling back package changes for
'EFCore'. Time Elapsed: 00:00:01.1413809
========== Finished ==========
I think there is an issue with versioning on the CoreApp dependency.

I'm happy to be corrected, but my understanding is that .NetCoreApp (v2) is the platform, whereas .NetCore.App (v2.0.5, currently) is the set of API's that target that platform.
So the fact that Microsoft.EntityFrameworkCore.Tools.DotNet V2.0.1 only points to .NetCoreApp,Version = 2.0 means it can only support the apis from that platform... which says nothing about what platforms those dependencies support. e.g. you if you take a further and look inside at the Microsoft.NetCore.App dependencies, you will see listings under .NetCoreApp,Version = 1.0 up to 2.0.
EDIT: My understanding of various .NET core versioning landscape goes as follows:
The .NET Core SDK version is 2.1.5. This allows the building of .NET standard and .NET core apps.
The Microsoft.EntityFrameworkCore.Tools.DotNet version is 2.0.1. This references .netcoreapp2.0
.netcoreapp2.0 is the platform that implements Microsoft.NetCore.App, which is currently version 2.0.5 of the runtime.
The key part of netcoreapp2.0 is its dependence on .NETStandard.Library (netstandard2.0) but netstandard2.0 does not depend on netcoreapp2.0. I think this answer explains it better than I can. So the EntityFramework cli tools won't work on a library that uses .netstandard2.0 because it targets .netcoreapp2.0. Incidentally, EFCore does work - because it targets .netstandard - just the tools won't.
In summary, the SDK that you have, at version 2.1.4, already contains the necessary .NET Core platforms and runtimes. So no downgrade to the original version 2 is required. What needs to happen is that the csproj has to be updated to target the .NET Core runtime instead in order to use the tools: <TargetFramework>netcoreapp2.0</TargetFramework>.
EDIT2: Here's a sample of a csproj file that targets .netstandard (so that UWP can reference it), and is able to use the EFCore tools.DotNet:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="2.0.1" PrivateAssets="All" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="2.0.1" />
</ItemGroup>
</Project>
The Microsoft.EntityFrameworkCore.Tools is a package reference that targets .NET Standard. the Microsoft.EntityFrameworkCore.Tools.DotNet is a tools reference and is treated differently to package references. So the versioning and targets are also a little different.

Related

Update version of package that's internally referenced from another package

My project uses .NET Standard Library version 2.1.0. One of the packages that it references is System.Net.WebSockets.Client version 4.0.2.0. This package in its turn has a dependency on System.Security.Cryptography.X509Certificates version 4.1.0. As a result, when I restore before build, this particular version gets downloaded. The issue is version 4.1.0 of System.Security.Cryptography.X509Certificates has a known vulnerability and should get updated to 4.1.2 which has the vulnerability fixed.
I am not sure how to update the version of a package that is being internally referenced from another package which itself is part of the .NET Standard Library.
I am getting flagged in my build for using the non-compliant version of the X509Cerificates package. Any pointers in this regard would be much appreciated.
Thanks.

Mac - VS 8.10 - New 3.1 Project - Install Postsharp

I created a new, console application. Nuget => Add PostSharp =>
Reading project file
/Users/jason/Projects/Postsharp/Postsharp/Postsharp.csproj.
Restoring packages for
/Users/jason/Projects/Postsharp/Postsharp/Postsharp.csproj...
Restoring packages for .NETCoreApp,Version=v3.1... Resolving conflicts
for .NETCoreApp,Version=v3.1... Cycle detected. Postsharp ->
PostSharp (>= 6.10.6). Checking compatibility of packages on
.NETCoreApp,Version=v3.1. Checking compatibility for Postsharp 1.0.0
with .NETCoreApp,Version=v3.1. Checking compatibility for Serilog
2.10.0 with .NETCoreApp,Version=v3.1. All packages and projects are compatible with .NETCoreApp,Version=v3.1. Package restore failed.
Rolling back package changes for 'Postsharp'.
Cycle Detected?
Geez, what am I doing wrong?
Thanks,
Jason
This is caused by naming your project PostSharp and having a dependency on the package of the same name.
Daniel, you were right, the project name was part of the problem.
The biggest issue was I needed to manually set PostSharpDependencyRestoreDisabled=True and then I had to manually add all the referenced Nuget packages. It was annoying, but at least it works now.
Thanks!

Azure Devops - Compatibility problems moving from .NET Core 3.1 to .NET 5 at Nuget Package

I have a .NET Core solution which was running well using .NET Core 3.1 using a Pipeline on Azure Devops. Everything was working fine on the Pipeline.
After moving from .NET Core 3.1 to .NET 5.0, I started to have some strange troubles running the pipeline, specifically with Nuget packages.
I can build with no problems, but when it starts to pack using Nuget Package, I've got this error:
[error] The nuget command failed with exit code(1)
NU1202: Package Microsoft.EntityFrameworkCore 5.0.0 is not compatible with net50 (.NETFramework,Version=v5.0). Package Microsoft.EntityFrameworkCore 5.0.0 supports: netstandard2.1 (.NETStandard,Version=v2.1)
Some weird fact is that this solution is running fine at the local machine.
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<Version>1.8.8.9</Version>
<PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
I already tried to change the OS on the Build, but I've got this error:
The current available version of MSBuild is 16.7.0.37604. Change the .NET Core SDK specified in global.json to an older version that requires the MSBuild version currently available.
Does someone have an idea?
Package Microsoft.EntityFrameworkCore.Relational 5.0.0 supports:
netstandard2.1 (.NETStandard,Version=v2.1)
This is because it was using an old version of Nuget. You can try to change it to 5.x and restore.
Here is a case with similar issue you can refer to.

Dotnet restore not working

dotnet Version: 1.1.0 (global.json)
NuGet Version : 4.4.1.4656
VS2017 v15.5.2 (as Administrator)
.NET Core 1.1
The solution I am trying to build
Update I:
I just changed the project to run under target framework .NET Core v2.0 & sdk version 2.1.3 and I only get these kind of errors:
Severity Code Description Project File Line Suppression State
Error NU1202 Package Microsoft.Extensions.FileProviders.Physical 1.1.0
is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0).
Package Microsoft.Extensions.FileProviders.Physical 1.1.0 does not
support any target
frameworks. AspNetCoreExample C:\Users\Admin\Source\Repos\Examples\src\AspNetCoreExample\AspNetCoreExample.csproj 1
Update II:
While the following solves the current issue, i am not sure if it solves the root cause for this issue.
Delete the global nuget.config file %AppData%/Nuget/Nuget.config.
I fixed this issue by doing the following:
I migrated the project to .net core 2.0 and changed the global.json to point to sdk 2.1.3.
Removed all references in AspNetCoreExample manually and added the latest version for all of them.
Issues with target framework 1.1
When doing a restore from the solution in VS 2017:
When doing the restore from cmd (dotnet restore)
Running dotnet restore in Package Manager Console
NuGet.targets(103,5): error : Access to the path 'System.Runtime.dll'
is denied
.NET Core SDKs installed:
.NET Host
Now when opening the solution I get:
Comparing the log entries you pasted to their AppVeyor build,
https://ci.appveyor.com/project/Autofac/examples
Your machine's NuGet configuration seems to be broken. Analyze that and fix the issues.
You should add this code to your .csproj file
<RuntimeFramework>2.0.3</RuntimeFramework>
This worked for me.

Unable to resolve dependencies. 'xxx' is not compatible with 'yyy constraint: zzz)'

We have a project that is utilizing a set of Nuget-based Azure libraries. One of them was published with a specific MIN and MAX dependency on Newtonsoft.Json (max version being 7)
This was a headache, because other libraries depend on 8+ version of Netwon and this specific Azure library is just fine working with any modern Json package.
In VS2013, we forced to install this Azure library with newer version of Json package thru nuget installer and subsequently, Nuget never gave us any issues installing/updating other libraries.
However, after upgrading to VS2017, we cannot update any package (or at least the ones that depend on Json) and we get the error below.
Unable to resolve dependencies. 'Newtonsoft.Json 8.0.3' is not compatible with 'Microsoft.Azure.Insights 0.15.0-preview constraint: Newtonsoft.Json (>= 6.0.8 && < 7.0.0)'
How do we have Nuget ignore that specific Azure library's unimportant MAX version dependence?
How do we have Nuget ignore that specific Azure library's unimportant MAX version dependence?
If you confirm that Azure library is just fine working with any modern Json package and you want use the Microsoft.Azure.Insights 0.15.0-preview and 8+ version of Newtonsoft.Json at the same time. I would like provide a workaround to you, hope this can help you.
Detailed Steps:
Install the package Microsoft.Azure.Insights 0.15.0-preview with its dependencies first.
Only uninstall the package Microsoft.Azure.Insights 0.15.0-preview, Keep dependencies installed.
Update the Newtonsoft.Json to the version 8+.
Install the package Microsoft.Azure.Insights 0.15.0-preview in the Package Manager Console with following NuGet command:
Install-package Microsoft.Azure.Insights -IncludePrerelease -IgnoreDependencies
With the option -IgnoreDependencies, NuGet will ignore that specific Azure library's unimportant MAX version dependence:
Note: Need to mention is that if you update the Newtonsoft.Json package next time, you still need to follow the steps above to upgrade your Newtonsoft.Json package.