If I have NuGet.config file with two sources retrieved from Artifactory.
For development purposes, one would want source to come from local packages if needed.
What is the best approach to go about that?
1) Having two Nuget.config, one for local development and one for production?
2) Include backup sources for nuget.config within same file?
3) Something else?
I guess the question is more about process to make development process easier. The NuGet.Config file is to be copied to Docker container to be part of that image.
For reference, here are the contents of the NuGet.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="Internal-Packages" value="http://artifactory.mycompany.corp:8081/artifactory/api/nuget/Internal-Packages" />
<add key="External-Packages" value="http://artifactory.mycompany.corp:8081/artifactory/api/nuget/External-Packages" />
</packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
NuGet uses a global cache automatically, without needing to update your NuGet config. If the packages are available in the global cache it uses them from there, otherwise it goes and looks in the artifactory sources you defined in your config. In other words, the same config for development and production does what you want.
From the docs:
When asked to retrieve a package, NuGet first looks in the global-packages folder.
Related
We have upgraded our TFS server to Azure Git, but few old projects are still sitting in TFS. one of my new project needs to reference the dll from the old project from TFS. Everything working ok locally, but Azure build pipeline is failing due to "can't find the reference to dll". How can I reference a dll from TFS project in Azre build pipeline?
This is the path in the project file
<ItemGroup>
<Reference Include="Apps.Reserve">
<HintPath>..\..\..\..\Apps\Reserve\bin\Debug\Apps.Reserve.dll</HintPath>
</Reference>
You use MSBuild hardcoded paths which work as a fallback for MSBuild and you shouldn't assume that they will be filled with DLLs on new standalone agents.
You should create lib folder from which you will take libraries or create a NuGet feed server (or folder) and setup it up through nuget.config.
From csproj
<ItemGroup>
<Reference Include="lib\$(TargetFramework)\*.dll" HintPath="%(FilePath)" />
</ItemGroup>
Or from nuget.config
<config>
<add key="globalPackagesFolder" value="<your path>" />
</config>
It's up to you which approach you will take but from my perspective the best approach is to create your own NuGet Server. Migrate all artifacts there and then migrate projects to Azure Pipelines.
Old TFS "thinking" isn't the best approach to handling feeds.
I unable to read private NuGet path while configuring NuGet restore in Microsoft Azure DevOps.
The error is:
Not found nugetConfigPath:
D:\a\1\s\https:\XXXX.pkgs.visualstudio.com_packaging\XXX\nuget\v3\index.json
Unable to read private NuGet path while building asp.net solution Azure DevOps
When you use nuget restore task in the Azure Devops, there are two options to select the nuget Feeds to use:
When you select the first option, you could select your private NuGet feed directly, like:
When you select the second option, you should specify the nuget.config in your repository that specifies the feeds from which to restore packages, like:
And the configuration in the feed in the nuget.config like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="AzureDevOpsFeed" value="https://pkgs.dev.azure.com/MyCustomOrganization/_packaging/MyCustomFeed/nuget/v3/index.json" />
</packageSources>
<packageSourceCredentials>
<AzureDevOpsFeed>
<add key="Username" value="xxx" />
<add key="ClearTextPassword" value="xxx" />
</AzureDevOpsFeed>
</packageSourceCredentials>
</configuration>
The reason for the error is that you add the private nuget feed path to the second option, that is not correct. You should select your private nuget feed from the first option.
Hope this helps.
I have a Xamarin Forms project for which I am using a private Telerik nuget feed (we're using their UI controls).
In the Azure DevOps build pipeline I have added a new service connection to the Telerik nuget feed.
In my build pipeline I have a nuget task that restores these packages.
However my build fails with the error "Unable to resolve Telerik.UI.for.Xamarin".
My understanding of configuring a private nuget feed may be incorrect. Do I need to specify a nuget.config file that specifies the Telerik nuget package? Do I need to remove the reference to the Telerik package from the .csproj? (i.e. do I need to separate out my private nuget packages to prevent the build from attempting to download them?)
After some trial and error I have eventually managed to fix this issue by creating a nuget.config file for my project and adding the following entries.
<?xml version="1.0"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
</packageSources>
<packageRestore>
<add key="enabled" value="true" />
<add key="automatic" value="true" />
</packageRestore>
</configuration>
These are just default values that allow my project to fetch the packages from nuget.org. The service credentials that I have configured for fetching packages from the private Telerik nuget feed are then merged into this nuget.config file during the build. The build is therefore able to fetch both the default packages from nuget.org as well as the private Telerik feed.
In our case, the problem was a trailing slash. In our nuget.config file, we had the endpoint specified as https://nuget.telerik.com/nuget/, but in the Service Connection in Azure DevOps it was specified as https://nuget.telerik.com/nuget (note the lack of a trailing slash!).
It's a bit annoying that Azure DevOps is that particular about it, but once we eventually saw the difference and removed the trailing slash from nuget.config, everything works as expected.
We have a project hosted in VSTS which consumes a NuGet package that we have hosted in a private NuGet feed behind our firewall.
Accessing the feed from withing the network is fine, and we can locally restore dependencies and build the project.
When configuring a VSTS build we have selected a private build agent installed on a PC within the same network as the NuGet feed. Again we have tested that restoring and building manually on that PC works.
On the NuGet feed location in the VSTS build definition task we have typed the very address we use for restoring from the private NuGet feed, and we assumed that since the agent and the private NuGet feed are inside the network and the agent's PC can access the feed and then VSTS, then there will be no problem, but that's not the case. Build fails restoring packages and the error said "can't find the feed".
Can private VSTS build agents use custom NuGet feeds?
Yes, private agent can access to your nuget feeds if the agent machine has right to access.
Since you have already verified the connection from your local machine to the private feed, you can check you VSTS build defition for NuGet restore task:
In NuGet restore task, you should select Feeds in my NuGet.config for Feeds to use option.
For Path to NuGet.config option, if you are using the nuget.config file located in %AppData%\NuGet\NuGet.Config, you can leave the option empty, it use the nuget.config file by default. If the nuget.config file you are using does not located in the path, you should specify the path for where the nuget.config file located.
For Credentials for feeds outside this account/collection option, select your private feed(s) for where to download the packages.
If you have not add endpoint for your private feed in VSTS, you can click New to add credential for your private feed.
They can but you might need to configure where your nuget feed is at on the Build server.
We run our private build agents under a user we have defined. We will call him user1.
If you go out to c:\users\user1\appdata\roaming\nuget there should be a NuGet.Config.
It should look a lot like this. We have stopped our build servers from finding the Microsoft Feed. We only wanted them to run the enterprise feed we have. You can steal the one off your local machine or save it using Visual Studio on the Build Machine.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageRestore>
<add key="enabled" value="True" />
<add key="automatic" value="True" />
</packageRestore>
<packageSources>
<add key="Your Repository Key" value="http://[your package location]/packages.svc" />
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
</packageSources>
<disabledPackageSources>
<add key="nuget.org" value="true" />
<add key="Microsoft and .NET" value="true" />
</disabledPackageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
</configuration>
I've set up an in-house NuGet repository (a shared folder on one of our servers), and have added it to the "Available Sources" list in the Visual Studio NuGet settings on my PC. I'm able to successfully install a package into my solution from this repository.
However on the TFS server the build is failing because it can't restore this particular package (message: "Unable to find version 'xxx' of package 'xxx'"). The solution is configured for "enable NuGet package restore", which works fine for packages installed via nuget.org. It's just not restoring the package from our internal repository.
Permissions on the repository folder/share are fine. What am I missing?
I'm guessing I have to configure Visual Studio's "available sources" on the TFS server too, but presumably these settings are user-specific? The build service runs as NETWORK SERVICE, so how can I configure NuGet for this user?
You can add the source to a machine-wide config on the TFS build server and it will be included in the list of sources when doing package restores.
What I did was create a file %ProgramData%\NuGet\Config\sources.config that contained:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="internal source" value="http://internal_server/nuget/" />
</packageSources>
</configuration>
The name of the file doesn't matter, it's the location of the file. Nuget picks up any .config files under that folder.
http://docs.nuget.org/docs/reference/NuGet-Config-File#NuGet_config_extensibility_point
UPDATE 2016-11-18
According to http://blog.nuget.org/20161121/introducing-nuget4.0.html (under breaking changes), VS 2017+ and NuGet 4.0+ changes the location of the machine-wide config folder to %ProgramFiles(x86)%\NuGet\Config\.
change your build to run as a specific account. you can then logon with that account and prove off all of these little snags.
depending on which way you are doing the NuGet restore, have you updated the targets file with the location of your local feed?
<ItemGroup Condition=" '$(PackageSources)' == '' ">
<!-- Package sources used to restore packages. By default, registered sources under %APPDATA%\NuGet\NuGet.Config will be used -->
<!-- The official NuGet package source (https://www.nuget.org/api/v2/) will be excluded if package sources are specified and it does not appear in the list -->
<!--
<PackageSource Include="https://www.nuget.org/api/v2/" />
<PackageSource Include="https://my-nuget-source/nuget/" />
-->
<PackageSource Include="http://MyLocalFeed/nuget/nuget"/>
</ItemGroup>