I think I figured this out by myself, so I thought I should post and share in case it might help somebody else one day.
I discovered that if I simply used VWD as an editor and save my changes and then go pull up the pages in a web browser without trying to debug or "start without debug" from the IDE then the extra build done prior to a debug was not attempted, thus did not fail,
and the page loaded and worked normally from outside of VWD.
Then I found an option to turn off the build prior to debug in VWD, so now it all works like it should by skipping that final build.
Here is my theory on why this is so. I believe that once the page has been displayed in a browser, the assembly's .dll file has been loaded into memory by IIS and is thus marked as in use and only IIS can unloaded it and recompile and load a fresh copy. If
VWD does a build for a debug run that tries to replace the dll it cannot do so, and is working with an older version in memory vs newer modified source code. That explains why I could build from the build menu in VWD successfully, but the build done in prep
for a debug was not successful because that build tried to replace a dll file in use by IIS. Just changing the source file and letting IIS discover the change and recompile dynamically caused IIS to unload and reload the dll, which is the only way it could
work once IIS had originally loaded it. So this problem may not occur when using the web server that comes with VWD, and it definitely does not occur if you turn of the build.
Moral of the story: If you are testing in IIS, you should go to the website menu in VWD, click start options, click "build" on the tree in the left pane, and on the dropdown list labelled "Before running startup page" select "No Build". Works for me.
Tepi
Member
30 Points
4 Posts
Re: The name xxx Does Not Exist in the Current Context
Jul 21, 2006 11:16 PM|LINK
I discovered that if I simply used VWD as an editor and save my changes and then go pull up the pages in a web browser without trying to debug or "start without debug" from the IDE then the extra build done prior to a debug was not attempted, thus did not fail, and the page loaded and worked normally from outside of VWD.
Then I found an option to turn off the build prior to debug in VWD, so now it all works like it should by skipping that final build.
Here is my theory on why this is so. I believe that once the page has been displayed in a browser, the assembly's .dll file has been loaded into memory by IIS and is thus marked as in use and only IIS can unloaded it and recompile and load a fresh copy. If VWD does a build for a debug run that tries to replace the dll it cannot do so, and is working with an older version in memory vs newer modified source code. That explains why I could build from the build menu in VWD successfully, but the build done in prep for a debug was not successful because that build tried to replace a dll file in use by IIS. Just changing the source file and letting IIS discover the change and recompile dynamically caused IIS to unload and reload the dll, which is the only way it could work once IIS had originally loaded it. So this problem may not occur when using the web server that comes with VWD, and it definitely does not occur if you turn of the build.
Moral of the story: If you are testing in IIS, you should go to the website menu in VWD, click start options, click "build" on the tree in the left pane, and on the dropdown list labelled "Before running startup page" select "No Build". Works for me.
Keith