在Visual Studio 2012中，版本之间的切换仍然会导致问题。

我们添加了一个预构建事件来删除obj文件夹:del /s /f /q $(ProjectDir)\obj，它修复了发布的问题。清洁有时有效，但并非总是有效。

这里我们遇到了同样的问题。

我们只需将“Publish method:”从“File System”更改为“Web Deploy”，然后立即将其更改为“File System”。

一个简单的解决方法是删除发布配置文件并创建一个新的配置文件。

当您右键单击解决方案并选择publish时，您就有了一个概要集。删除这个并创建一个新的。

这将解决问题。

从2010年切换到2012年，我就遇到了这个问题

不管怎样，我最终放弃了与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)中调用它，但它也可以很容易地连接到构建后事件中。

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

但我注意到我们的五个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" />

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

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

我有同样的错误，我改变了设置从发布调试和问题解决。