This project is read-only.

Building Multiple packages from a single solution/build?

Nov 3, 2011 at 1:03 PM

I've got a solution that's building a selection of related, and interdependent libraries, which I've got configured with nuspec files for each of them. I've been using the NuGetPowerTools package for building, and it's worked OK, but I'd like to move to using NuGetter for this.

My question is, what's the "right" way to go about doing this. I could tweak the XAML file to split a semicolon (;) separated list of nuspec files and iterate through each one, or do something that'll follow wild cards (**\*.nuspec) but I'd like to not reinvent the wheel if others are working on this, and I'd like to make something that might be accepted back into the package.

So, anyone have any suggestions?




Nov 4, 2011 at 3:51 PM


I haven't tried this approach but within the build template there is an "If" activity called "If NuSpec File Path not provided then no packaging".  That step in the workflow is looking for the nuspec file which starts the NuGet processing.  I would think that you could wrap this in a loop for each nuspec file that you want to process.  Obviously you will need to add activities that parse your list of nuspec's but that should get things moving fairly quickly. 

Deployment may need some work as well depending on your needs, if you do it at all, etc.

Let me know if you try this and how it goes.  I will continue to assist where I can.



Nov 4, 2011 at 7:22 PM

That's basically what I've done. I've gone with the wildcard idea, overloading the use of the NuSpec File Path to accept \MySourceRoot\**\*.nuspec.

Also, I'm swapping out the nuspec for an available csproj (of the same name) when passing it to pack, so I can take advantage of the automated replacement variables in NuGet 1.5.

Currently hitting an issue where it's unable to find the built assembly, because it ends up in Binaries, rather than the default location (nuspeclocation\bin\Debug, for example):

Error reported in the NuGet Process: Unable to find file "C:\Builds\1\Project\Build\Sources\...\Bin\Debug\Project.dll." Make sure the project has been built.

The file exists in "C:\Builds\1\Project\Build\Binaries\Namespace\Project.dll", and I'm trying to pass that directory as my basepath, but I guess it's not using that the way I expect it to. I guess I'm doing something stupid, but I'd love any help you can give. (and yes, this isn't related to the original issue)



Nov 4, 2011 at 8:54 PM

What about the drop location?  What is ending up there?


Nov 7, 2011 at 1:36 PM

The appropriate DLL and PDB are showing up in the drop location. Not really sure what else to look at.



Nov 7, 2011 at 3:25 PM

OK, got around it by doing the quick-n-dirty of passing -build to nuget pack through "Additional NuGet Command Line Options" configuration.

I'd still like to understand why it needs this, but it seems to allow me to move forward, anyway.


Nov 7, 2011 at 5:48 PM

OK, nevermind. I merged my changes back into my main branch, redirected the build back to that, and because the time was horrible, I changed the add'l command line options to -Symbols rather than -Build, and it worked. No idea why, but I guess as long as it works, we call this thread done.

Nov 7, 2011 at 7:07 PM

And 4th reply to self for the day. I'm back to passing -build to nuget, along with -Symbols, because it previously worked because the NuGetPowerTools build was still taking place, though I've now got it disabled, and had to add -build back in. Interestingly, the whole NuGet squence is taking between 3-10 seconds for my various packages, so it's almost certainly not actually rebuilding the packages.

Nov 8, 2011 at 1:27 PM

I don't understand why the process would need -build to run.  Obviously, it should already be built.  It is isn't it?

Nov 8, 2011 at 2:14 PM

From what I can tell, in the build directory, everything's built, but exists in the obj\Debug directory, but NuGet is looking for the output in the bin\Debug directory, which doesn't exist. By adding -build, it looks like the same stuff is simply pushed to bin\Debug (as if the last step or two of the build had failed) and then NuGet picks it up successfully.

Nov 8, 2011 at 4:47 PM

Sorry, I'm getting a little confused so I need to take a step back.  It makes sense that the only thing you see in the build/sources folder is obj because everything should be ending up in the drop location.  That location will use "debug" or "release" if you are building multiple configurations but if you're not, then the assembly(s) should end up in a folder named after the project. 

Are you pointing NuGet at the build folder or the drop?


Nov 8, 2011 at 6:14 PM

I guess the short answer is, I don't know. I know the NuSpec (and csproj) files I'm pointing it at are in Build. Do I need to have it copy the nuspec (and csproj, or work around the included replacements such as $description$) to the drop folder?


Nov 8, 2011 at 7:24 PM

I think your best bet is to get things in the drop folder and then work there.  The drop is the intended location for all of the newly built assemblies so that should be the source of your package creation.  Now, you may need some files that are back in the sources or binaries folders to complete the packaging process but that doesn't sound like what you are trying to do here - but, even if you did need to work with files from there, IMO, you should copy them over to the drop and work from there.  It's a one-stop location to see what your build actually did.

NuGetter definitely assumes the drop folder as the location to start looking for or creating files and folders.

Nov 9, 2011 at 5:05 PM


First, I get what you're saying, and I agree with you, but I think I'll keep doing it my way if I can work around my last issue (which I know I can, it's just a question of doing it the right way, or the functional/easy way.

OK, I remembered to turn on pushing, and it broke everything for me ;) Not your fault, just a side effect of what I did to continue using the csproj supported replacement variables. I think I'm going to ask if maybe nuget itself should have a query operation that can be passed either a nuspec or *proj file and return a queried piece of data, such as id. That'd work around my issue, but it's not an instant fix.

The instant fix is to move the files manually, rather than using the NuGetter push functionality. I'm using a shared directory for my repository, so it's trivial, and I think that's what I'm going to do short-term. But I'd like to try to work with you (Mark) to make this more flexible and easier for the next person who comes along and wants to do what I'm trying to do.


Nov 10, 2011 at 1:51 AM

Happy to.  Time to take this offline and get a little more efficient than a "forum".  I will contact you directly.



Feb 25, 2012 at 1:46 AM

I have the same need (create multiple NuGet packages from the same build). I'm just curious if any new approaches or fixes were discovered after the discussion went offline?