We use our private Artifacts Feed on Azure DevOps Server 2020.1 (on-prem). I get a feed MyFeed and a feed MyFeedTest. I use the MyFeedTest for Staging our NuGet Packages. When they are stable, they get pushed to MyFeed. If a NuGet package in the feed has a dependency on another NuGet package in the feed, I use the following line:
<PackageReference Include="ext.lib.MyPackage" Version="*" />
The issue here is that the Azure DevOps Server determines the dependency by itself, and it takes the Versions from the staging package in MyFeedTest for the packages in MyFeed even when the package MyFeedTest get unlist, even when the whole feed MyFeedTest get deleted.
The Azure DevOps Artifact should not determine the dependencies to another package by itself, and it should not ignore the defined dependency setting inside the package project file (Version="*").
In the end, my collogues get the following error in Visual Studio:
The Dependencies of the Package ext.lib.MyPackage on Azure DevOps Server looks like:
But to remember, the package ext.lib.DevExpress in Version 13.1.5.3 do not exist after deleting the whole feed MyTestFeed.
So how can I solve that? Is it possible to configure the Azure DevOps Server to not behave like this? We can't use staging with that mechanism.
The issue here is that the Azure DevOps Server determines the
dependency by itself
This is not determined by Azure DevOps Server, but resolved by NuGet. Version="*" means the highest stable version. Here is the document about Floating version resolutions.
I used dotnet CLI to create NuGet package. Here is my sample:
1.Add package reference in the "*.csproj" file.
<ItemGroup>
<PackageReference Include="ext.lib.MyPackage" Version="*" />
</ItemGroup>
2.Use dotnet pack command to build a NuGet package. This will generate a "*.nupkg" file. Change the suffix of this file to zip and extract files.
3.We can find a "*.nuspec" file. Open this file with Notepad, we can find the following content:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2013/05/nuspec.xsd">
<metadata>
<id>ext.lib.DevExpress</id>
<version>3.2.1</version>
<authors>ext.lib.DevExpress</authors>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>Package Description</description>
<dependencies>
<group targetFramework="net5.0">
<dependency id="ext.lib.MyPackage" version="1.2.3" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
</package>
So we can find that before this package is pushed to Azure DevOps, the dependencies of the package have been resolved to explicit versions and this is the expected behavior.
If you don't need ext.lib.DevExpress as dependencies any more, you need to remove this package reference in your ext.lib.MyPackage and push your package again.
Related
I have a Nuget package. Example: 'Sample'.
I have generated a .nupkg file using nuspec file.
and then pushed 'Sample' nuget package to feed using Nuget push azure build task.
my nuspec file:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>Sample</id>
<version>1.0.0.0</version>
<title>Sample</title>
<authors>Name</authors>
<copyright>Copyright © 2009-2019. All rights reserved.</copyright>
<tags>Sample</tags>
<description>This package is for testing.</description>
<owners>Name</owners>
</metadata>
<files>
<file src="./Sample.dll" target="lib\net46\Sample.dll"/>
</files>
</package>
Now I want to change the name of my nuget package, For example: 'SamplePackageForTesting'.
Nuget pakage name is not updated eventhough I change the title, and then pushed.
But when I change the id and push, then it is updating as new package.
Can you provide any solution how to change the name of my nuget package 'Sample' to 'SamplePackageForTesting'.
A rename is not possible: from NuGet's perspective, Sample and SamplePackageForTesting are two different packages as they have different IDs.
If you're using nuget.org, a workaround would be to deprecate your package (see here).
And if the NuGet feed is under your control you could also delete the Sample package. But for this, you have to make sure that nobody ever consumed it because otherwise deterministic builds won't be possible when going back in Git history.
We have been erratically getting NU110 erros in our Azure DevOps pipeline for the MS hosted Windows (vs2017-win2016) based agents. This is been going on for a few days now
error NU1101: Unable to find package CommandLineParser. No packages exist with this id in source(s):
Is this some kind of a known issue and is there anything required from our end for addressing this?
Thanks
error NU1101: Unable to find package CommandLineParser. No packages exist with this id in source(s):
As far as I know, the CommandLineParser package exists in the nuget.org.
Here are two methods, you could refer to them.
When you use the feeds in Nuget Restore task. You could select the Use packages from NuGet.org.
When you use the Nuget.config file to restore the package, you could add the Nuget.org as the package source.
For example:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<!-- remove any machine-wide sources with <clear/> -->
<clear />
<!-- get packages from the NuGet Gallery -->
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
</configuration>
Based on my test, the package could be found successfully.
Updates:
Now the "Dotnet Restore" task has some issues itself. It sometimes causes the Unable to find package issue. For more information, you could refer to this ticket.
Workaround:
You could change to use the Nuget Restore task. This task has the same function and it could work fine.
I am trying to set up a DevOps pipeline with Azure DevOps and BotFramework. My build is failing due to the package Microsoft.Bot.Protocol.StreamingExtensions.NetCore with the error NU1101: Unable to find package Microsoft.Bot.Protocol.StreamingExtensions.NetCore. No packages exist with this id in source(s): NuGetOrg
I tried to uninstall this package, but then I started getting the same error locally. When I tried to reinstall I couldn't find the package on NuGet which is probably why this error is occurring, so I had to revert to a previous commit to get a working version of my bot.
It would be expected for the package to be able to be installed when the project is being built on Azure DevOps. Any help with this is appreciated.
Build Fails with NU1101: Unable to find package Microsoft.Bot.Protocol.StreamingExtensions.NetCore
That because the package Microsoft.Bot.Protocol.StreamingExtensions.NetCore was only published to the myget.org Not nuget.org. That is also the reason why the error message show that this id in source(s): NuGetOrg.
You can find that package on the myget.org:
https://botbuilder.myget.org/gallery/experimental
Then get the URL to connect the feed is:
https://botbuilder.myget.org/F/experimental/api/v3/index.json
To resolve this issue on Azure DevOps, you can add a nuget.config under the solution folder with following content:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="MyGetFeed" value="https://botbuilder.myget.org/F/experimental/api/v3/index.json" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
Then submit and push this file to the Azure Devops repos. Use this file when you restore nuget packages:
As test, it works fine on my side.
Hope this helps.
I am trying to run:
nuget pack project.csproj
but because of the directory structure of the project:
A\B\C\Project
it keeps saying:
NuGet.Protocol.Core.Types.FatalProtocolException: Failed to retrieve information from remote source 'A\B\Packages', which it really should be 'A\Packages'. How do I change where NuGet looks for packages while establishing dependencies.
I have tried putting a NuGet.config in both the project directory as well as the Solution (in .nuget). I added this to the file:
<config>
<add key="repositoryPath" value="A\Packages" />
</config>
in both places and it made no difference (it always says A\B\Packages).
VisualStudio 2019: Tools > Nuget Package Manager > Package Sources:
Select nuget.org and specifically unselect the others options
Add NuGet.org reference in the package source
Go to tools -> NuGet package manager-> package manager settings
Select NuGet Package manager and then Package sources
Add the following source library.
Name: NuGet.org
Source: {"\Https://api.nuget.org/v3/index.json}
The error is a bit weird, but is already mentioned here.
It looks like NuGet by default expects a packages folder at the same location as the .csproj file.
I also had a custom project structure where the .sln was located in another folder.
At least I worked around this by creating a Symbolic link like this (open cmd with admin rights):
cd <your .csproj location>
mklink /d packages "C:\path\to\actual\packages"
This way NuGet thinks the packages folder exists and should be able to create your package.
For me it worked by adding NuGet.config in solution folder.
I was facing similar issue with core 3.1 and trying to upgrade package 'Swashbuckle.AspNetCore.SwaggerGe'.I found that i was doing typo in Package source url. I have corrected it [Tools => Nuget Package manager => Package manager setting => Package Source ] and issue got resolved.
If you use packages that have Semantic Versioning 2.0.0, please make sure that you are using the V3 feed, https://api.nuget.org/v3/index.json, in the NuGet configuration.
The issue may be caused by the way the nuget looks for the packages folder. It looks for a .sln file by traversing up the directory structure. If, in your case, directory A\B contains a .sln file then nuget will assume the packages folder would also be there.
On OSX you can add a symlink to trick nuget into building.
Run the following in the project folder to make nuget read from the parent (solution) directory that have a packages folder:
ln -s ../packages packages
In my case, I unchecked ALL the package sources except the one that I needed which was NuGet.org from NuGet Package Manager >> Package Sources. After this, the NU1301 error was gone.
In the case of Rider IDE another problem could cause this error:
if you configure your NuGet sources in the project let the Username and Password in the Rider Ui empty and instead add manually this section (packageSourceCredentials) to your NuGet.Config in the project folder:
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
<add key="YourNuget" value="<your_nuget_url>" />
</packageSources>
<packageSourceCredentials>
<YourNuget>
<add key="Username" value="<Username>" />
<add key="ClearTextPassword" value="<Password>" />
</YourNuget>
</packageSourceCredentials>
</configuration>
I cannot get nuget pack X.csproj to recognize package dependencies in a project. Amazingly, when packaging, the diagnostic message “Found packages.config. Using packages listed as dependencies” is printed, but in the end the <dependencies/> tag in the .nuspec file inside the package is empty.
The packages.config for the project does indeed contain references:
<packages>
<package id="SmartAction.Logger" version="1.0.2.0" targetFramework="net40" />
<package id="SmartAction.Pervasive" version="1.0.1.0" targetFramework="net40" />
</packages>
To narrow the problem down, I removed my own parallel .nuspec file, and mostly all switches from the nuget pack command:
> nuget pack libToneDetection.csproj -prop Configuration=Release
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Attempting to build package from 'libToneDetection.csproj'.
Packing files from '[snip]\Core\ToneDetection\libToneDetection\bin\Release'.
Found packages.config. Using packages listed as dependencies
Successfully created package '[snip]\Core\ToneDetection\libToneDetection\SmartAction.Audio.ToneDetection.1.0.0.0.nupkg'.
NuGet Version: 3.3.0.212
The only difference I can spot with this project is that its name is different from package name (I am trying to maintain them in sync but this is older stuff I am repackaging).
I doubt I had ever seen this before. I am finding questions on SO from people trying to prevent references in packages.config from becoming dependencies of the package, but none from those trying, like me, to beat the reverse problem. Help!
Addendum. I copied the project out of the solution with other projects to a temporary directory and rebuilt the package from there. Now one of the two dependencies from packages.config was added to the package:
<dependencies>
<dependency id="SmartAction.Logger" version="1.0.2.0" />
</dependencies>
Thinking of the differences between the two, the SmartAction.Logger package depends on SmartAction.Pervasive. But the package I am compiling really uses both.
To me, either behavior looks incorrect. Am I hitting a nuget bug, or a cryptic complex feature?
Xref: Opened https://github.com/NuGet/Home/issues/1867