Getting around Nuget’s External Package dependency problem

I’ve already blogged about how to create simple Nuget packages using Rake and Albacore, now to the advanced part.

I used FluentMigrator as the example in my previous post and it was while creating the second package for FluentMigrator that I ran into a ‘feature’ of Nuget.

We had decided to divide the FluentMigrator package into two packages, the main core package and a new FluentMigrator.Tools package. FluentMigrator.Tools contains all the extra dlls that we didn’t want to put in the core package. Basically, there are four versions of the tools directory, one for each supported .NET version and per platform (.NET 3.5 and 4.0, x86 and x64). The idea is that if you need the x86 3.5 version of the migration runners then the core package is sufficient otherwise you need to fetch the FluentMigrator.Tools Nuget package.

The core package has a lib directory which contains the FluentMigrator dll. So I created a dependency on the core package in the Tools package so that when you download the Tools package from Nuget it also downloads the core package. This meant that the Tools package only contained a tools directory at the root, no lib and no content directory.

Side Note on how to test your Nuget package

To test your newly created Nuget package (always a good idea!) point your Nuget source in Visual Studio to your nupkg file. In Visual Studio 2010 go to Tools->Library Package Manager->Package Manager Settings then choose Package Sources in the left hand menu and add the directory which contains the nupkg file to be tested. Then when adding a package from the Package Manager Console, in the Package Source dropdown menu to the upper left you should have two choices now; Nuget official package source and your new test source. So choose your test source and install-package NameOfYourPackage and test it out.

To the heart of the matter

While testing the Tools package in the Package Manager Console I got the following incomprehensible error:

External packages cannot depend on packages that target projects

Steve Sanderson ran into this problem first and filed an issue on Codeplex in which he also mentions a workaround (Thank you Steve!). The reason for this error is that my new FluentMigrator.Tools package only contains a tools directory and no content or lib directory and Nuget has decided that it therefore may not be dependent on a package that does contain a lib or content directory.

The solution is a big, fat hack. Add a content directory with a dummy text file and then use a powershell script to remove it from the target project after you have installed the Nuget package.

Diving into PowerShell

At this stage you will want to have the Nuget documentation open so that you check out the different conventions around powershell and Nuget. I created a text file named InstallationDummyFile.txt and placed it in the content directory and a powershell file named install.ps1 and placed it in the root of the tools directory. install.ps1 looks like this:

param($installPath, $toolsPath, $package, $project)

$project.ProjectItems | ForEach { if ($_.Name -eq "InstallationDummyFile.txt") { $_.Remove() } }
$projectPath = Split-Path $project.FullName -Parent
Join-Path $projectPath "InstallationDummyFile.txt" | Remove-Item

It does two things:

  • Removes the reference to InstallationDummyFile.txt from the project by looping through ProjectItems until it finds the text file.
  • Deletes the InstallationDummyFile.txt file. First I get the path to the project file and store it in $projectPath and create a new path by joining it with the file name and then remove it from the project directory.

I am a total beginner when it comes to powershell so this was a bit of a struggle (and maybe will be for others?). The above calls are pipelines and start on the left with a bar (|) separating the different stages. E.g. The Join-Path function takes in two parameters and returns a new path to the text file, this is then passed on the next stage in the pipeline as a parameter. Remove-Item takes in the newly generated path as a parameter and deletes the file. Read the Nuget documentation for more info on the parameters passed in on the first line.

The Result

Now when you install the Tools package it first downloads its dependency, the core package, and adds a reference to the FluentMigrator dll in the target project. As the Tools package now has a content file, Nuget no longer classes it as an “external package”. Next Nuget installs the Tools package in the packages directory alongside the core package and calls install.ps1. This removes the dummy file from the project (both as a reference and by physically deleting the file from the project folder) and now there is no incriminating evidence left of us fooling Nuget. When creating my Rake script to run migrations, I can now refer to the console runner in the FluentMigrator.Tools directory in the Nuget package directory. Mission accomplished.

2 thoughts on “Getting around Nuget’s External Package dependency problem

  1. I had a similar issue. I resolved it by putting DUMMY.txt in the lib folder. Since it is a txt file there are no project reference side effects, and no need to employ powershell to remove it.

    1. Thanks for the tip. We will be changing the structure of the Nuget packages for FluentMigrator over the next couple of months so hopefully we’ll be able to do it in a more elegant way this time.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s