Edit and continue feature stopped working in Visual Studio 2010

问题

The Visual Studio Edit and Continue feature stopped on Visual Studio 2010, and I don't know what has caused the problem.

I am working on a Windows application program using C#. This application was initially developed in Visual Studio 2008, and later upgraded to Visual Studio 2010.

Everything was working fine, including Edit and Continue, until I upgraded the .NET Framework from 3.5 to 4.0.

Now when I use debug mode, changing any line of the code in the IDE results in the following message:

Edits were made which cannot compiled. Execution cannot continue until the compile errors are fixed.

Actually, there are no compilation errors, and I must restart the Visual studio to get the updates to run.

How can I get Edit and Continue to work again?

回答1:

In the Solution Explorer view, right-click on each reference of References, choose Properties. In the Properties view, sign False to the field of Embed Interop Types. This works for me.

回答2:

The Edit and Continue feature does not work with the dynamic keyword.

I tried to remove the method that uses a dynamic parameter, and the converted project now works on Visual Studio 2010.

Internet research reveals that is is a bug that has been reported to Microsoft. The link below has more details:

Dynamic object as method parameters breaks edit and continue for the class and the project

回答3:

I had some Excel file "embed interop types" == true. When I changed it to false, edit and continue started working.

回答4:

I had used Microsoft's profiler yesterday and afterwards my "Edit and continue" feature got away. I finally realized after hours of frustration that I needed to execute VsPerfCLREnv /globaloff command from command prompt and restart my computer. Now I have my Edit and continue future back. It has nothing to do with target platform by the way. It works with target platform set to Any CPU without any hassle.

回答5:

I had this problem in Visual Studio 2013, and :-

Sometimes just closing and reopening the solution works, but when that doesn't
restarting Visual Studio (Close solution, exit Visual Studio, Re-open Visual Studio, re-open solution, re-try debugging with Edit & Continue) fixes it.

In my case, I didn't have any Interop types that were embedded, nor did any of my code have the dynamic keyword, and I had performed a full solution clean without success. I had been running, debugging and re-starting many times, however, so it may have had something to do with memory -- it took Visual Studio more than one minute to close, during which time the disk was thrashing (presumably memory paging at play).

回答6:

I'd try cleaning out all the files that are generated by VS. So I'd delete the bin and obj directories and I'd also delete the *.suo and *.user files. Since those files are auto-generated this shouldn't affect anything (though I'd obviously make a backup of all files just in case there's some other files that have been put in there by mistake).

Sometimes those files can get corrupted (it used to happen quite a lot in the old VC++ etc) and then VS can start acting very funny.

回答7:

I tried all the above solutions none of them worked for me. However, when I deleted the bin and object folders in visual studio and run again, it start to work.

回答8:

I understand this post is old, but I had this issue lately, and this blog post shows me how to fix it.

Delete the obj folder
Delete the bin folder. You can copy and paste libraries, data files, etc...back to the folder after removal.
From VS, menu Solutions -> Clean solution.

This works for me multiple times.

回答9:

working with VS2017 community I had this aggravating problem: if you port an existing project the tag EmbedInteropTypes may not be in the .csproj file yet, a search is futile. If that's the case, add the tag at the end to the property group Debug|x86 (or whichever you use) to the .csproj with a text editor:

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>

This must be done with all projects that belong to the solution!

回答10:

In VS2013 I had to enable "Use Managed Compatibility Mode" in the debugging options. I think it is because I have a .Net 4 project referencing a .Net 2 assembly.

For another project in the same solution I had to uncheck "Define TRACE constant" in the project properties.

回答11:

In my situation, someone added a Reference to the Project's output into the Reference list: in Solution Explorer look under [ProjectName]\References for [ProjectName*] and remove it.

If the project is relying on code from a copy of itself, you can't 'Edit and Continue'. In the warning list you may or may not (more likely to in a larger project) have 'conflicts with imported type' messages if this is the cause of the problem.

回答12:

In Visual Studio 2015, I've deleted the .vs folder (where the new style .suo file is), deleted all bin and obj, and also uninstalled Resharper 2015. Edit and Continue is back.

(side note: intellisense is now showing autocomplete almost instantly, whereas it was taking 2 to 5 seconds before, maybe resharper's fault, and maybe unrelated...)

回答13:

For me this was caused by Nuget failing to download a package (built for Net Framework) to a Net Standard project that was being referenced. Nuget entered an infinite loop (look in the output window).

The solution was to turn off the 'automatic package restore' setting see: https://developercommunity.visualstudio.com/content/problem/26638/nuget-infinite-loop.html

to access this setting Tools > Options > NuGet Package Manager > General

回答14:

I had to uncheck "Enable Native Edit and Continue" in Tools -> Options -> Debugging -> General:

回答15:

Reading the above, my UI project has Shell32 with "Embed Interop Types" == true. I changed it to false, and "edit and continue" started working.

回答16:

In the Solution Explorer view, right-click on each reference of References, choose Properties. In the Properties view, sign False to the field of Embed Interop Types. This worked for me.

回答17:

For who still gets this error even with Visual Studio 2017

No dynamic/Portable Class Libraries/Nuget packages or dependancy problems. No errors or warning highlighted by Visual Studio.

After hours spent trying all the solutions posted in this and other threads and webpages, the only solution that worked for me was to check-in, remove the Workspace and Map&Get again.

To remove the Workspace, Source control → Advanced → Workspace → Remove.

I'm using Visual Studio 2017 Community up to date and after a relatively fresh install on a new machine (one week and few work hours).

Methods I've tested with no success prior to the solution above

Made sure Edit & Continue was enabled in Visual Studio options. Untick and tick it back again
Deleting bin and obj for all project in solution
Clean and Rebuild all, restart VS / reboot in combination to the above
Checking compile options and Nuget packages and dll compatibility for the projects, inspired by this
Unloading the projects in various combinations to test dependancy problems or other issues (inspired by this)
Deleting solution an re-downloading it (without removing the Workspace)
Sign False to Embed Interop Types
Set <_ResolveReferenceDependencies> to true as explained here
Combinations of the above with restart of VS and reboots

After this, I made a check-in and downloaded the Solution on another machine running the same version of Visual Studio (2017 Community). As I didn't get the Edit&Continue issue there, I went for the Workspace removal.

回答18:

In my case, what worked was unchecking "Require source files to exactly match the original version" in Debugging options. VS Community 2017 here.

回答19:

Removing the * from the assembly versions of my referenced projects solved the issue for me.

From Github:

"I reproduced this issue on a mix of VB and C# projects with [assembly: AssemblyVersion(1.2.3.*")]. Once a VB project references a C# project with this setting things start collapsing. It looks like it has the same problem the other way around." -rhuijben

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

(At risk of being flagged, seems we have been suffering from VS Edit and Continue issues for over a decade. It's shocking to me that the Microsoft Visual Studio team hasn't cared enough to help developers by providing more verbose info when this occurs)

回答20:

I tried all the above, none worked. It was apparently due to enabling some low-level debugging options (view registers...)

Tools -> Import and Export Settings -> Reset All Settings

resolved it

回答21:

In VS 2015 this error was caused by a nuGet package I had recently installed. By uninstalling this package and reinstalling, the bug was fixed.

来源：https://stackoverflow.com/questions/4782057/edit-and-continue-feature-stopped-working-in-visual-studio-2010

标签

visual-studio-2010

debugging

edit-and-continue