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
Related
Azure is well-suited to publicly releasing developer-oriented artifacts like NuGet packages. And it's great at deploying Web-Apps and things intended for VMs. Plenty of release templates for those. But I can't find much discussion on deploying a simple standard Windows desktop application installer. Does such a facility exist?
Because our pipelines produce two main artifacts we give to customers:
a NuGet packaged SDK for developers
an installer for a standard old Windows Desktop application for end users
Getting #1 out there is easy. But what do I do about #2?
I'm not sure what I was expecting. Maybe something like an Azure-provided publicly-facing page with a list of installer builds I had released. Something my pipeline could feed into directly. Maybe even some provision to require people to enter contact information to download the installer, or a customer-specific URL that would record for us who had downloaded it.
Does this sort of Azure facility exist? Or is this a case where we should just expose a downloads page directly from our own company website?
Is there an Azure Pipeline facility for releasing a standard Desktop Application?
I am afraid there is no such specific Azure Pipeline facility for releasing a standard Desktop Application.
When we release a standard Desktop Application, we could use the copy task or publish build artifact task to deploy standard Desktop Application build artifact, to a network drive folder or target machine directly.
You could check this document and my previous thread for some details.
So,there is no such specific Azure Pipeline facility for standard Desktop Application.
If you really want to use artifacts to manage standard Desktop Application, you could try to use the Universal Package, which store one or more files together in a single unit that has a name and version. we could also publish Universal Packages and download it.
I recently installed Nuget Gallery (https://github.com/NuGet/NuGetGallery) as a repository. Ideally I would like to create multiple feeds so that I could differentiate between nuget packages that will be reused in other projects (dll's, contracts etc) from the packages we use to deploy our projects to the production environment.
I know I can achieve this by creating multiple instances of the Nuget Gallery, but this seems to me a bit of an overkill, it would mean two websites two databases. I am also familiar with the fact that MyGet provides this functionally but I will not be able to get an approval for the purchase. I am also aware teamcity contains its own feed server but it doesn't allow this multiple feed scenario, nor its performs well enough to be used in a large scale.
In a nutshell the ideal deployment scenario would be as follow:
teamcity generate deployment package or dll/contract package, depending on the build scenario.
teamcity publishes deployment packages to a nuget gallery deploy feed
(say: nugetgallery.server.com/deploy/api/v2).
teamcity publishes dll/contract packages to a nuget gallery dev feed
(say: nugetgallery.server.com/dev/api/v2).
octopus always searches for packages in
nugetgallery.server.com/deploy/api/v2
devs / teamcity searches for packages in
nugetgallery.server.com/dev/api/v2
This way I keep things clean and I can even go as far as create a third type of feed that only contains release packages so that I can be sure nothing would ever be deployed to production if it wasn't on that feed.
I might have missed some fundamental approach, so alternatives to this one I picked are welcome.
As I couldn't find anything relevant I ultimately gave up and went with the two servers solution. I struggled a lot to find any documentation what functionalities the nuget gallery really has.
Right now we have something like deploy-nuget.server.com and dev-nuget.server.com, separate urls, iis instances and sql instances and folder location.
For someone that might look into this in the future, one of the solutions that could work is to make private repository based on the user, unfortunately in my case that would not be enough as I would also want the packages to be stored in different locations so we could enforce different backup policies based on the type of package. Another option would be to actually change to fork the project, but from my previous experience this never ends well as sooner rather than later you will want to upgrade and your custom changes will have to be sorted somehow.
I understand this is not the idea behind nuget gallery, as you are not supposed to delete packages. But we do have some space constraints so eventually we will remove certain deployment packages that were created for QA environments which we obviously dont care anymore.
you can try Proget. using this server you can easily manage multiple NuGet feeds.
it also provides free edition which supports all features.
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.
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.
per internal policies I have to setup a local nuget repository that contains only the packages approved by internal committee.
I know how to setup a local nuget server and I also found how to download all packages from Nuget (http://weblogs.asp.net/jgalloway/archive/2011/02/02/downloading-a-local-nuget-repository-with-powershell.aspx), but what I'd need is a way to just download the packages that are approved with their dependencies, save them on my local server and then possibly keep them up do date when a new version comes out and it is "re-approved" internally.
Thank you
This is exactly what ProGet was built for :)
ProGet is a private NuGet repository designed to manage both third-party and in-house libraries used as application dependencies. There's a free version of ProGet available that meets most organizational needs.
There are also other private repositories available, including MyGet, JFrog Artifactory, and Sona Nexus. Make sure to check out Taking NuGet to the Enterprise for other best practices in introducing NuGet in your organization.
(disclaimer: I work for Inedo)