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.
Related
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.
How to Install the Azure Artifacts Packages in VS Code, I tried to check the Connect to feed option and found there are multiple Nuget options like Dotnet, Nuget.exe, and Visual Studio, etc.
But when I am trying for VS Code then it's not working.
What I did so far in the VS Code?
1 Approach) I install the NuGet package manager and when I am trying to do search my package then it's not showing in the list. but using this command "Get-PackageSource" I am able to see the package in the console.
2 Approach) I created one nuget.config file and mentioned below the package details
'<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="test#Release" value="https://xxxxxxx.pkgs.visualstudio.com/_packaging/test/nuget/v3/index.json" />
</packageSources>
</configuration>'
after that running NuGet restore command and below giving the output but I didn't see any dependencies in the project and the same thing working fine using Visual Studio 2017
NuGet Config files used:
C:\Users\sudhir\source\repos\testPrivateNugetFeed\NuGet.Config
C:\Users\sudhir\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config
C:\Program Files (x86)\NuGet\Config\Xamarin.Offline.config
Feeds used:
`https://XXXXX.pkgs.visualstudio.com/_packaging/test/nuget/v3/index.json'
All projects are up-to-date for restore.
I have also followed this thread
Add custom package source to Visual Studio Code
Please give me some solution.
How to Install Azure Artifacts Packages dependencies in Vs Code?
I could reproduce this issue on my side, it seems to be a limitation of the NuGet package manager extension or Visual Studio Code.
No matter how I set up my Nuget.config file, I could not see the custom nuget package from the Azure devops feed in the NuGet package manager extension. I also test any other extension like NuGet Gallery, but not success.
To resolve this issue, I add following nuget.config file in my project, which next to my .sln file：
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="AzureDevOpsFeed" value="https://pkgs.dev.azure.com/<MyORGName>/_packaging/<MyFeedName>/nuget/v3/index.json" />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
<config>
</config>
<packageSourceCredentials>
<AzureDevOpsFeed>
<add key="Username" value="LeoTest" />
<add key="ClearTextPassword" value="My PAT Here" />
</AzureDevOpsFeed>
</packageSourceCredentials>
</configuration>
And add following in my packages.config:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="LibA" version="1.0.0" targetFramework="net461" />
</packages>
The LibA is a custom package in my Azure decops feed:
Then I use nuget.exe to restore the package for my project:
If nuget restore not work for you, please share the log for that command.
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.
Using AzureDevOps I should be able to restore packages from the feeds hosted within AzureDevOps.
The Nuget.config seems correct, the build has access to the feed, locally it runs fine with explicitly using the same config file.
I've seen VSTS Build vNext NuGet custom package source but would very much like to stay out of adding apikey's there. The official documentation states it should be possible: https://www.visualstudio.com/docs/package/get-started/build/team-build
NuGet.config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<packageSources>
<clear />
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="Net2Library" value="https://xxx.pkgs.visualstudio.com/DefaultCollection/_packaging/yyy/nuget/v3/index.json" />
</packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
Feed settings
Restore settings (it uses the correct config, visible from listing the feed in the logs)
Relevant logs:
2016-07-30T12:33:37.8085538Z Restoring NuGet package XYZ.2016.7.29.14.
2016-07-30T12:33:42.6885539Z Unable to find version '2016.7.29.14' of package 'XYZ'.
2016-07-30T12:33:42.6915543Z Feeds used:
2016-07-30T12:33:42.6925542Z C:\Users\buildguest\AppData\Local\NuGet\Cache
2016-07-30T12:33:42.6925542Z C:\Users\buildguest\.nuget\packages\
2016-07-30T12:33:42.6925542Z https://api.nuget.org/v3/index.json
2016-07-30T12:33:42.6935552Z https://xxx.pkgs.visualstudio.com/DefaultCollection/_packaging/yyy/nuget/v3/index.json
2016-07-30T12:33:42.7235541Z ##[debug]rc:1
2016-07-30T12:33:42.7245545Z ##[debug]success:false
2016-07-30T12:33:42.7325527Z ##[error]Error: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.103.1\agent\Worker\Tools\nuget.exe failed with return code: 1
2016-07-30T12:33:42.7335525Z ##[error]Packages failed to install
2016-07-30T12:33:42.7335525Z ##[debug]task result: Failed
2016-07-30T12:33:42.7345538Z ##[error]Return code: 1
This is caused by VSTS issue which has been fixed by now, please try the build again.
Issue: Failures while restoring nuget packages in Visual Studio Team Services – 8/1 – Resolved
Other possible issue: Packaging issues with Visual Studio Team Services – 7/30 – Resolved
.
I'm having the exact same issue. I've been experiencing the error most of the times when the build starts from a push from the local repo (either from VS 2015 or git bash). The workaround for me has been to queue a build directly on VSTS build definition, through "Queue Build.It's annoying but it's the only way I found to overcome the issue. I do think this is a bug and hope MS fix it. Hope my workaround helps.
Summary: We have a script that runs nuget.exe from the command line within our solutions repository. How can we configure NuGet to only use a specific package source (and not anything listed in the machine-wide or users configuration)?
From the NuGet documentation, one can read the following concerning chaining multiple config files:
NuGet first loads NuGet.config from the default location, then loads
any file named NuGet.config starting from the root of the current
drive and ending in the current directory. (...) When <clear /> is
present for a given node, previously defined configuration items for
this node are ignored.
At the root of our repository, we have added the following NuGet.Config file to make sure we only fetch NuGet packages from out own internal NuGet repository:
<!-- C:\repository_root_path\NuGet.Config -->
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
<packageSources>
<clear /> <!-- ensure only the sources defined below are used -->
<add key="Internal package source" value="\\network_fileshare\nuget_packages\" />
</packageSources>
<disabledPackageSources />
<activePackageSource>
<add key="Internal package source" value="\\network_fileshare\nuget_packages\" />
</activePackageSource>
</configuration>
The problem we're experiencing now, is that this yields different results depending on which version of NuGet.exe we're running. To debug, I've downloaded three separate versions of NuGet.exe and put them all in the .nuget-folder in our solution. The result is as follows:
C:\repository_root_path>Source\.nuget\nuget_2.5.40416.exe sources
Registered Sources:
1. Internal package source [Enabled]
\\network_fileshare\nuget_packages\
C:\repository_root_path>Source\.nuget\NuGet_2.6.40619.exe sources
Registered Sources:
1. NuGet official package source [Enabled]
https://nuget.org/api/v2/
2. Internal package source [Enabled]
\\network_fileshare\nuget_packages\
C:\repository_root_path>Source\.nuget\nuget_2.7.40808.exe sources
Registered Sources:
1. NuGet official package source [Enabled]
https://nuget.org/api/v2/
2. Internal package source [Enabled]
\\network_fileshare\nuget_packages\
3. https://www.nuget.org/api/v2/ [Disabled]
https://www.nuget.org/api/v2/
So the question is: has there been introduced a bug in NuGet between version 2.5 and 2.6 so that the <clear /> element is ignored, or is there something wrong in the NuGet.Config file we have in our solution root?
This has been confirmed as a bug in NuGet. The fix is assigned to release 2.7.2.