This project is read-only.


Create output folder fails if Output Directory is relative


When usinNuGetterMultiPkgBuildVersionedTemplate20.xaml and setting OutputDirectory relative (e.g., "Binaries\NuGetPackage"), the build fails on:

Create Output Folder if necessary
Exception Message: Value cannot be null.
Parameter name: path1 (type ArgumentNullException)
Exception Stack Trace: at System.IO.Path.Combine(String path1, String path2)
at TfsBuild.NuGetter.Activities.CreateFolder.Execute(CodeActivityContext context)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

Accroding to log, the drop location is not set:
Create Output Folder if necessary
Initial Property Values
DropLocation =
FolderName = Binaries\NuGetPackage
Final Property Values
DropLocation =
FolderCreated =
FolderName = Binaries\NuGetPackage
Closed Feb 9, 2013 at 4:19 PM by marknic
NuGetter is performing as designed. The behavior described would need to be added as an additional feature if pursued.


gius wrote Feb 7, 2013 at 4:05 PM

The same holds for relative Base path ("Sources").

marknic wrote Feb 8, 2013 at 3:03 AM

I'm not clear on what you are trying to do with the OutputDirectory. It should definitely be a relative path that originates in the drop folder. You mentioned "Binaries\NuGetPackage". I don't understand if you are trying to create a "Binaries" folder within the drop folder or if you are thinking the folder should be in the Binaries folder within the build location. The workflow will try to combine the output directory value with the drop folder location to create the full output directory location.

If there is an issue with the drop folder itself then an error like this would definitely happen since the OutputDirectory is a relative location from the drop. No drop - no new folder to hold the output.

Is the drop folder location being set properly in the Build Defaults page of the build definition? I ask because the properties you show don't show the DropLocation.


gius wrote Feb 8, 2013 at 11:42 AM

The problem is on the drop location - as you can see from the log, an empty value is passed to the process. Also, the exception is from line Path.Combine(dropLocation, outputDir) where dropLocation is null.

So, what can be the cause of this DropLocation being null/empty?

marknic wrote Feb 8, 2013 at 10:43 PM

On the "Build Defaults" tab of the build definition, is "Copy build output to the following drop folder..." selected and is there a UNC path (share location) identified as the place to drop the build files?

One last check, when you queue the build, is the drop folder there in the "General" tab?


gius wrote Feb 9, 2013 at 9:11 AM

The Drop Location in Build Defaults requires a UNC path. It is not set as I just wanted the drop location to be the default one (D:\TFSBUILDAGENT\Builds\1\Dev\MyBuild).
So, maybe there is my misunderstanding.

Shortly - all I want to do is to use "Binaries\NuGetPackage" instead of "D:\TFSBUILDAGENT\Builds\1\Dev\MyBuild\Binaries\NuGetPackage" in Base Path and Output Directory.
Relative Base Path used to work in the TFS2010 version, whereas I had to set Output Path as absolute even then. Now, both of the paths had to be set absolute to work properly.

marknic wrote Feb 9, 2013 at 4:13 PM

Ok, we both had misunderstandings. I was unclear on the fact that you want to use the build location directly instead of the drop. If you don't specify the build drop location then it makes sense that it would be empty during the build process. Unfortunately, for what you are trying to achieve, the NuGetter workflow is relying on the drop location. This is for a good reason though.

You mentioned the "default drop location" but that's not the drop, that's the build where all compilation activities happen. The problem with using that location is that the build is never versioned, it is overwritten every time the build happens whereas the drop location is versioned - every build gets a new subfolder named after the build and the "build number format". That location is by far, the more recommended approach for building applications. Not using the build drop would be a way to simply verify compile and unit test.

Because of these reasons, I am going to close this issue since NuGetter is performing as designed and intended. However, I encourage you to open up a discussion thread - especially if you would like to share reasons behind your intended approach and why you think NuGetter should directly support it.

Thanks for the responses,


wrote Feb 9, 2013 at 4:14 PM

wrote Feb 9, 2013 at 4:15 PM

wrote Feb 9, 2013 at 4:16 PM

wrote Feb 9, 2013 at 4:19 PM

wrote Feb 22, 2013 at 12:00 AM

wrote May 16, 2013 at 11:38 AM