We Keep Coding

Different versions between a nuget package and its referenced nuget packages

I have an Azure Function (version 3, dotnet 3.1) referencing the following nuget package:
Microsoft.Extensions.Configuration
When I try to install this nuget, I get the version 5.x of the package, which causes the installation of
Microsoft.Extensions.Configuration.Abstractions
But I have conflicts when running my function. The solution found on several other topics, is to downgrade the nuget package, as the Azure Function doesn't support 5.0 dependency for the Microsoft.Extensions.Configuration.Abstractions package.
So I execute the following command line in the package manager console to install the initial nuget package:
Install-Package Microsoft.Extensions.Configuration -Version 3.1.14 -DependencyVersion Lowest
But it always install the version 5.x of the dependency "Microsoft.Extensions.Configuration.Abstractions"
Any advice to download the right version of the dependency?

I used the command you gave, everything seems to be no problem:
1. As Sara Liu-MSFT mentioned in the comments, you may need to check whether other assemblies reference Microsoft.Extensions.Configuration.Abstractions. If so, you may need to downgrade that assembly.
You can check here:
2. Or you can try to manually reference the Microsoft.Extensions.Configuration.Abstractions assembly:
<PackageReference Include="Microsoft.Extensions.Configuration.Abstractions" Version="3.1.14" />

Why do I have mismatched versions of .net core sdk in one solution

I have a single solution and when I try to consolidate the Microsoft.NETCore.App, it shows a mismatched set of versions and says that I have to update the SDK to the package. What do I need to do to resolve that?

Thanks for the pointer jmesolomon. I found the issue was that I had 2 references to the Microsoft.NETCore.App in the project's .csproj file. I removed the second one which includes the version reference and now all the projects are using 2.2.0
removed:
<ItemGroup>
<PackageReference Update="Microsoft.NETCore.App" Version="2.2.1" />
</ItemGroup>

You can use Visual Studio NuGet Package Manager to update that. The screenshot you provided looks like you've got the Nuget Package Manager already opened.
So are you going to go with version 2.2.1, 2.2.0 or the latest (2.2.3)?
I would probably just downgrade the project with the version 2.2.1 to 2.2.0 so you can build the solution right-away
To do so, un-tick all other projects except for the top one and you can choose to install the 2.2.0 version from the drop down.

Version for package `Microsoft.EntityFrameworkCore.Tools.DotNet` could not be resolved

I am deploying a new .NET Core application to my server. I'm trying to run the EntityFramework migration, as the project was created using the "code-first" method.
The command to be run is
dotnet ef database update
Migrations work locally using visual studio without issue, however, on the server, I receive the error;
Version for package Microsoft.EntityFrameworkCore.Tools.DotNet could not be resolved.
The version on my development machine of DotNet is 1.0.0
The version on my server of DotNet is 1.0.1
My project uses the .csproj file (not project.json, which is no longer used it seems).
I have added the reference to the csproj file, but regardless of the version I still get the above error.
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.0" />
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.1" />
</ItemGroup>
Update
Basically I have tried installing the Microsoft.EntityFrameworkCore.Tools.DotNet from the command line using NUGET:
C:\Program Files (x86)\Jenkins\workspace\api.XXX.com\XXXProject>nuget i
nstall Microsoft.EntityFrameworkCore.Tools.DotNet
Then I receive the following:
WARNING: Install failed. Rolling back...
Executing nuget actions took 13.44 sec
Package 'Microsoft.EntityFrameworkCore.Tools.DotNet 1.0.0' has a package type 'D
otnetCliTool' that is not supported by project 'C:\Program Files (x86)\Jenkins\w
orkspace\api.XXX.com\XXXProject'.`
Then if I run the dotnet ef command, I get this:
C:\Program Files (x86)\Jenkins\workspace\api.desully.com\deSullyAPI_Core>dotnet ef update database
Version for package Microsoft.EntityFrameworkCore.Tools.DotNet could not be re solved.
Update #2
I noticed that my dev machine has different SDK versions in it than the version on the server
Dev Box
Production Box
I'm assuming that the problem is that 1.0.1 doesn't have Microsoft.EntityFrameworkCore.Tools.DotNet in it? Isn't it strange that the older version does?
Update 3
So fyi - I went to the Microsoft Site to try to download the 1.0.0 version of the SDK (since it didn't seem to be installed on my server). Unfortunately, the MS site seems to force feed me the 1.0.1 version (which doesn't contain the EF stuff I need?).
I tried copying the 1.0.0 dir from my dev box to the production server, but that also didn't seem to work. What am I missing here?

