好的，这是一个了不起的错误。我有一个2012解决方案，可以在2012 TFS服务器上执行MSBuild。传递给构建过程模板中“MSBuild Arguments”字段的参数如下:
/p:DeployOnBuild=true /p:PublishProfile=ProfileForProjectA /p:PublishProfile=ProfileForProjectB /p:VisualStudioVersion=11.0
我从TFS回来的错误是...
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets (4435): The value for PublishProfile is set to 'ProfileForProjectA', expected to find the file at 'C:\Builds\1\Solution\Solution\Sources\Solution\ProjectB\Properties\PublishProfiles\ProfileForProjectA.pubxml' but it could not be found.
换句话说，似乎构建服务器希望每个发布配置文件(* .pubxml)位于每个PublishProfiles文件夹中。两个项目的发布方法都是“文件系统”。
为我解决的唯一问题是将ProfileForProjectA添加到ProjectB的PublishProfiles文件夹中，反之亦然，但这似乎不是一个非常优雅的解决方案。任何人都可以重现这种行为吗？有谁有更优雅的解决方案？我想念什么吗？
提前致谢。
最佳答案
通过命令行传递属性时，它们是全局MSBuild属性。因此，它们被传递到.sln文件中的每个项目。 Web项目是唯一响应那些特定属性的项目。
在您的方案中，如果要在.sln文件中构建和发布两个项目，则需要在每个具有相同名称的Web项目中创建一个配置文件，例如“MyProfile”。它们不需要包含相同的信息，它们各自可以具有自己独特的一组设置。他们只需要分享一个名字。
然后在构建时。
msbuild.exe mysolution.sln /p:DeployOnBuild=true /p:PublishProfile=MyProfile /p:VisualStudioVersion=11.0
当构建每个Web项目时，将调用该项目中MyProfile的发布过程。
如果您要为PublishProfile指定不同的值，则需要创建MSBuild脚本而不是生成.sln文件。您可以通过几种不同的方法来解决它，但是它们都涉及一些MSBuild。
免责声明
不要将这种技术用于实时服务器...
但如果您要在最终发布之前将其发布到中间位置，那就太好了。
如果您在解决方案中构建+发布多个项目，则您可能会发布一个项目，而另一个项目甚至没有构建。这是因为发布过程实际上是构建过程的扩展。这是一个例子。
当您使用上面的属性进行构建时，您将在解决方案中拥有ProjectA和ProjectB，并且将进行构建和发布。然后它将继续到ProjectB，后者将生成并发布。 ProjectB的构建可能会失败，并且ProjectA应该已经发布。
关于tfs - MSBuild失败，出现两个软件包，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14226451/