不管怎样，我最终放弃了与Web Deploy的斗争，让它做我想做的事情(复制可部署的文件，不做其他任何事情)，所以我在PowerShell中编写了脚本，对结果非常满意。它比我通过MSBuild/Web Publish尝试的任何方法都快得多，大概是因为这些方法仍然在做我不需要的事情。

以下是要点(字面意思):

function copy-deployable-web-files($proj_path, $deploy_dir) {
  # copy files where Build Action = "Content" 
  $proj_dir = split-path -parent $proj_path
  [xml]$xml = get-content $proj_path
  $xml.Project.ItemGroup | % { $_.Content } | % { $_.Include } | ? { $_ } | % {
    $from = "$proj_dir\$_"
    $to = split-path -parent "$deploy_dir\$_"
    if (!(test-path $to)) { md $to }
    cp $from $to
  }

  # copy everything in bin
  cp "$proj_dir\bin" $deploy_dir -recurse
}

在我的例子中，我在CI环境(TeamCity)中调用它，但它也可以很容易地连接到构建后事件中。

我在VS 2010上遇到了同样的问题，在检查发布输出，事件日志，打开和检查visual studio日志等之后，我决定删除web发布(通过添加/删除)，我相信最近更新到v1.0.30810.0。这就解决了问题。

我发现我可以通过改变目标位置从obj/[释放|阶段|..]到解决方案文件夹之外的新路径，例如c:\deployment。看起来VS 2012有点混乱，可能在发布过程中就放弃了。

Matt

以上的方法对我来说都没用。

但我注意到我们的五个ASP。NET MVC项目在我们的主要解决方案中，其中四个将部署包放在正确的位置，而一个将它留在obj\Debug下。

我比较了这些项目，发现了不一致之处。解决办法是改变这一点:

<Import
    Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

:

<Import
  Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets"
  Condition="'$(VSToolsPath)' != ''" />
<Import
  Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
  Condition="false" />

在我做了这个更改之后，所有五个项目都将它们的部署包放在了正确的位置。

(很抱歉排了这么长的队，但我找不到更好的方式来浓缩它们。)

这是因为.pubxml. xml。User包含发布所需的信息，该文件没有(也不应该)包含在源代码控制中。要修复这个VS错误，请从.pubxml. xml文件中复制信息。用户文件到.pubxml文件。相关属性为:

<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>

把它们放到.pubxml中，就可以开始了。

同样的问题与VS 2012 Pro的磁盘发布目标。项目用来正确发布，但开始做这个问题，它无法将文件复制到目标文件夹。

解决方案是编辑发布配置文件，将模式从发布(任何CPU)更改为调试，然后返回发布(任何CPU)。这样做会导致PublishProfiles\projname.pubxml。要重写的用户文件(如上所述)。看起来它在propertygroup节点下添加了LastUsedBuild,LastUsedPlatform和TimeStampOfAssociatedLegacyPublishXmlFile元素。发布完成后，它将添加另一个ItemGroup，其中包含单独的文件和发布时间。