I am not looking to downgrade a Nuget package, but Nuget itself. I am trying do downgrade from 6.2 to 6.1 as 6.2 is causing nuget errors for my project after upgrading.
You can download latest and previous versions of Nuget on their official download page: https://www.nuget.org/downloads
Related
Whenever I try to install any package from Nuget through Visual Studio 2022 - be it the GUI or package manager console, I can't seem to find a way to get the highest dependency version.
For example: if I add latest version 1.0.152 protobuf-net.Grpc to my project it has a dependency on Grpc.Core.Api >= 2.36.1. The current version for Grpc.Core.Api is 2.46.3...
In the GUI under options I have no option to control dependency version what so ever it seems like the Install-Package cmdlet doesn't obey -DependencyVersion Highest:
Install-Package protobuf-net.Grpc -DependencyVersion Highest
Installing NuGet package protobuf-net.Grpc 1.0.152.
Committing restore...
Successfully installed 'Grpc.Core.Api 2.36.1'
Successfully installed 'Microsoft.NETCore.Platforms 2.1.0'
Successfully installed 'protobuf-net 2.4.6'
Successfully installed 'protobuf-net.Grpc 1.0.152'
Successfully installed 'System.Memory 4.5.3'
Successfully installed 'System.Private.ServiceModel 4.5.3'
Successfully installed 'System.Reflection.DispatchProxy 4.5.0'
Successfully installed 'System.Security.Principal.Windows 4.5.0'
Successfully installed 'System.ServiceModel.Primitives 4.5.3'
How can I force Nuget to install the highest dependencies version?
According to your description here are some suggestion:
First check your project type “-DependencyVersion Highest” only used in packages.config format.
You can see the project type support about two package management formats: Projects.config and PackageReference.
Someone posted a similar issue on github, see the issue here. Hope this help you.
If you want to use “Grpc.Core.Api 2.46.3 “, you can try to delete the bin and obj folder and then go to Tools>Options>Nuget Package Manager>General>Clear All Nuget Caches.
Then you can install Grpc.Core.Api 2.46.3 package before install protobuf-net.Grpc 1.0.152
Is there any setting in proget nuget server which can make it treat version 1.0.1.0 = 1.0.1
So basically when any of the version's package is tried to restore then it will return 1.0.1.0 version's package.
Because I have a package with version 1.0.1.0 in my project but whenever I try to restore it, it always try to look for 1.0.1, skipping the last zero and so it throws error that the package does not exist. Because proget server has 1.0.1.0 version.
It works when I use my local folder as nuget source in visual studio. Because from local folder it restores the version 1.0.1.0 because it seems for local folder somehow it treats 1.0.1.0 = 1.0.1
Any idea?
Is there a setting in proget nuget server to make it consider version
1.0.1.0 = 1.0.1
ProGet nuget server does not have an option to make it consider version 1.0.1.0 = 1.0.1.
I think the package is packed by on old nuget cli <=v 3.3.0. And since nuget v3.4.4, nuget will remove the fourth node if it is zero automatically.
And the latest VS and nuget will ignore the fourth zero node of the package version if you install your package version 1.0.1.0. See this official Microsoft document.
So if you install it from local source or nuget.org, on these sources, it will remove the last zero from the source path.
However, on ProGet server(third party nuget server and not Microsoft), it still retain the fourth zero node of the package version. So when you install this package on VS, it shows the version 1.0.1.0 in packages.config file and when you restore it, it will find version 1.0.1 since the new rule of nuget.
And actually, when you enable the ProGet package source, it can still find version 1.0.1.0. In my side, although it still shows version 1.0.1.0 and vs have to catches 1.0.1 during restore process, the project will still works well.
So I suspect there is some deviation between you and my environment.
This is my test process:
For an example
This is my package:
In VS, it shows version 1.0.1.
But, on ProGet nuget server, it shows version 1.0.1.0.
Suggestion
First, try to clean nuget caches first or delete all files under C:\Users\xxx\.nuget\packages.
Then enable the proget nuget server package source and remember to check it:
============================================
If you still face the error, you could follow these below:
As a suggestion, you could upload your package on nuget.org, and it will automatically cull your package to version 1.0.1 and then it will synchronize to the ProGet nuget server.
When I upload the version 1.0.1.0 on nuget.org, it shows version 1.0.1:
I was using .Net Core 2.1.1, and recently updated the SDK to 2.1.401 (.Net Core Runtime 2.1.3). When i create a new project the version of Microsoft.AspNetCore.App under Dependencies > SDK is still 2.1.1. Looking at the properties of Dependencies > NuGet, the package is being referenced from "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.aspnetcore.app\2.1.1"
I tried installing Package 2.1.3 using NuGet package manager, and it downloaded all dependencies from NuGet despite that i have 2.1.3 already installed on my machine.
How do i force existing / new project to use the latest version of packages from the SDK install ?
You shouldn't need to update the version of Microsoft.AspNetCore.App manually in your project. 2.1.1 is perfectly fine. Your application will run on the latest 2.1.* framework installed on the machine.
If you publish a self-contained application, the tooling will automatically switch to the latest known version of 2.1.* at build time for the self-contained build only. (-r win-x64 argument)
This may or may not change for the 2.2 or 3.0 releases, read/follow this GitHub issue and thread for more information.
This is a bug as it has already been reported but for now this can be the solution.
In ProjectName.csproj file:
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeFrameworkVersion>2.1.3</RuntimeFrameworkVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.3" />
</ItemGroup>
I have .NET 4.6.1 and 4.5.1 and VS 2013
I am installing Npgsql 3.2.0 (PostgreSQL .NET provider).
It fails:
Attempting to resolve dependency 'NETStandard.Library (≥ 1.6.1)'.
'NETStandard.Library' already has a dependency defined for 'Microsoft.NETCore.Platforms'.
Any ideas?
Thanks!
The culprit is likely VS2013, or rather your version of nuget. Can you make sure you have the latest version of the nuget extension and retry?
This was resolved by installing the latest NuGet Package Manager, the latest version is 2.12.0.817
https://visualstudiogallery.msdn.microsoft.com/4ec1526c-4a8c-4a84-b702-b21a8f5293ca
Note that: Don't forget to restart VisualStudio.
I'm configuring a TFS 2015 build using the new scriptable system. During the build, when NuGet is retoring some packages, it fails with the following error:
The 'System.Collections 4.0.10' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
The 'System.Diagnostics.Debug 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Globalization 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Linq 4.0.0' package requires NuGet client version '3.0' or
above, but the current NuGet version is '2.8.60318.667'.
The 'System.Resources.ResourceManager 4.0.0' package requires NuGet
client version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Runtime 4.0.20' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
The 'System.Runtime.Extensions 4.0.10' package requires NuGet client
version '3.0' or above, but the current NuGet version is
'2.8.60318.667'.
The 'System.Threading 4.0.10' package requires NuGet client version
'3.0' or above, but the current NuGet version is '2.8.60318.667'.
BTW, I've installed Visual Studio 2015 in the whole build machine and I've checked that NuGet 3.1 is present in the extensions manager menu.
I guess TFS Build is using a different NuGet installation location, but I can't figure out where's looking for it and how do I update it from 2.8.x to 3.x.
There's a workaround to this problem.
By default, if you use VSBuild/MSBuild tasks, you can only choose whether to run nuget restore or not via the appropriate checkbox. But there is a separate task called NuGet Installer (it lives in the Package section). It exposes an optional field for the custom path to the NuGet.exe:
So, here is the idea:
Schedule NuGet Installer step before the appropriate VSBuild/MSBuild step
Specify correct custom path to NuGet.exe
Make sure Restore NuGet packages flag is off for the VSBuild/MSBuild step
NOTE: Your solution with replacing the physical executable directly in the build agent internals might work well up until the agent is updated (either on purpose, or somehow automatically) and overwrites NuGet.exe with newer, but still outdated version.
It was easier than I thought...
After checking the TFS build log I found the following string:
X:\TfsBuild\Agents\project\agent\worker\tools\NuGet.exe
restore
"X:\TfsBuild\Agents\project\c57207ab\path\to\solution\whatever.sln"
-NonInteractive
That is, when TFS build agent ZIP is downloaded from the TFS Web Access, it includes an outdated NuGet executable.
The worst part that there's no publicly available NuGet Command-Line 3.x executable, and I needed to use Google once I've found a post in the official NuGet blog pointing to a NuGet Command-Line 3.1 beta version executable I've replaced the one in the build agent tools location with the beta one, and the error got fixed.
The issue also affects XAML builds
If you want to work with XAML builds, you'll need to download the same NuGet Command-Line executable and copy it to C:\Program Files\Microsoft Team Foundation Server 14.0\Tools\nuget.exe and replace existing one...
I had the same problem. You need to use more recent version of nuget.exe. Version 3.5.0 soved my problem.
You can download Nuget distributions here: https://dist.nuget.org/index.html
There should be a .NuGet folder at the top of your solution. TFS will use the nuget.exe in this folder for package restore operations.
Visit this URL: https://dist.nuget.org/index.html
Download the latest nuget.exe
Delete the existing nuget.exe from the .nuget folder.
Use add/existing item to add the new nuget.exe to this folder.
Check in the change.
You should now be able to queue a build and have it restore packages successfully.