Interesting trail of events you've been having. Thanks for passing on all of the information.
Answer to your first question: No, you don't need NuGet.exe "installed" in TFS more than once and by installed I just mean that it exists in a source control folder and you pass that path in the build definition. You probably know this but, you
don't have to put it in TFS if it is on your build machine.
The reason why System.Management.Automation.dll was not available may be due to the OS on your build machine and what was installed on it. The assembly is used to allow the calling of PowerShell from .NET. It is installed on my build machine
in the GAC. I don't have much more info on its origins at this point.
And, that brings us to the NuGetPackage folder. I came up with that name as a convention, there's nothing special about it at all. Its purpose is just to be a destination for the packaging step. If you have a simple project then your assemblies
end up in single folder in the "drop" location. The nuspec file says here's how I want the package and NuGet.exe packages things up and puts the nupkg file where you tell it to. This is what the NuGetPackage folder (aka, the Output Directory) is
meant for. If NuGet gets all the info it needs and you tell it to put the output in that folder then that's where they will end up. Likewise, I created the "prepackage" folder, this is where you can organize more complex (multi-framework) projects
into a single folder that is the input to NuGet. And, again, the output would be the NuGetPackage folder (if you follow my convention).
A simple way to look at it is this: In the build definition, the "Base Path" is the source location for the NuGet.exe processing and the "Output Directory" is where NuGet puts the newly generated package. I used NuGetPrePackage and NuGetPackage as
the names of these folders. I tried to keep the context of the NuGet.exe (parameter names, process, etc.) as close as I could to the command-line calls.
All of this extra "stuff" like the PowerShell script and the prepackage folder is there if you need it - especially when things get more complicated than a single assembly. Over the years I have tried to create builds that were not done until
the output of the build process looked almost identical to what it would look like when it was installed on a production machine. Then, the packaging process (in this case NuGet but could also be an msi) did not have to do anything special to generate
the package. I just said, here's the files, go package it up.
In your case, the Base Path should be set to the name of the folder where your assembly was created, then NuGet does its thing and outputs into NuGetPackage.
That's a big brain dump. Let me know how things are going and if you need more help.