Where to put the .nuspec in your project?

Sep 13, 2010 at 11:25 PM

I'm taking some real projects and seeing what it would be like to drop in a .nuspec file and create packages for them. I'm curious: where do we expect developers to put the .nuspec file, and when do we expect they will create packages?

Is the idea that they are adding the .nuspec into their project root, and building the package from the NuPack Console? Is that a scenario we intend to support? (I assume it is, otherwise why have the New-Package command in the console.) The problem with this is that all of the surrounding files are implicitly added to the package's contents, which includes things like source files and other stuff you won't want in your package.

Is the idea instead that folks are including a .nuspec file with the build output, and then packaging after the build (either manually or in some automate fashion)? If this is the case, I guess it doesn't matter where I put my .nuspec file in VCS, as long as it is makes it into the build output. In this case, implicitly adding surround files is not a problem, unless there are build artifacts I don't want in the package.

If we expect folks to build packages in the NuPack Console, implicitly adding files might not be a good idea. If that isn't the expectation, I'd like to know what is, so I can assess the impact of the implicit file addition, and so I can assess how .nuspec files end up with their contents.

P.S., I think I prefer only explicit contents (like gems), even if it means a larger .nuspec file. :P


Sep 13, 2010 at 11:30 PM
Edited Sep 13, 2010 at 11:30 PM

We actually have some nuspec files for internally built packages and what I did was something like this:

  • Create the nuspec file at your project root
  • Set "Copy to Output Directory" to Copy always or Copy if newer
  • Specify the files you want in the package (now it's relative to bin folder since the nuspec file is there)
Sep 13, 2010 at 11:34 PM

Do you exclude the .nuspec file at the root, and include the one in /bin/{mode}? Otherwise, running New-Package in the console is going to use the one in root. Or are you suggesting that you wouldn't run New-Package in the console?

Sep 13, 2010 at 11:37 PM

(Oh, and I should be clear that I think adding a file from /bin/{mode} would be silly, and I expect you'd agree. Just to be silly, I tried doing that just now, and the console couldn't find the .nuspec file when I ran New-Package.)

Sep 13, 2010 at 11:41 PM

It's not silly so I don't agree :). Also the nuspec file isn't added from disk, it's recreated while building the package. If I have a library A.dll I'd do what I said above and have one line in the nuspec file that specifies the A.dll in the output directory bin\{mode}. I was also more thinking of an msbuild target that runs the command line tool, not using New-Package in nupack console.

Sep 13, 2010 at 11:44 PM

I don't mean dropping the .nuspec file there is silly; I mean that adding into the project in VS so that you can run New-Package is silly.

Yes, dropping it in for a post-biuld package makes sense, but then why have a New-Package command in the console. I'm trying to find a valid scenario for using New-Package in the console.

Sep 13, 2010 at 11:51 PM

As the owner of mutliple oss projects I think this thread is way off track. I am mobile right now but will respond with more detail later.

Sep 13, 2010 at 11:57 PM

Thanks Eric.

I know how I'd package ColorCode, but I don't want to color the discussion with my thoughts (at least, not just yet). I want to see how the team thinks folks will package projects.

Sep 14, 2010 at 12:34 AM
Edited Sep 14, 2010 at 1:17 AM

Eh, screw it, I'll color it.

I wouldn't worry about creating packages each build in CI; I'm never going to touch them. I want to create a package at minor and major release points (this is putting aside the notion of edge or --pre or something similar). If I'm using MSBuild, I probably create a build target that handles all of the packaging details, so I can just `build package` manually when needed and then take the output and upload it to the feed.

The only reason I might want to build the package from within VS, in the console, is to test or play with the package. But the .nuspec file is going to live in a very different place in that case, so implicitly adding contents seems like a bad idea. Then again, even if I explicitly add the contents, any relative file and folder references will be wrong. We can add some sort of -BaseDir option to New-Package, but I'm not sure there is a lot of value in it. Alternatively, I could just run New-Package -Package path/to/my/drop.

The real reason for this thread is I want to know how we will support people creating new packages, so I can test those stories.

Sep 14, 2010 at 12:36 AM

I think it's a very fair question to ask.  We need to figure out what a clean/standard workflow might be for people to create packages from a project.

Sep 14, 2010 at 2:30 AM

Yea we don't have a good end to end workflow as yet.

Sep 14, 2010 at 2:48 AM

Sorry, that bold came off more agitated-looking than I intended. I just wanted to be clear, that I'm looking to learn *all* of the ways we intended and support for people to create new packages.

Tomorrow I'll lay out all of the different approaches I can see as a starting point for the conversation. We at least need to settle on the stories for the upcoming release pretty quick.

Sep 14, 2010 at 6:49 AM
Thanks Drew, I think laying out the options will be helpful to push the discussion along. Also, looking at existing projects and walking through how we'd expect them to build a package given their current source structure is a worthy exercise.

Sep 14, 2010 at 1:47 PM
So the way I will create packages for my existing oss projects will be to modify my existing build scripts outside of visual studio.  I think most mature oss projects already are using build scripts to create their release packages, they currently exist in the form of zip files or self extracting exes.  For me, I actually have scripts in nant and psake. They typically copy all the files and docs into a temp folder structure that I can use to zip up an make a package.  I like this work flow, because it is easy to debug a file missing.  I can look at the work in process and see if something is missing along the way. I also create my packages in a way where I do not maintain single file names but rather use wild cards and exclusions.  I see adding an additional step to my existing builds where I copy in files needed for a nupack package.  I will create the simplest nuspec file possible and specify the least amount of xml and rely on the file and folder conventions and use my build script to put files in the correct sub folders.
I do not personally see any value in creating a package as part of the visual studio build experience. That seems like a non repeatable manual process that we typically try to avoid.  Also, to this point. All of my projects use build scripts that can run without having visual studio installed on the build machine. I do this to ensure that all of my dlls are referenced and included in my source control tree and my only machine dependency is the correct version of the .Net Framework.
I hope this gives at least one point of view.
Sep 14, 2010 at 3:37 PM

That’s a very good point. I agree that many developers will probably build these things outside of visual studio using build scripts.

However, I do think we should not discount the Visual Studio experience. Imagine that I’m Joe Corp developer and I have an internal library that I want to share among my other corp drones. I’m not an OSS developer. I just set up an internal package feed on \\corp-share\packages and want to simply build my package from VS. There’s no need to make it harder than it has to be.

Another scenario is that while I agree that many OSS projects use build scripts outside of VS, I have seen many use the slingshot task (http://nantcontrib.sourceforge.net/release/latest/help/tasks/slingshot.html) from within their main NAnt build and then use that task to run the build part. After all, why duplicate all the information that’s already within a solution (and its proj files)?

So I do see value in having package creation as part of Visual Studio for some people. I don’t think we can completely discount it. But I do agree that perhaps it’s a lower priority than focusing on the build script scenario.

Sep 14, 2010 at 3:51 PM


Sep 14, 2010 at 4:32 PM

+1 on Eric's statements. I do not use Visual Studio for the build. I have not found but a small handful of projects that use vs for the build.  Most all do not because there are so many aspects of a "build" and vs only does compile without some finagling (technical word there).

"Be passionate in all you do"


Sep 16, 2010 at 1:14 AM
+1 with Eric


On Tue, Sep 14, 2010 at 11:32 AM, ferventcoder <notifications@codeplex.com> wrote:

From: ferventcoder

+1 on Eric's statements. I do not use Visual Studio for the build. I have not found but a small handful of projects that use vs for the build.  Most all do not because there are so many aspects of a "build" and vs only does compile without some finagling (technical word there).

"Be passionate in all you do"


Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com