"Edit and continue" -Allow changes in Library Project by Michael Freidgeim

Thank you for your suggestion. We'll assign it to the appropriate feature area and evaluate it for a future release. Because we're still early in the product cycle, you may not hear back from us for some time but we'll contact you if we have questions and will let you know the final status of your suggestion.

The Web Platform & Tools Team

Microsoft comments: Thankyou for the feedback.

The code in reefrenced projects is made read-only as EnC is not supported for dlls loaded into web projects. Its actually because of EnC, that editing is disabled. So as not to confuse users, editing is disabled at runtime if EnC is not possible. EnC is not possible in the web case becuase of issues of loading the changes into asp.net. Because the in-memory representation of the binary is different from the on-disk representation it causes issues.

Thank you for your explanation why EnC by design is so restrictive in the Visual Studio 2005. But I post a SUGGESTION for the future version of Visual Studio.
Even if VS is not able to re-compile library code in background, it still should allow to edit the source code, giving a warning that source and binary is not matched any more. VS has a special option for this "Require source files to exactly match the original version".
When EnC is not possible, EDITOR still should allow to EDIT with all warnings, that are appropriate.

By the way C# files in libraries are not locked and can be edited during debugging session, so the limitation is applicable to VB libraries only.
Also documentation (http://msdn2.microsoft.com/en-us/library/7932e88z(VS.80).aspx) doesn't describe the library changes as not supported by "Edit and Continue".
I've posted the procedure that I have to use at the moment -very inconvinient(http://geekswithblogs.net/mnf/archive/2006/01/09/65292.aspx).

You've resolved the suggession "By Design". But the suggestion was to change design, because the current design is NOT GOOD.

I agree. VB users should at least be able to edit the file to fix a problem right there. If EnC can't recompile those edits right then, obviously a warning should be generated. To force the VB developer to have to stop debugging right then to fix a minor problem is bad productivity.

To say this is by design is stupid and irresponsible. No way would the developers deliberately make the behaviour so significantly worse than 2003. Take the person that made this design decision and hit them with a blunt object.

theres all kinds of reasons you might make a change to code :

* add a method
* change a method
* fix a simple logic bug
* add a logging statement
* add a comment
* fix a spelling mistake

now lets say you're debugging and youre trying to fix a real problem (or whatever youre doign), but you come across a spelling mistake. well do you really care if it compiles right now. NO - of course not! but do you want to fix it now so you don't forget to do it later! of course you do! but this stupid behavior prevents me from doing it.

what this comes down to is that the developers of the IDE don't trust the user of the IDE to know what they're doing. this is the frustrating part. the developer should be smart enough to decide that they want to edit code even if it isnt compiled and EVEN IF the debugger gets confused when stepping through the code.

Just like it always did in 2003. cmon pleeeease trust us!

I find this a huge issue while developing, a tiny fix forces you to restart your application, and when your app covers 40 projects, its not a quick process. There is even the case where you start to edit, then undo everything, and then it tells you to edit or reset and you want neither option as nothing has changed!! You can't fix it, as you already have so again, your forced to restart.

An inaccurate message is a serious usability issue in any case. Saying less in this case causes lest frustration. Message should be "Changes in VB libraries are not allowed when the debugging. This is a technical limitation.".