Edit and continue feature stopped working in Visual Studio 2010

Question

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?

Answer 1

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

Answer 2

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.

Answer 3

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

Answer 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.

Answer 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).

Answer 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.

Answer 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.

Answer 8

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!

Answer 9

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.

Answer 10

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.

Answer 11

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...)

Answer 12

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.

Answer 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

Answer 14

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

Answer 15

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.

Answer 16

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.

Answer 17

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

Answer 18

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

Answer 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)

Answer 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

Answer 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.