I have release version: 1.90. Is it possible to keep this version when I was doing patch updates for my library?
Currently when I am trying to publish with the version 1.90 it shows me the error: "Unable to process request. 'A package with id "TrakopolisAPI" and version '1.90 already exists and cannot be modified.''"
Change the minor version. Unless you can delete the old package i don't think you can publish with the exact same version number
Related
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.
I have published many versions of a Dart package, but I want to go back an update a previous version. Let's say I have published these versions:
1.0.0 - first version
1.1.0 - minor update
2.0.0 - major update with breaking changes
I would like to go back and publish version 1.2.0 with a small change to 1.1.0 code, but not use the 2.0.0 code. If I use pub publish with version 1.2.0, will it add it to the versioning list correctly, or will it use publish date order instead?
I believe that it should work correctly, and if it doesn't, it would be a bug that should be reported.
As an example, the versions of the path_provider package show that version 1.6.28 was uploaded after 2.0.0 and 2.0.1, but 2.0.1 (as of writing) is advertised as the latest stable version.
In my build pipeline, I have the following step:
I am getting the following error:
##[error]The nuget command failed with exit code(1) and error(NU1102: Unable to find package Microsoft.Windows.SDK.BuildTools with version (>= 10.0.19041.8)
When I go to the NuGet page for this package: Microsoft.Windows.SDK.BuildTools, I see that it only has one version: 10.0.18362.3-preview. I am not sure why the NuGet restore step is trying to get a higher version that does not exist. Why is this happening and how can I fix it? Note: this is my first Pipeline.
Agent Specification: Windows-2019.
From this page, you can see only two versions of the package Microsoft.Windows.SDK.BuildTools are listed:
10.0.19041.1
10.0.18362.3-preview
When open the page of version 10.0.19041.1, you can see the warning message to notify that this package version has been deprecated. But it seems that you can still download and install it.
I think the other package versions may have been permanently deleted by the owner due to some security vulnerabilities. So you no longer find them.
You can try to open your project using Visual Studio on your local machine, and change to use version 10.0.18362.3-preview in your program.
My packages.config has this entry:
<package id="xxxxxx" version="3.0.0" allowedVersions="[3.0,3.3)" targetFramework="net452">
Now there is no package xxxxxxx at version 3.0.0 (there might have been, once upon a time), but I am allowing anything between 3.0 and 3.3. I do have a package at 3.1.0, and I expected that nuget would find that one and pick it up, but I get the error
Unable to find version '3.0.0' of package xxxxxxxx
Questions:
Why does nuget not say, "oh I can't find 3.0.0 but I'm allowed to use anything from 3.0 to 3.3 and I have 3.1.0. I'll use that!"
What is the correct config to use to make it pick up the highest available version in the allowed range?
In packages.config, every dependency is listed with an exact
version attribute that's used when restoring packages. The
allowedVersions attribute is used only during update operations to
constrain the versions to which the package might be updated.
Source: https://learn.microsoft.com/en-us/nuget/concepts/package-versioning#references-in-project-files-packagereference
If you want to use ranges in your project, you will have to switch to References in project files (PackageReference), but keep in mind:
NuGet 2.8.x and earlier chooses the latest available package version
when resolving a dependency, whereas NuGet 3.x and later chooses the
lowest package version.
Option to always resolve to highest version was proposed and rejected: https://github.com/NuGet/Home/issues/1192
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.