NuPack MSBuild Task

Oct 7, 2010 at 6:25 AM

I'm working on a first take of a NuPack MSBuild task, only for creating packages. For the first take, I'm keeping things simple: you give it the path to a .nuspec file and it will make the package in the current working directory. I can think of several other behaviors to enhance it, but it seems prudent to start simple.

I have a few questions:

  1. What do you think of this as for the "spec": <NuPack Specification="<path-to-file.nuspec>" />?
  2. I'm thinking folks will only ever want to create packages with MSBuild; does anyone else think otherwise?
  3. How will we deliver this? Folks will need to reference the .dll in a <UsingTask />; should the NuPack.MSBuild.dll itself be distributed as a package?
Oct 7, 2010 at 6:42 AM
  1. I think that's fine
  2. Or the command line tool if they're using another build system.
  3. IlMerge NuPack.Core into NuPack.Msbuild and let them do using task.
Oct 7, 2010 at 6:45 AM

1. Should provide another (optional) parameter to set the output .nupkg file name/path.

Oct 7, 2010 at 6:47 AM

Re: 3, Yeah, I planned to ILMerge Core, but how are they getting the merged .DLL? I was thinking if I want to use the NuPack.MSBuild.dll I'd just get it via NuPack as a package.

Oct 7, 2010 at 6:48 AM

Re: 2, I mean, I don't think folks will want to install, update, or uninstall packages with MSBuild. I didn't mean they would only use MSBuild for creating packages. :)

Oct 7, 2010 at 6:53 AM

dotnetjunky, I was thinking of only supporting the same options as NuPack.exe for the first take of this. Do you think an optional output target is important from the start?

Oct 7, 2010 at 6:57 AM

People are already asking for such parameter for NuPack.exe (

Oct 7, 2010 at 7:05 AM

Okay, I'll go ahead and add it. Here's what I'm thinking now:

<NuPack SpecFile="<path-to-file.nuspec>" PackageFile="<optional-path-of-created-package-and-must-end-in-.nupkg>" />

Oct 7, 2010 at 7:06 AM

What about OutputPath and not let them specify the file name

Oct 7, 2010 at 7:10 AM

Yeah, I like that better. The issue only mentions setting the destination path. MSBuild tasks usually use the word Dir or Directory, so how about OutputDir?

Oct 7, 2010 at 8:10 AM

And I don't mean to add more work for you (but I will :P) but if you're going to add the output dir anyways, might as well also do it for right?

Oct 7, 2010 at 8:19 AM

It's funny that bug is filed, I'm sure you can specify the output path (since I added that code long ago). Was that bug filed because the help text doesn't show the options or did anyone even try it :)?

Oct 7, 2010 at 8:21 AM

Ha! I didn't file the bug. Mark it as fixed and assign to Drew. :)

Oct 7, 2010 at 8:25 AM

Yeah, scanning the code, it looks like it will work, but it isn't reflected in the usage. You should fix the usage before marking it fixed. :P

Oct 7, 2010 at 8:56 PM

Re: 2. Rake, Nant and MSBuild can use an executable task to run the exe. I don't believe it's worth the effort to do anything more or you will see duplication of effort and possible synchronization issues where the msbuild task does this but the command line tool does this.

Just give people the code for running the executable to add to their msbuild scripts.

This is coming from experience in building and maintaining a build system and also providing and maintaining tools that can be used by automation suites.

Just the code to run the exe for people to insert into their build scripts.
"Be passionate in all you do"

Oct 7, 2010 at 9:23 PM

Just saying, if we are going to do one, we have to at least also provide Nant. People still use it and we can't ignore it. That also means a dependency on nant.core.

Oct 7, 2010 at 9:24 PM

Time to fire up NuPack.Contrib!

Oct 7, 2010 at 9:33 PM

I don't want to run my MSBuild against the EXE. If the MSBuild task doesn't belong here, that's fine; I'll put it somewhere else and distribute it as a package.

I think if other folks want NAnt, et. al., that's great; they can do the work and send a pull request. I say this not as a Microsoft employee, but somebody that has OSS projects that currently use MSBuild. Yes, I'm selfish. These are obviously just my thoughts. :)

Oct 7, 2010 at 9:47 PM

Submit it to the MSBuild Communit Task project. It's full of all kinds of Tool Tasks like this.

Oct 7, 2010 at 9:57 PM
Hopefully that didn't come off wrong, not my intentions. I'm trying to think more towards the impression we present as an OSS tool for those with a critical eye.

With respect to one of the projects I run, I provide MSBuild/NAnt tasks and a command line tool for RoundhousE. After maintaining that and adding and removing a bunch of switches (like nearly 40, one required), I've come to the conclusion to sunset the msbuild/nant tasks and just provide a sample of how to hook up the executable. Less maintenance, everyone is using the same tool (for issues/questions), and everyone 

With respect to the build framework, I've found over time developers move towards just having people run the command line runner, so that's what I've migrated to using with UppercuT. The task gets out of sync and they keep the command line version up to date. It's more a duplication of effort and over time people stop duplicating and let the msbuild/nant task fall into deprecation.
Oct 7, 2010 at 10:09 PM

If anything, I probably came off wrong. I definitely see what you're saying, and I think most people will just use the CLI anyway. Heck, I wrap all of my MSBuild-bases stuff in PowerShell as it is.

I'm honestly not convinced that we need the MSBuild task, aside from the fact people are asking for it. But we could try suggesting they go the <Exec> route. The benefits of a true MSBuild task are limited unless you need input/output handling and advanced logging, which aren't the case here.

And, to be clear, I'm not opposed to NAnt. I just don't like it personally, for most of the reasons I don't actually like MSBuild very much (writing spec's in XML is on my top 10 ideas for torture). I dream of a viable, mature rake equivalent for .NET, that plays nice with the solution and project systems. I forget that folks that don't know me might think I have a bias for Microsoft, working for them, and therefore MSBuild. Folks who know me, know that is most certainly not the case. :)

It's ultimately up to the project's team whether to take this. I'm perfectly happy putting is elsewhere. I'm nearly done, so unless I hear otherwise, I'll put up the code review, and let the chips fall.

Sorry to be jack-ass,


Oct 7, 2010 at 11:02 PM

If there’s an MSBuild Contrib, that seems like a good place. Otherwise, if someone starts a NuPack Contrib, that’d be a great place as well. Until then, keep it here and see what happens. J