The C# team posts answers to common questions and describes new language features
UPDATE 2014-05-20: We've received enough responses and the survey is now closed. Thanks everyone!
Hey C# developers!
Do you get tired of seeing this box (I know I do)?
Tell us about it!
The Visual Studio team would like your anonymous feedback on improving Edit and Continue (E&C) when developing .NET applications. This survey can take as little as 3 minutes to complete (I’ve saved you some time already by copying all the words on that page to this page so you don’t have to read it twice) and will guide ongoing support and making it work in more places. If you consider yourself a regular E&C user or would like to see improvements that let you use it more often – we need to hear from you!
Please take a few minutes to complete the survey @ http://aka.ms/encsurvey and if it’s not too much trouble tell all of your developer pals about it. Blog, wall, and tweet the link to anyone who’ll listen!
The information you provide is entirely voluntary. If you do not wish to provide us with any information, please disregard this survey. By filling out and returning this survey, you agree that we can use, disclose, reproduce, or otherwise distribute your feedback at the aggregated level. Your personal information will remain confidential. Please check http://privacy.microsoft.com/en-us/default.aspx for Microsoft Privacy Statements.
Anthony D. Green, Program Manager, Visual Basic & C# Languages Team
Edit and Continue is the one thing that is absolutely magical about the debugger, and I'd love it to get even more magical. It's a great selling point for using visual studio.
Filled out the survey, though I'm far more interested in writing lambdas in the watch window and having a better REPL than the immediate window during debug time. This would save literally hours of time stopping the debugger, adding manual debug statements, recompiling, relaunching.
Look no further than Visual Basic 6 - you could (in 1998)
1. Break on break-point.
2. Create a new function in your class.
3. Add a line that calls the new function.
4. "Set Next" to the new line that calls new function.
5. Step into the new function.
None of this works anymore.
Forgot to mention that - (still in VB 6) you could easily write and re-write whole sections of your code while in Debug. You could to step through your code to locate a bug, and once you find it - you just delete a couple of lines of offending code (variables and all), write bunch of new code, "Set Next" somewhere before the new code you just wrote - and run it. All from within the same debugging session, without recompiling or restarting.
So, yeah, you could start aiming for something like that.
izmir, çiçek, siparişi, için, http://www.izmirciglicicek.com
The difference is that VB6 was interpreted during the debugging process.
.NET is compiled and it makes things a lot more complicated.
Actually all of that still works (I just tried it). As xxxo mentions there are some differences in the compilation model for VB.NET which makes Edit & Continue more challenging to implement. In fact it requires special support in the CLR itself to make it doable. E&C support wasn't ready in time for the Visual Studio 2002 and 2003 releases but in 2005 the feature was restored.
You can perform steps 1-5 in Visual Studio today but there's a caveat about #2 I should mention. Right now we don't allow you to add non-private functions in Edit & Continue sessions (with the idea that if you add those methods overload resolution might have changed elsewhere in the universe) so you'll have to declare the new function as Private. We're debating whether this restriction is more annoying than helpful.
Anyway, since the initial release of E&C for VB in 2005 we've added many new language features which require a lot of infrastructure to work and so E&C doesn't work when you use those features, which is unfortunate. And that's what this survey is about.
izmir cicek siparisi icin http://goo.gl/uMFLNU