Guidance on WiX, TeamCity and NuGet integration

Question

This may get flagged as “not a real question” but I'm really confused by where NuGet fits in with a WiX deployment (which you can guess by the questions at the end...)

Current Situation

Our TeamCity build creates the WiX Burn (3.6) installers for our WinForms products that are FTP’d to our servers. The apps call our web services to determine whether there is a later version that it’s entitled to, and if so downloads it in the background so that’s it’s ready to be installed the next time the app starts.

New Requirement

We have some new functionality that is included into our c# solution via a NuGet package. The package will not be required by 90% of our client installations due to the specific functionality in the package, so presumably will need it’s own msi. The NuGet package in question isn’t ours, and resides on one of our suppliers servers and requires authentication to get hold of.

I’m somehow new to the world of NuGet, and cannot get my head round where it fits in with WiX...

• Do I somehow include the NuGet package as part of the CI build and include it within the WiX installer so it’s not downloaded from the suppliers site (this would resolve the authentication issue)?

• Do I create a new MSI which includes the components within the Nuget package, but not actually use NuGet for the final client deployment at all? (This would solve a number of issues but would potentially need work each time the NuGet package is updated, and doesn't feel right!)

• Do I create a headless MSI package which downloads separately as part of the burn install? Clients won’t be able to enter the authentication required as they won’t have it.

• If the NuGet package is installed during installation, and always get the latest available presumably our install may fail at a later date if the NuGet package is updated by the supplier which breaks our install somehow. Is there a way around this if the NuGet package is downloaded on the client?

Many thanks, Confused!

Answer 1

The most straightforward way in handling 3rd-party packages is to use their redistributable installers for end-users (e.g., with Burn). Presumably they have dealt with all the issues required for their target platforms, will continue to do so in the future and may have even provided an update mechanism. That would be definitely true for many components from Microsoft, such as the .NET framework and VC runtimes.

Nuget is for developers. It downloads dependencies, adds them and possibly source code, configuration elements, etc to projects. So, it is not normally used to distribute libraries to end-users. If the library doesn't have its own installer for end-users, you can (if allowed by the license) include it in the setup for your product or in a separate setup as you suggest.

Underlying this, as always, is how your application will deal with different versions of libraries and how it will find them at run-time. That can be very simple but is a whole other topic in itself. You'll have to consider this in your installation design and build process.