NuGet packages - Deployment Manager

Before you can deploy an application using Deployment Manager, 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. Deployment Manager 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

NuGet Servers

When planning your Deployment Manager 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:

• A remote feed exposed over HTTP
• A local feed exposed as a File Share or local directory
• A JetBrains TeamCity server (version 7 and above)
• A MyGet server

Deployment Manager can consume packages from multiple feeds at once, and these can be added from the Settings menu in the Deployment Manager web interface.

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 Deployment Manager:

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 Deployment Manager. Instead, your Deployment Manager package should look exactly as you want the files to be extracted on disk. For example:

Dependencies

Another NuGet feature that doesn't translate well to Deployment Manager 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 Deployment Manager, for the same reasons as above. For example, if your Deployment Manager 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, Deployment Manager NuGet packages cannot have dependencies.

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

Using NuGet from Visual Studio

Note that the above limitation only applies when building your Deployment Manager package. You can still use NuGet to manage your references inside Visual Studio - Deployment Manager 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 Deployment Manager package you create for your application should simply include the bin\Debug or bin\Release folder as-is.

NuGet.Server package size

Note that NuGet.Server restricts package sizes to 30MB by default.

To set it to something more reasonable (say 400MB for large applications), update Nuget.Server's web.config with these values:

<system.web>

<httpRuntime maxRequestLength="419430400" />

...

<system.webServer>

No

<requestFiltering>

<requestLimits maxAllowedContentLength="419430400" ></requestLimits>

...

Database packages

For information on how to create and deploy database packages, see: Working with database packages.