TFS 2012 CodeActivity Executing System.Diagnostics.Process Issue

Question

I have a fairly complicated build process that involves a modified workflow template, various custom workflow tasks, and code activity tasks executing in a TFS 2012 environment.
This complex process boils down to creating a self extracting self executing archive using 7zip's command line tool.  I've created a custom C# CodeActivity that takes in various parameters on what to compress, where to put the output, etc.
The activity uses the System.Diagnostics.Process object to start a synchronous process for invoking the command line tool.  Here's s snip-it of the code:
string Invoke7Zip(string sevenZipExeFilename, string workingDirectory)
if (File.Exists(Path.Combine(workingDirectory, TEMP_ARCHIVE_FILENAME)))
File.Delete(Path.Combine(workingDirectory, TEMP_ARCHIVE_FILENAME));
ProcessStartInfo pInfo = new ProcessStartInfo(sevenZipExeFilename, string.Format("a -t7z {0} * -m0=BCJ2 -m1=LZMA:d25:fb255 -m2=LZMA:d19 -m3=LZMA:d19 -mb0:1 -mb0s1:2 -mb0s2:3 -mx", TEMP_ARCHIVE_FILENAME));
pInfo.WorkingDirectory = workingDirectory;
pInfo.StandardOutputEncoding = System.Text.Encoding.GetEncoding(System.Globalization.CultureInfo.InstalledUICulture.TextInfo.OEMCodePage);
pInfo.RedirectStandardError = pInfo.RedirectStandardOutput = true;
pInfo.UseShellExecute = false;
pInfo.CreateNoWindow = true;
Process p = new Process();
p.StartInfo = pInfo;
p.Start();
p.WaitForExit();
string stdOutput = p.StandardOutput.ReadToEnd();
string stdError = p.StandardError.ReadToEnd();
if (string.IsNullOrEmpty(stdError))
stdError = "NO ERRORS REPORTED";
return string.Format(COMPRESSION_REPORT_FORMAT, Path.Combine(workingDirectory, TEMP_ARCHIVE_FILENAME), stdOutput, stdError);
I have a test project in which I invoke these activities in order to unit test them.  On my local dev machine the activity executes correctly. When run from TFS it appears to hang on p.WaitForExit();. I'll remote into the build machine and see the process
opened but not using any resources (sitting idle consuming no processor unlike my dev machine test which uses a large amount of CPU).
Is there a limitation from invoking processes from activities involved with a team build?
EDIT:
I should note that I am migrating away from the use of InvokeProcess activity so that I can generate reports. When using the InvokeProcess activity it would take about ~6min to complete the compression. I've let it sit for 30min in this activity without
any progress.

Answer 1

Hello John,
Thank you for responding. I think you may have missed part of my explaination.  You are correct stating that I did say that my code activity correctly runs in a test project on my local machine.  However please see this quote from the original
question:
I have a test project in which I invoke these activities in order to unit test them.  On my local dev machine the activity executes
correctly. When run from TFS it appears to hang on p.WaitForExit();.
After verifying a correct run in the test project on my local machine I've pushed the custom assembly into the BuildAssemblies folder of TFS (which is where the controllers point to) and started a build in which the code activity is to be executed. 
When the build gets to the code activity it essentially hangs. I've let it sit for over a half hour in just this one task. That's longer than a previously successful build would run. If I RDP into the build machine I can see the process running under the
build controller's account and can terminate it. This will cause the build to continue.  To be clear, this does not happen in my local testing project.
As an additional piece of information I would like to point out that all dependencies of the console application are in source control and are part of the workspace which is created during the build (again, invoking this process does work when using the
InvokeProcess task).
I appreciate your follow-up and finding someone to help me further with this issue. It's kind of frustrating that I have not been able to figure out what is exactly causing this to happen.
Regards,
Mike G.