我有一个包含许多项目的大型解决方案，其中一个是安装项目。还有许多当前版本存储在单独的分支中。我有一个曾经在 .NET 2 中工作的构建工具，但自从我们升级到 .NET 4 后就不再工作了。
在内部，新的 .NET 4 版本的构建工具使用Microsoft.TeamFoundation.Client.RegisteredTfsConnections.GetProjectCollections() and versionControlServer.GetAllTeamProjects(false)得到一个集合TeamProject来自我的 TFS 源代码控制服务器。
然后，我在 UI 中直观地显示它们，当用户单击特定的解决方案版本时，应用程序将调用以下命令来获取该解决方案版本的最新版本：
workspace.Get(new string[] { serverPath }, VersionSpec.Latest, RecursionType.Full,
GetOptions.GetAll);
用于构建解决方案文件的应用程序，其中包括安装项目。在此阶段，安装项目将创建一个可以安装应用程序的 MSI。这是我遇到问题的最后一步。
我需要能够使用 C# 代码以编程方式构建用户选择的解决方案。其工作 .NET 2 代码如下：
Process process = new Process();
ProcessStartInfo processStartInfo = process.StartInfo;
processStartInfo.FileName = processName;
processStartInfo.Arguments = string.Format(" \"{0}\" /BUILD \"Release|Any CPU\"",
solutionPath);
processStartInfo.WorkingDirectory = processDirectory;
process.Start();
运行时没有错误，但它不再启动 Visual Studio 并生成代码。显然，这最初是一个糟糕的方法，但我找不到使用 TFS 类的“正确”方法。
我还尝试直接运行 MSBuild.exe（类似于上面的示例），这确实构建了解决方案，但由于某种原因没有构建生成 MSI 的安装项目。请注意，我不使用任何手动创建的构建文件。
不幸的是，很难找到 Microsoft.TeamFoundation 命名空间的有用文档！我希望这里有人已经使用了这些类，并且可以指导我解决这个问题。
如果可能的话，我需要使用 .NET 类（例如，不是 Process.Start），因为我确实需要知道构建何时完成。不过我可以设置一个FileSystemWatcher如果要求过高，则反对。
