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" />
Related
I want to list down all the nuget packages along with its dependencies recursively.
Project is in VS2017 and .NET Core.
I tried with Get-Package -ProjectName "Your.Project.Name" it displays all the nuget packages in project. I want all the dependencies also printed.
You can use the dotnet cli: dotnet list package --include-transitive. The dotnet-outdated global tool probably has similar functionality.
I have 2 solutions:
SolutionMyTool
SolutionToolUsage
From SolutionMyTool there are produced NuGet packages
MyTool 1.1.0
MyTool 1.1.1
MyTool ... (many, many new versions)
On SolutionToolUsage side I have dependency
<PackageReference Include="MyTool" Version="1.1.*" />
Now on each build of SolutionToolUsage I want to get the latest version of MyTool.
Is it possible?
It seems that SolutionMyTool on 1st buiod gets "latest version" of MyTool (eg. 1.1.7).
Then each next build of SolutionMyTool is using this version (1.1.7), although in the meantime there were produced newer versions of MyTool.
How can I always get the "latest"?
Thank you ;]
Just use an asterisk for the version.
The following line loads the latest version on every build.
<PackageReference Include="MyTool" Version="*" />
https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#floating-version-resolutions
EDIT
Maybe you have also to restore the project's dependencies with
dotnet restore
The command dotnet build implicitly restores packages.
As of 2020-January NuGet behaves like here.
If SolutionToolUsage has dependency
<PackageReference Include="MyTool" Version="1.1.*" />
Then on 1st build is taken newest version (eg. 1.1.2) of MyTool.
Then on each next build is taken this version (1.1.2) even if newer are available in NuGet Feed.
If you need "asked flow" the simplest workaround is to manually:
increase version of each MyTool with each lib build
setting explicitly this version in SolutionToolUsage
Although Microsoft sometimes "recommends" uninstalling and installing again MyTool.
https://learn.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages
Reinstalling a package during its development: Package authors often need to reinstall the same version of package they're developing
to test the behavior. The Install-Package command does not provide an
option to force a reinstall, so use Update-Package -reinstall instead.
Trying to install the OpenIDConnect Nuget package to my project, which was targeting .NET Framework 4.5. That failed, with the error:
Could not install package
'Microsoft.AspNet.Authentication.OpenIdConnect 1.0.0-rc1-final'. You
are trying to install this package into a project that targets
'.NETFramework,Version=v4.5', but the package does not contain any
assembly references or content files that are compatible with that
framework. For more information, contact the package author.
So I look at the dependencies for the package, and see that "DNX 4.5.1" is listed:
Dependencies
DNX 4.5.1
Microsoft.AspNet.Authentication (>= 1.0.0-rc1-final)
Microsoft.IdentityModel.Protocols.OpenIdConnect (>= 2.0.0-rc1-211161024)
DNXCore 5.0
Microsoft.AspNet.Authentication (>= 1.0.0-rc1-final)
Microsoft.IdentityModel.Protocols.OpenIdConnect (>= 2.0.0-rc1-211161024)
System.Net.Http (>= 4.0.1-beta-23516)
... so I assumed that DNX is a useless abbreviation of ".NET" - who knows, maybe the field doesn't accept a '.' in the field, so they had to come up with something else. No worries, I'll just upgrade my project to .NET Framework 4.5.1 and try again.
... but that didn't work. I get the same error, but the error has the 4.5.1 version number.
I looked at the "install other frameworks" page and I don't see any "DNX" frameworks listed there.
What am I doing wrong?
What's with the "DNX" business?
How do I Install OpenIDConnect Nuget Package with Dependency on “DNX 4.5.1”
Just like Will said, this nuget package came out during the birth of .NET Core and you can also find this this nuget package is a just a pre-release version, microsoft has not officially released it. It has not been updated since 11/18/2015. Obviously,The NuGet team deprecated this package.
To resolve this issue, you can use the package Microsoft.AspNetCore.Authentication.OpenIdConnect instead of it.
Get it from: https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.OpenIdConnect/2.1.0-preview1-final
Hope this helps.
The scenario is package management with NuGet.
Suppose you have PackageA that depends on PackageB, you publish both of them so whenever you publish PackageA, you specify the version range of Package B you depends on.
Now both of the packages are automatically published with a Build, and they use SemVer (GitVersion.exe), version 6.0.0 of PackageA declares that it needs at least version 6.0.0 of Package B. This works perfectly if packages are in stable version.
Actually no 6.x.x stable version exists for both package and if I'm installing the prerelease version of PackageA it complains because it needs at least version 6.0.0 of packageB, but packageB has only 6.0.0-prerelease version.
Here is the error.
Unable to resolve dependencies. 'PackageB 6.0.0-unstable0066' is not compatible with 'PackageA 6.0.0-unstable0015 constraint: PackageB (>= 6.0.0)'.
My question is, how is the correct way to manage dependencies from pre-release version of packages?
Thanks.
For me, this is a clear bug at NuGet, because even if you explicitly add a reference to PackageB 6.0.0-unstablewhatever, NuGet claims that the packages are incomatible.
Or, to be more precise, it does that if you are using package references. If you use the old package.config format, NuGet is happy to accept the prerelease package.
I used Nuget to install ServiceStack.Text,ServiceStack.Client and ServiceStack.Common in version 3.9.7.0.
When trying to install ServiceStack.Interfaces version 3.9.7.0 it couldn`t find it.
If i still need the specific version of 3.9.7.0 what should i do?
I prefer to manage all my packages threw nuget..but if won`t have a choise i will use different solution.
In ServiceStack v3 the ServiceStack.Interfaces.dll was maintained in the ServiceStack.Common NuGet package, so to install a specific version of ServiceStack.Interfaces from NuGet you can specify the version you want:
Install-Package ServiceStack.Common -Version 3.9.70
See the v3 installation docs for other NuGet instructions.
The ServiceStack.Interfaces library for ServiceStack v3 was reset to 1.0.0.0 when v4 was released, in this commit.
You can see the version information for the library here:
https://github.com/ServiceStack/ServiceStack/blob/v3/src/ServiceStack.Interfaces/Properties/AssemblyInfo.cs