How to use NuGet packages on build server/production server without internet?

Question

Background

I have the following components:

• My local solution (.NET 4.5) which makes use of NuGet packages.
• A PowerShell build script in my solution that has targets to build, run unit tests, to Web.config transforms, etc.
• A build server without an internet connection running CruiseControl.NET that calls my build script to build the files. It also serves as the (IIS7) environment for the dev build.
• A production server with IIS7 that does not have internet access.

Goal

I would like to utilize NuGet packages from my solution and have them be stored locally as part of source -- without having to rely on an internet connection or nuget package server on my build and production servers.

Question

• How can I tell MSBuild to properly deploy these packages, or is this the default behavior of NuGet?

Idel

Answer 1

Scott Hanselman has written an excellent article entitled How to access NuGet when NuGet.org is down (or you're on a plane). If you read through this article, you'll see at the end that the suggestions he makes are primarily temporary-type solutions and he goes out of his way to say that you should never need the offline cache except in those emergency situations.

If you read at the bottom of his article, however, he makes this suggestion:

If you're concerned about external dependencies on a company-wide scale, you might want to have a network share (perhaps on a shared builder server) within your organization that contains the NuGet packages that you rely on. This is a useful thing if you are in a low-bandwidth situation as an organization.

This is what I ended up doing in a similar situation. We have a share which we keep with the latest versions of various packages that we rely on (of course, I'm assuming you're on some type of network). It works great and requires just a little work to update the packages on a semi-regular basis (we have a quarterly update cycle).

Another article that may also be of help to you (was to me) is: Using NuGet to Distribute Our Company Internal DLLs

Clitoris

in VS exist Package Manager options but how do i configure msbuild in the CI server to go to this network share? – Gingergingerbread

Answer 2

By default, Nuget puts all your dependencies in a packages/ folder. You can simply add this folder to your source control system and Nuget will not need to download anything from the internet when you do your builds. You'll also want to ensure that Nuget Package Restore isn't configured on your solution.

Connelly

This is actually not a recommended practice for a variety of reasons. In fact, for those folks with network access, Nuget provides a feature to download missing packages (as defined by a single file) automatically so you never need to check them in. (goo.gl/v7Zrb) Otherwise, read this discussion for why this isn't recommended: goo.gl/Cp9oG – Clitoris

I agree, this approach does have a lot of problems. I completely forgot about pointing Nuget to a local repository. Upvoted your answer. :) – Connelly

:) Appreciate it. Yeah...I made the mistake of checking in the packages folder at one point for a large project...Subversion didn't handle it well. That's one reason I wanted to share my experience. – Clitoris

Answer 3

You'll have to make a decision; either you download/install the packages at build time (whether it be using package restore, your own script, or a build tool that does this for you), or you put the /packages assemblies in source control as if they were in a /lib directory.

We've had so many problems with using package restore and NuGet's Visual Studio extension internally that we almost scrapped NuGet completely because of its flaws, despite the fact that 1 of our company's 2 products is a private NuGet repository.

Basically, the way we manage the lifecycle is by using a combination of our products BuildMaster and ProGet such that:

• ProGet caches all of our NuGet packages (both packages published by ourselves and ones from nuget.org)
• BuildMaster performs both the CI and deployment aspect and handles all the NuGet package restoration so we never have to deal with massive checked-in libraries or the solution-munging nightmare that is package restore

If you were to adopt a similar procedure, it may be easiest to create a build artifact in your first environment which includes the installed NuGet package assemblies, then simply deploy that artifact to your production without having to repeat the process.

Hope this helps,
-Tod

Malay

Tod, can you expound upon "it may be easiest to create a build artifact in your first environment which includes the installed NuGet package assemblies, then simply deploy that artifact to your production without having to repeat the process."? I need to get my NuGet packages into my zipped up build artifacts. Is it only the packages folder? – Cloak

Answer 4

I know this is an old discussion, but how in the world is it bad to store all the files required to build a project because of the size?

The idea that if a library is not available that you should replace it is crazy. Code cost money and since you don't control the libraries on git, or in nuget, a copy should be available.

One requirement that many companies have is an audit. What if a library was found to steal your data. How would you know for sure if the library is removed from NUGET and you can't even build the code to double check.

The one size fits all Nuget and git ways of the web are not OK.

I think the way Nuget worked in the past, where the files were stored locally and optionally place in source control is the way to go.

Hypnoanalysis