5

I have the annoying problem, that since I changed to my new development machine (Win 7, VS 2013), the edit and continue feature in a WPF application (.net 4.0) is not working anymore. If I try to edit some code file while debugging, I always get the message

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

but no error is shown in the "Error List".

To make matters even worse (speaking strictly of finding the cause of this issue) in some projects it's working fine. It's also not every WPF application that's affected with this issue...

After huge amounts of research and trial and error I found that when I replace the GeneratedInternalTypeHelper.g.i.cs in the obj directory with an empty one, everything seems to work just fine. But I'm not quite sure, if that's such a great idea to meddle with these files.

Has anyone an inkling what GeneratedInternalTypeHelper.g.i.cs does and what it's used for? Or any ideas on why edit and continue is not working properly?

iber
  • 51
  • 1
  • 4
  • It is code that's auto-generated from your XAML. Yeah, don't ever mess with it. If it would work then that would be bad, having the code mismatch your declarations. You didn't describe your scenario well, but E+C just doesn't work in all possible cases. And it certainly cannot modify your xaml on the fly. – Hans Passant Dec 03 '13 at 14:24
  • It's generated, that's true, but I can't see that it's based on my XAML, since they have always the same content... I'm aware of the limitation that I can not edit XAML files. Any suggestion, how I could better describe my scenario? What have I left out? – iber Dec 03 '13 at 15:17

1 Answers1

2

As stated above, these files are auto-generated. When the problem is in an auto-generated file it's because something has confused the compiler somehow.

I've encountered situations where one of the *.g.i.cs files is the source of a compilation error. In my case, the issue had to do with the *.g.i.cs files referencing a library that was no longer correct (e.g. after upgrading to a new version of the library, even when the project references are correct and the 'use specific version' flag is true). In my case, the only way that I've found to resolve the issue is to remove the reference to the old assembly, attempt to recompile the solution (it won't build, but it'll help the compiler to realize that it needs to revise it's reference to the assembly), then re-add the correct project reference and recompile the solution. There may be a better way of doing this (neither running a 'Clean solution' nor manually purging the contents of the build folders has worked for me).

You mentioned that you're only having this problem with some of your projects. Try to figure out what the broken ones (or alternatively, the working ones) have in common. If you're encountering the same problem that I did, then I suspect that you have references to one or more libraries that have changed, and the compiler hasn't revised it's view of the landscape to correctly account for the change.

shooley
  • 189
  • 5