I have turned on TeamCity's NuGet Server and I want to push in common packages (i.e. from public sources such as NuGet.org) because the build server cannot see outside our company, so restoring packages on the build server from NuGet.org is not possible.
I cannot see how to push these packages on to our TeamCity server. I've seen various answers suggesting to use a package build still or some other means of publishing from within a build, but this is not appropriate for my use case.
If I try to publish from a command line it complains that it cannot find an API key (where do I get that from?) and it won't allow me to enter my credentials (I assume my team city login would be it) as it tells me "Cannot prompt for input in non-interactive mode." (I didn't set that mode and I can't see how to turn that off).
So, how do I push/publish an adhoc package that I obtained elsewhere into team city?
I believe that the nuget functionality provided by TeamCity is an API added on top of TeamCity's builtin artifact functionality.
There are a number of consequences of that:
When a build configuration is executed that produces any .nupkg files that are marked as artifacts, they will be available on the Teamcity nuget feed.
As with all other artifacts nupkgs published in TeamCity are subject to Teamcity's general artifact retention rules.
Access rules for nuget packages are the same as access to the TeamCity projects.
There is however as far as I know no implementation in the Teamcity Nuget API for pushing packages to it. The general practice for storing original or generated packages is to use a stand alone nuget server or service like a normal file share, a Nuget.Core based server, proget or myget.org.
Update:
If you end up with many packages of your own I've heard people reporting that Teamcity becomes quite slow when the clients are resolving the packages.
Update 2:
The last years I've adopted the notion of separating build artifact packages into the two categories library package and deployment package. A separate package repository can be used for both types but a repository such as the one available in for instance Octopus deploy should only be used for deployment packages.
Update 3:
Microsoft have a page for a number of nuget server options.
Related
I am looking for practical options to develop and test private nuget packages.
We have a set of "core" code that is delivered securely through an Azure Artifact Feed. We have various "consuming" applications that use the core nuget packages.
As a small-medium team, one person may be developing the core nuget as well as consuming it.
Today we check-in / merge the code for the nuget package. Make sure the Pull request is approved / passes. Then the build updates the Azure Artifact feed.
Then we come back to the "consuming" app and can update the package. Works great if you fix / add the feature the first time. However, slows down productivity when treating this as an iterative development approach.
Looking for simple options for a small team. Random thoughts on options:
Push nuget "alpha" package straight from developer's machine to Azure Artifact feed. Symbol server too?
Do something with an Azure build to allow "feature" branches to publish to Azure Artifact feed somehow?
Push to local nuget feed. Include pdbs so it can be debugged?
Temporarily break the nuget reference directly for local copy of dll(s)?
Re-think using nuget packages as a whole?
Push nuget "alpha" package straight from developer's machine to Azure Artifact feed. Symbol server too?
It depends on whether you need to debug it. If you need do debug this "alpha" package, you have to push the symbol package to the symbol server.
Note: You do not need to push the "alpha" package to the symbol server, just the symbol package.
Do something with an Azure build to allow "feature" branches to
publish to Azure Artifact feed somehow?
There is a task Push NuGet packages, we could use it to publish to Azure Artifact feed during build, no matter which branch it is on. It depends on whether you have enough permissions for the Azure Artifact feed, you can check it from Artifacts->Settings->Feed settings->Permissions:
Push to local nuget feed. Include pdbs so it can be debugged?
No, you also have to include the source code. Check this thread for some more details.
And there is a lightweight solution how to debugged nuget package on local feed on a network share.
Temporarily break the nuget reference directly for local copy of
dll(s)?
Re-think using nuget packages as a whole?
The answer is yes, when we develop the project on the local, use project reference is better than nuget, check my another post for some more details:
Ticket: Project reference VS NuGet.
Hope this helps.
I have a situation where we have multiple C# projects that use similar set of Nuget packages (ex. Newton Json, Microsoft Compilers and CodeDom, Owin, log4net, jQuery, EntityFramework etc.)
I am trying to see how we can have a shared location for all Nuget packages to reduce the footprint of those binaries in Git, having a single repo for them by centralizing them in one place.
One option I found is to use Nuget.config in each project with repositoryPath set to point at the shared location. This works great for adding/upgrading/restoring Nuget packages in the project but it is not very clean when a package gets removed from one project but is still required in a different one. Basically the package will get removed from the shared location and the change is committed to Git, then when the other project requires it, it would get restored and added back to Git. Not a perfect solution in my mind.
I have a two part question:
1. Is there a way to improve the above workflow when packages get removed?
2. What is the industry standard for handling third party libraries delivered via Nuget? Or if there is none, can you share your experience handling Nuget packages across multiple projects.
If the concern lies with the footprint/organization of the Git repository, maybe you can do a .git ignore for the dependencies folders to prevent git from committing them into the repositories. When you need to build the projects from source, just do a dotnet /nuget restore to get the dependencies from the source you configured in the Nuget.config
Not sure if it is the industry standard, but we host our own Nuget server to control the libraries that the different teams can use. Microsoft has an article on Hosting your own NuGet feeds
Hope it helps.
I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.
I have a working Octopus Deploy server which has a library of packages I built.
I have an assembly which depends on one of the assemblies which I have deployed in Octopus Deploy and which is currently in that repository. I tried adding it as a package source in NuGet Package Manager, with my repository's URL (something like:
http://myoctoserver/app#/library
).
It will not populate the list Manage NuGet Packages of Visual Studio 2013, although the Microsoft and .NET and the nugget.org will populate.
Documentation doesn't appear to address this at OctopusDeploy.com. Is this something that can be done, or does my organization need to make an external NuGet feed?
Octopus Server provides a write-only repository and it can't be consumed by other NuGet clients.
There are many options available to you depending on your budget / hardware
ProGet
MyGet
NuGet.Lucene
NuGet Gallery
Octopus built in package repository is not mean't to be consumed by others.
The nuget packages there, are built specifically for Octopus. They have different structure. These packages are meant to be unpacked directly to a specific location, and run by either Windows service or IIS.
Also, from docs:
It is important to understand that the Octopus server provides a
write-only repository; intended for hosting application packages only
. Packages that are pushed to the Octopus server can't be consumed by
other NuGet clients like Visual Studio. If you need a NuGet feed for
sharing libraries between your development projects, a separate NuGet
repository is required.
http://docs.octopusdeploy.com/display/OD/Package+repositories
We host internal nuget server ourselves, which works very nicely.
I have been looking at self hosting NuGet, having a hard time understanding how to set it up and how it would help support our development process.
Does anyone have any recommendations as to which to use, how to set it up?
Or should I just use a hosted service?
After looking around at various solutions--self-hosted and hosted service--we chose to go with ProGet.
ProGet Summary
ProGet has a standard "free" license and nominal licensing fees (single year and perpetual) for the enterprise version. We currently use the standard "free" version and have no real complaints. You can create as many feeds as you want, add as many users as you want, etc. (We created "Testing", "Staging", and "Production" feeds to be part of our quality assurance process.) The only real limit in the free version is the inability to filter external feeds for specific packages you want included in your ProGet feeds. This filtering feature is managed with "connectors". With the enterprise version--when you create a feed--you can optionally add a "connector" to pull in packages from other feeds (external or internal).
ProGet With Nuget Package Management and Creation
The steps for creating a nuget package itself I'll leave to David Ebbo's popular blog post, http://blog.davidebbo.com/2011/04/easy-way-to-publish-nuget-packages-with.html. However, know that for uploading packages you can upload via the ProGet packages administration web UI, command-line nuget.exe, or the Nuget Package Explorer.
ProGet Installation, Configuration, and Activation
Installing, configuring and activating ProGet was the least intuitive part. It can install backed by a regular SQL Server database or a SQL Server Express db. Furthermore, it can also be a self-hosted app or run under IIS. If you need to perform offline activation or want to request different license keys go to my.inedo.com and create an account and you can do everything from there.
Proget Quality Control & CI
CI with TeamCity is something we are going to need so we are looking at creating a nuget package build process using TeamCity's Nuget server. There's a how-to for creating the packages I'll post in a comment. The next step would be to automatically publish the TeamCity-created nuget packages over to the appropriate ProGet feeds (ie. "Testing", "Staging", "Production") perhaps utilizing command-line Nuget with an API key.
Further Information
We looked at MyGet as a hosted service but it seemed to trip up on simple scenarios like adding another contributor/user. It also jumped quite a bit in price when needing more than just two contributor accounts. Whereas with ProGet you get unlimited user accounts with the free version alone.
One more side note: For publishing OSS type projects/packages, I'd take a look at Chocolatey as a solution.
Another option for self hosting is using the NuGet.Server package and creating an IIS website to host it on your internal network, although it won't scale very well if you plan to publish more than a handful of packages.
I've created a fork of NuGet.Server that uses a Lucene.Net index to fix these performance issues. Downloads are available from https://github.com/themotleyfool/Klondike/releases.
To keep this thread up-to-date, Visual Studio Team Services also has a package manager in preview. See the marketplace: Package Management
You can create an empty Asp.Net Web Application and install Nuget.Server from Nuget Gallery. This is a free option of self hosting your own Nuget packages on IIS. Check the documentation