I understood that Edit and Continue would not be implemented in VS 2005 for ASP.NET.  However, I was under the impression that 'Edit and Refresh' or 'Refresh and Continue' would be available -- this describes when you make an edit in the code and refresh just the page and the code is recompiled without stopping the project. 

Beta 2 seems to have neither - the code behind seems to be locked from editing while debugging.  Am I missing a setting, or has ‘Edit and Refresh’ been removed? 

I hope it has not been removed as I have been looking forward to the return of that feature ever since we lost it in moving from VB6 and classic ASP.

We have been working through these scenarios, and some of the code is still locked when it shouldn't be. Essentially the model we want to enable is to be able to edit pages when in run mode. Editing pages in break mode gets more iffy as the code you would be stepping through would not map to what is actually being executed.

Sam

Thanks for reply. In my opinion, the single feature most important to me for VS 2005 is the ability to edit code behind while debugging (break mode).  Editing in run mode would be a new thing, but if I don't have to stop and start, it would be just fine. Editing in break mode is what I am used to, so it would take quite a while to break a habit of 10 years if I was unable to edit in break mode.

VS 2003 lets you edit in break mode, but ignores your code behind changes until you restart. (And an excruciating restart it is at over 60 seconds - that's my main problem with VS 2003).  I am comfortable with the current way debug edits are handled in VS 2003 -- I realize the yellow line and breakpoints will be inaccurate, but the ability to watch live variables while I am making code fixes is very helpful.

I am impressed with the much improved intellesense in the code in the aspx files.

I was able to edit the aspx server script blocks while in break mode, but intellisense did not work at that time, and it did not recompile on the fly.

Another question – is the plan to have session and application variables be able to survive a debug code change?

Actually VS 2003 does not allow you to edit markup neither in run no in break mode. It also does not allow you to switch to Design view while debugging. VS 2005 allows markup editing and Design view access (albeit we make DV read-only).

You do can edit code while application is running. The only case when code remains locked is when VS is sitting on a breakpoint.

In my experience, I am able to edit the .aspx files in run and break mode in VS 2003 (HTML, not Design) almost all the time.  (Rarely it will lock them for some unknown reason.)

Actually, this behavior comes in very handy as I can edit JavaScript and HTML and see my changes by just refreshing the page.  I find this extremely useful and productive, and wish the code behind would behave in the same manner.  Is this not the way it is supposed to be in VS 2003?

In VS 2003 I cannot edit the code behind (aspx.vb or aspx.cs), unless I break.  Of course, all edits are not compiled until a restart. 

To clarify -- I would like to see from VS 2005 the ability to edit the code behind and code in dll's and have it compiled when the page is refreshed – no restart required.  This is the same behavior we had in classic ASP - just change the code and refresh the page.  It would also be nice if session and application state survived a code change, and that the recompile occurs very quickly.  In beta 2, the code behind is locked when in run and break mode.

I personally don’t really care about the HTML designer’s behavior during debugging, leaving that locked or inaccessible is understandable. 

I am so vocal about this because the long restart time in VS 2003 has put a damper on my productivity.  I want to get back to full speed. 

Thanks for listening.

Hi Chris,

You should actually have the behavior you are looking for in Beta2 today.  To try it out:

1) Create a page with an event handler

2) Set breakpoint in the event handler

3) Run with debugging

4) Hit the breakpoint

5) Hit continue to complete executing the page

6) With debugger still attached (but breakpoint not currently hit), make a code modification

7) Hit refresh in the browser or push another button to cause a postback

8) Your breakpoint will hit -- now with the new code change taking affect.  No need to stop and restart the debugger.

Hope this helps.  Let us know if for some reason this isn't working.

Thanks,

Scott

Thanks Scott, I tried it and this is what I found with beta 2, and a simple web project:

In run mode, I cannot edit VB code in the code behind (partial class) or code in a class I added to the the App_Code folder.  It just beeps when I type and the status bar says "Cannot currently modify this text in the editor.  It is read-only."

I can edit inline code in the .aspx files, (and .js files), save, and refresh and it works.  I can currently do the same thing in VS2003, but in break mode.  (Side note: VB Intellesense doesn't work in run mode in the .aspx in 2005.)

In break mode in beta 2, I cannot edit anything.  That seems to be the opposite of the way it works in VS2003.

I hope that edit and refresh isn't just for .aspx file code, becasue we do all our coding in the code behind/beside.

This is being fixed for RTM. The editor for VB code was locking the file for editing when it didn't need to.

Sam

That's great news.  Thanks.

Think it might be fixed in the next public build (before rtm)?

Anyone know if the locked down editor was fixed in the lastest PDC?