NuGet Packages

Before you can deploy an application using Octopus, you will need to bundle all of the executables, DLL's, configuration files, installation scripts, and anything else the application needs to run into a package. Octopus standardizes on the NuGet package format, a popular ZIP-based file format from Microsoft used in Visual Studio. There are a few reasons for this:

  1. NuGet packages have rich metadata, such as versioning, release notes, and author information
  2. Many tools exist to make creating and publishing NuGet packages easy
  3. NuGet packages can be consumed via a feed, so other applications can easily query the available packages
  4. Developer familiarity

The easiest way to create NuGet packages that are compatible with Octopus is using OctoPack.

NuGet Servers

When planning your Octopus installation, you will need to decide how to host your packages. Your continuous integration server should create NuGet packages, and publish them to a NuGet server. A NuGet server will typically be:

Octopus can consume packages from multiple feeds at once, and these can be added from the Settings menu in the Octopus web portal.

Differences

NuGet was designed to make it easy to add references to code libraries inside of Visual Studio. Like other package managers (RPM, APT) though, it's a logical extension that a package manager can also be used for installing applications.

NuGet does however have some default conventions that are used for building Visual Studio library packages, that don't make much sense when deploying applications. Here are some NuGet conventions and features that do not work when using Octopus:

Folder layout

NuGet encourages you to put compiled binaries into a lib folder, scripts into a tools folder, and everything else into a content folder. NuGet does this because the Visual Studio support has special conventions around these folders. This will not work in Octopus. Instead, your Octopus package should look exactly as you want the files to be extracted on disk. For example:

Package contents

Dependencies

Another NuGet feature that doesn't translate well to Octopus is dependencies. NuGet has a convenient feature for tracking dependencies between packages. This is used when, for example, a package like NHibernate depends on a package like log4net. NuGet will install NHibernate, resolve the dependency, and install log4net. It's important to note that NuGet will install them to two separate folders on disk:

  • packages/NHibernate.x.y.z
  • packages/log4net.x.y.z

While this makes sense for libraries referenced via Visual Studio, it doesn't make sense in Octopus, for the same reasons as above. For example, if your Octopus application package had a dependency on log4net, on disk you would have:

  • packages/YourApp.x.y.z
  • packages/log4net.x.y.z

At runtime, the executables or ASP.NET site under YourApp would try to invoke a method in log4net, and fail because the DLL can't be found. While this could theoretically be solved using probing paths in your configuration file, in practice it's better to avoid this approach.

For this reason, Octopus NuGet packages cannot have dependencies.

Instead, any libraries you need to use should be bundled inside of your package in the standard binaries folder:

Binaries in a package

The easiest way to avoid these issues is to use OctoPack.

Using NuGet from Visual Studio

Please note that the above limitation only applies when building your Octopus package. You can still use NuGet to manage your references inside Visual Studio - Octopus does not break that.

Most of the references will have CopyLocal=True set in the properties window, so they'll be copied to your bin\Debug or bin\Release folder. The Octopus package you create for your application should simply include the bin\Debug or bin\Release folder as-is.

NuGet.Server

Note that NuGet.Server restricts package sizes to 30MB by default. To increase the setting, please see this page.