This project is read-only.

NuGet Package MSBuild.Extension.Pack Design Issue

Aug 24, 2012 at 2:22 PM

I'm trying to use the NuGet package MSBuild.Extension.Pack 1.0.0, and I'm not sure what the design goals of the package where, but I assumed (yeah, I know), that it was for adding the MSBuild Extension Pack to a solution so you can use in MSBuild scripts for the solution.  But I found a few issues, not all related to MSBuild Extension Pack.  

The first was that you can't use NuGet to add a package to a solution.  So, you have to add it to a project.  The second NuGet issue was that most project types are not supported.  The only projects you can add a NuGet package to are the typical code projects (C# and VB).  Which, in the case of MSBuild tasks doesn't really make sense, since you probably want to add it to a build project.  Since there isn't really a build project type, I tried the Setup Project (next logical choice), and that is how I found NuGet doesn't work with most project types.

So, I decided that since I had to use a code project type, I'd just add the MSBuild Extension pack to my NUnit test project.  But instead of installing a package that I can use within my solution, it added references to all the task libraries to the NUnit project.  So that is where I was sure if what I was trying to do (use the NuGet package to add the custom tasks to my project) aligned with the goals of the package.  It almost seems as though the package was built so someone can extend the custom tasks.  Was that the goal?


So, instead what I did is started to build a NuGet Pacakge with the goal of using the custom tasks within the solution, and no requiring the custom tasks to be installed on the machine.  I then made all the ref paths relative to the Solution and the pacakage folder.  Also, I was thinking of making it dependent on a StyleCop package, so this way the solution is totally independent and doesn't require things to be installed on the machine.

I can donate the code/NuGet package to the project, if it something you would like to add.

Sep 4, 2012 at 11:47 PM


More than happy to take on anything that will help users out with the nuget experience. Thanks!

Can you mail me to discuss further or attach a zipped patch?


Oct 31, 2012 at 1:06 AM
Edited Oct 31, 2012 at 1:08 AM


I am experiencing the exact same "frustration" as DonXML. I think my intention and ensuing questions/misunderstandings are similar. I want to use the nuget package at the solution level, not at any specific project (I simply need some msbuild tasks to customize the build process).

I prefer to use a nuget package because it's easier for anyone would download the code to build the solution if nuget package restore is enabled.

Also, I was expecting to find a .targets file... but there ain't any. Is there any reason? Right now I am declaring the msbuild extension pack tasks I need in every msbuild project (csproj/btproj/...) that needs them. But of course it's a PITA, even more so when you upgrade the package with the latest version from nuget... the path changes...

So, what did I do wrong, misunderstand? How can I get closer to what I want/need?

Thank you for your help


Nov 27, 2012 at 2:01 PM

Nuget packages like MSBuild.Extension.Pack that provide tools instead of code libraries, is better installed as part of the build script that requires them. That way you won't have to have a "fake" project to depend on these.

In a script, with the Nuget command-line tool you can easily do the following:

"$(NuGetExe)" install MSBuild.Extension.Pack -o "$(PackagesDir)"


I know that you cannot include the task library in the same script that installs it, but having a bootstrap script doing this before executing the actual script solves that problem.

Dec 10, 2012 at 3:05 PM

I raised a work item request ( to also produce a nuget package (.nupkg) as part of the build.  If anyone of you have similar requirement, please vote.



Marked as answer by mikeFourie on 5/26/2014 at 4:00 AM