编辑并继续功能在 Visual Studio 2010 中停止工作

Question

Visual Studio 编辑并继续功能在 Visual Studio 2010 上停止，我不知道是什么导致了该问题。

我正在使用 C# 开发 Windows 应用程序。该应用程序最初是在 Visual Studio 2008 中开发的，后来升级到 Visual Studio 2010。

一切都工作正常，包括编辑和继续，直到我将 .NET Framework 从 3.5 升级到 4.0。

现在，当我使用调试模式时，更改 IDE 中的任何代码行都会产生以下消息：

进行了无法编译的编辑。执行无法继续，直到 编译错误已修复。

实际上，没有编译错误，我必须重新启动 Visual Studio 才能运行更新。

如何才能再次编辑并继续工作？

Answer 1

在“解决方案资源管理器”视图中，右键单击“引用”的每个引用，选择“属性”。在“属性”视图中，将“嵌入互操作类型”字段标记为 False。这对我有用。

Answer 2

“编辑并继续”功能不适用于 dynamic 关键字。

我尝试删除使用 dynamic 参数的方法，转换后的项目现在可以在 Visual Studio 2010 上运行。Internet

研究表明，这是一个已向 Microsoft 报告的错误。下面的链接有更多详细信息：

• 动态对象作为方法参数会中断类和项目的编辑并继续

Answer 3

我有一些 Excel 文件“嵌入互操作类型”== true。当我将其更改为 false 时，编辑并继续开始工作。

Answer 4

我昨天使用了微软的分析器，后来我的“编辑并继续”功能消失了。经过几个小时的挫折后，我终于意识到我需要执行 VsPerfCLREnv /globaloff 命令提示符并重新启动我的计算机。现在我有了我的编辑并继续未来。顺便说一句，它与目标平台无关。它可以与设置为任何 CPU 的目标平台一起使用，没有任何麻烦。

Answer 5

我知道这篇文章已经过时了，但我最近遇到了这个问题，并且这个 博客文章 向我展示了如何修复它。

• 删除obj文件夹
• 删除bin文件夹。您可以在删除后将库、数据文件等复制并粘贴回文件夹。
• 从 VS 中，菜单解决方案 -> 干净的解决方案。

这对我多次有效。

Answer 6

我在 Visual Studio 2013 中遇到了这个问题，并且：-

• 有时只需关闭并重新打开解决方案就可以工作，但是当这不能
• 重新启动 Visual Studio 时（关闭解决方案、退出 Visual Studio、重新打开 Visual Studio、重新打开解决方案、重新打开解决方案） -尝试使用“编辑并继续”进行调试）修复它。

就我而言，我没有嵌入任何互操作类型，我的任何代码也没有 dynamic 关键字，并且我执行了完整的解决方案，但没有成功。然而，我已经运行、调试和重新启动了很多次，所以它可能与内存有关——Visual Studio花了一分多钟才关闭，在此期间磁盘发生了剧烈的抖动（大概是内存分页在玩）。

Answer 7

我会尝试清除 VS 生成的所有文件。因此，我会删除 bin 和 obj 目录，并且还会删除 *.suo 和 *.user 文件。由于这些文件是自动生成的，因此不会影响任何内容（尽管我显然会备份所有文件，以防万一有其他文件被错误地放入其中）。

有时这些文件可能会被损坏（在旧的 VC++ 等中经常发生这种情况），然后 VS 就会开始变得非常有趣。

Answer 8

我尝试了上述所有解决方案，但没有一个对我有用。但是，当我在 Visual Studio 中删除 bin 和对象文件夹并再次运行时，它开始工作。

Answer 9

在我的情况下，有人将对项目输出的引用添加到引用列表中：在解决方案资源管理器中，在 [ProjectName]\References 下查找 [ProjectName*] 并将其删除。

如果项目依赖于其自身副本中的代码，则您无法“编辑并继续”。在警告列表中，如果这是问题的原因，您可能会或可能不会（在较大的项目中更有可能）出现“与导入类型冲突”消息。

Answer 10

在与 VS2017 社区合作时，我遇到了这个严重的问题：如果您移植现有项目，标签 EmbedInteropTypes 可能尚未出现在 .csproj 文件中，搜索是徒劳的。如果是这种情况，请使用文本编辑器将属性组 Debug|x86（或您使用的任何一个）末尾的标记添加到 .csproj：

before:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\x86\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <DocumentationFile>bin\Debug\MyProject.XML</DocumentationFile>
    <DebugType>full</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <ErrorReport>prompt</ErrorReport>
    <Prefer32Bit>false</Prefer32Bit>
  </PropertyGroup>

after:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
    <DebugSymbols>true</DebugSymbols>
    <OutputPath>bin\x86\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <DocumentationFile>bin\Debug\MyProject.XML</DocumentationFile>
    <DebugType>full</DebugType>
    <PlatformTarget>x86</PlatformTarget>
    <ErrorReport>prompt</ErrorReport>
    <Prefer32Bit>false</Prefer32Bit>
    <EmbedInteropTypes>false</EmbedInteropTypes>
  </PropertyGroup>

这必须使用 all 完成属于解决方案的项目！