There isn't a 1.0.1 version of Microsoft.EntityFrameworkCore.Tools.DotNet (at the time of writing). You need to set Version="1.0.0" in order to restore the package.
The available versions are listed on NuGet.
Update:
To use CLI tools, you first need to add <DotNetCliToolReference> items as you have already have.
Then you call dotnet restore in the directory of the project to download the packages to your local cache, then the tool becomes usable and dotnet ef can be used.

What helped in my case(.NET Core 2.0.3) was to issue:
dotnet add package Microsoft.EntityFrameworkCore.Design
And then
dotnet restore
This installed the Microsoft.EntityFrameworkCore.Tools.DotNet in a correct version

what worked in my case was using the cli including Microsoft.EntityFrameworkCore.Tools.DotNet Version="2.1.0-preview1-final, then after dotnet restore

Change Microsoft.EntityFrameworkCore.Tools.Dotnet version to an available version, then run this on the CLI: dotnet restore. Then try again.

To enable migrations in dotnet core:
1 open command prompt and change directory to the .csproj location
2 run the command 'dotnet restore' #This will download and make th next command availe in the location
3 When completed, run the command 'dotnet ef'

Update .net standard PackageReference from command line

We have a bunch of fast moving internal nuget packages.
We want the consumers of these packages to always be on the latest version. We currently do this on our CI system by running nuget update on the command line before build.
However we now are moving to .net standard/core. When we run nuget update on a .net standard csproj we get the following error:
Unable to update. The project does not contain a packages.config file.
Nuget still seems to be expecting a packages.config even though this has been dropped for .net core/standard csproj files.
How do we update PackageReferences to the latest version using the commandline for .net core/standard csproj projects?
UPDATE:
I've created a bug report incase this is a bug here: https://github.com/NuGet/Home/issues/4945

As a workaround, you should be able to run dotnet remove package followed by dotnet add package to update to the latest version of some package.

Nuget Update-Package not finding new versions of packages

I have a product with multiple services that have many solutions each. In order to reference things across services we are using Nuget to download and reference the dlls. Since we are still in early development of this product there are a lot of changes to the core dlls and we are having a lot of merging issues and annoyances with updating the references.
I tried using Update-Package -ProjectName XProject -Safe thinking this would do exactly what I wanted it to, update all the references with the same Major/Minor version. However, it just skips over all the files saying they are updated. When I look in Nuget it clearly notices that there is a new version so I am unsure what the problem is...
No updates available for 'Framework.EntityModel'.
No updates available for 'Framework.Core'.
in packages.config:
<package id="Framework.Core" version="1.0.14030.1137" targetFramework="net45" />
<package id="Framework.EntityModel" version="1.0.14030.1137" targetFramework="net45" />
There are versions in nuget with the label: 1.0.14034.1137 so I don't know why it isn't picking them up. I can open up package manager and update from there fine. I just want a way to easily update every reference without doing things manually.

This is taken from the Versioning page of NuGet # the bottom of the page:
Dependencies are no longer unnecessarily updated during package installation
Before NuGet 2.5, when a package was installed that depended on a
package already installed in the project, the dependency would be
updated as part of the new installation, even if the existing version
satisfied the dependency.
Starting with NuGet 2.5, if a dependency version is already satisifed,
the dependency will not be updated during other package installations.
The scenario:
The source repository contains package B with version 1.0.0 and 1.0.2.
It also contains package A which has a dependency on B (>= 1.0.0).
Assume that the current project already has package B version 1.0.0
installed. Now you want to install package A.
In NuGet 2.2 and older:
When installing package A, NuGet will auto-update B to 1.0.2, even
though the existing version 1.0.0 already satisfies the dependency
version constraint, which is >= 1.0.0. In NuGet 2.5 and newer:
NuGet will no longer update B, because it detects that the existing
version 1.0.0 satisfies the dependency version constraint. For more
background on this change, read the detailed work
item as well as the related
discussion thread.
Edit:
The above explains why you may be experiencing your issue, but to actually help to resolve it, take a look at http://blog.nuget.org/20131216/update-all-experience-explained.html. It shows you how you could use the DependencyVersion parameter of Install-Package or override the default behaviour in your nuget.config file to use "HighestPatch".
See the Install-Package section of http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference for more information.