visual-studio-2012edit-and-continue

Stale Code Warning on Edit and Continue in Visual Studio 2012 Express

In most of my projects, during debug mode if I see a small error I can edit the code during debug, choose apply code changes, and continue.

This generally works for most any minor change. If the changes are too extensive it will say insufficient space in the module memory, or if the changes modify a try-catch block it will screw up the stack unwind, so those special cases require a rebuild and restart. But pretty much anything else can edit and continue.

But for this one project, every little change no matter how insignificant I get a message "The source file is different from when the module was built. Would you like the debugger to use it anyway." And if I choose yes, then I get a warning that I am about to use stale code.

Why is this one project unable to update the source code to keep in sync with edit and continue changes? Did I inadvertently mess something up in the project settings?

source out of date warning stale code warning

UPDATE

I have tried every solution posed here and no luck. This is evidently a common problem because there are many posts on and off of SO about this topic. But it looks like no one ever has a reliable solution, evidently VS Edit and Continue is quite temperamental.

Opened a second instance of VS and loaded a prior project where I knew edit and continue does work. I re-verified that it does work. Then I put the project properties side by side and verified every switch and setting exactly identical. I then put VS options and settings side by side and verified every setting exactly identical. Yet edit and continue works in the one project, not in the other.

Solution

  • Evidently edit and continue is incompatible with COM objects linked using the #import directive.

    I discovered that only one module of my project had stale code on edit and continue. that module brings in an ADO COM object using the #import directive.

    Writing a quick wrapper class to encapsulate the COM stuff and keep it trapped in its own module solved my problem.

    MSDN does not seem to explicitly state this in their documentation https://msdn.microsoft.com/en-us/library/0dbey757%28v=vs.110%29.aspx