Answer 11

在 VS2013 中，我必须在调试选项中启用“使用托管兼容模式”。我认为这是因为我有一个引用 .Net 2 程序集的 .Net 4 项目。

对于同一解决方案中的另一个项目，我必须取消选中项目属性中的“定义跟踪常量”。

Answer 12

在 Visual Studio 2015 中，我删除了 .vs 文件夹（新样式 .suo 文件所在的位置），删除了所有 bin 和 obj，还卸载了 Resharper 2015。
编辑并继续回来了。

（旁注：智能感知现在几乎立即显示自动完成，而之前需要 2 到 5 秒，可能是 resharper 的错误，也可能无关......）

Answer 13

对我来说，这是由于 Nuget 未能将包（为 Net Framework 构建）下载到正在引用的 Net Standard 项目而引起的。
Nuget 进入了无限循环（查看输出窗口）。

解决方案是关闭“自动包恢复”设置，请参阅：https://developercommunity.visualstudio.com/content/problem/26638/nuget-infinite-loop.html

访问此设置
工具>>选项> NuGet 包管理器 >一般

Answer 14

我必须在“工具”->“工具”中取消选中“启用本机编辑并继续”选项->调试->一般：

Answer 15

读完上面的内容，我的 UI 项目有 Shell32 且“嵌入互操作类型”== true。我将其更改为 false，然后“编辑并继续”开始工作。

Answer 16

在“解决方案资源管理器”视图中，右键单击“引用”的每个引用，选择“属性”。在“属性”视图中，将“嵌入互操作类型”字段标记为 False。这对我有用。

Answer 17

对于即使使用 Visual Studio 2017 仍然出现此错误的人，

没有动态/可移植类库/Nuget 包或依赖问题。 Visual Studio 没有突出显示任何错误或警告。

经过几个小时尝试了本文中发布的所有解决方案和 其他线程和网页，对我有用的唯一解决方案是签入、删除工作区并再次Map&Get。

要删除工作区，源代码控制→高级→工作区→删除。

我正在使用最新的 Visual Studio 2017 Community，并且在新计算机上进行了相对全新的安装（一周和几个工作时间）。

---

在上述解决方案之前我测试过的方法没有成功

• 确保编辑并删除在 Visual Studio 选项中启用了“继续”。取消勾选并再次勾选它
• 删除解决方案中所有项目的 bin 和 obj
• 清理并重新构建全部，重新启动 VS / 重新启动结合上述
• 检查项目的编译选项和 Nuget 包和 dll 兼容性，灵感来自 this
• 以各种组合卸载项目以测试依赖性问题或其他问题（受到这个的启发）
• 删除解决方案并重新下载（不删除工作区）
• 签署 False 以嵌入互操作类型
• 将 <_ResolveReferenceDependencies> 设置为 true，如下所述
• /stackoverflow.com/questions/20324080/visual-studio-2013-net-4-5-1-edit-and-continue-64-bit-not-working/20344017#20344017 ">此处 上面重新启动 VS 并重新启动

之后，我签入并在另一台运行相同版本的 Visual Studio（2017 Community）的计算机上下载了解决方案。由于我在那里没有遇到“编辑并继续”问题，因此我选择了“工作区”删除。

Answer 18

就我而言，有效的方法是在调试选项中取消选中“要求源文件与原始版本完全匹配”。 VS 社区 2017 在这里。

Answer 19

从我引用的项目的程序集版本中删除 * 解决了我的问题。

来自 Github：

“我使用 [程序集：AssemblyVersion(1.2.3.*”)] 在 VB 和 C# 项目的混合中重现了此问题。一旦 VB 项目引用具有此设置的 C# 项目，事情就会开始崩溃。看起来它也有同样的问题。” -rhuijben

https://github.com com/dotnet/roslyn/issues/28224

（面临被标记的风险，十多年来我们似乎一直受到 VS 编辑和继续问题的困扰。令我震惊的是 Microsoft Visual Studio 团队并不关心发生这种情况时，足以通过提供更详细的信息来帮助开发人员）

Answer 20

我尝试了以上所有方法，但没有任何效果。这显然是由于启用了一些低级调试选项（查看寄存器...）

工具 ->导入和导出设置->重置所有设置

解决了这个问题

Answer 21

对我有用的方法类似，但与接受的答案不完全一样。我通过 LINQ 查询创建了一个匿名类型；即

var thingy = (from thing in things select new { thing.Property1, thing.Property2 }).First();

当我将匿名类型更改为元组时，问题就消失了：

var (thing1, thing2) = (from thing in things select (thing.Property1, thing.Property2)).First();

Answer 22

我找出了我的项目不允许我在调试模式下继续和编辑的原因之一。
您不能拥有两个具有相同文件名的 C# 文件，即使它们位于不同的文件夹和不同的名称空间中并且可能具有不同的类名。我更改了类名，但仍然没有解决问题。您必须更改 .cs 文件名。

.Net Framework 4.8没有这个问题，所以.net core添加了这个功能。

Answer 23

在 VS 2015 中，此错误是由我最近安装的 nuGet 包引起的。通过卸载该软件包并重新安装，该错误得到修复。