We have made the decision in Whidbey not to explicitly support ASP debugging anymore. This is because we expect more and more customers to swithch to ASP.NET. However, actual support is not totally cut, it's just not that obvious. In order to be able to debug ASP sever side script you have to:
1. Enable script debugging for you app's virtual directory in IIS manager (In the Property dialog for your v-dir, go to the Directory tab, click on Configuration, go to the Debugging tab and check both debugging flags the reset IIS to apply the change)
2. Then load your ASP page in IE and attach the Whidbey debugger to the ASP worker process (dllhost.exe in IIS4 and 5 and w3wp.exe in IIS6) selecting Script as the type.
3. Now you can debug your ASP sript as before (you might have to open the page from the Debug | Windows | Script documents window).
This being said, if for some reason ASP debugging doesn't work or you find some bugs related to it, it's because we don't explicitly support it anymore hence we didn't focus on making sure that this is at a high quality level.
What sort of problems are you seeing I can't seem to get it to work either. I get messages saying that the server (I'm developing on the server) is not configured to support debugging, with a suggestion to see some non-existent topics on configuring ASP.NET and ATL debugging in the documentation, and messages saying that the "current trust level does not support the 'debug' attribute." I've played a little bit with the groups and permissions based on what I could find, placing the ASPNET user as well as the logged in user into and out of administrative, debug user groups etc. but it doesn't make any difference.
Thanks for the info. I am using the "Visual Web Developer 2005 Express" flavor of VS2005. It doesn't look like the "attach to process" feature is present. Is that correct
If so, is there another way to enable legacy ASP debugging I realize that this goes against the intent behind this tool, but the fact of the matter is that while I'm taking on more and more .NET projects, I'll be stuck w/ legacy ASP maintenence for quite some time and it'd be nice to use one tool to does both. I imagine that I'm not alone.
I am amazed that this has been taken out. I have been searching through the documentation to find out how to debug the asp code. Even with the process attached, how do you set the break points on the asp code. Although our new apps are in .net there are still numerous older apps of ours and customers that require asp debugging and we would like our developers to be on a standard platform rather then jumping between VS2003 and VS2005.
I agree it is appalling there is no support for legacy ASP in Visual Studio 2005.
I have bought the release version and I am currently converting our application. Unfortunately much of the ASP code has been inherited, uses very dodgy techniques to submit the form data and is virtually impossible to maintain without access to an online debugger. It was my hope to support it using Visual Studio 2005 while migrating our code to .NET.
I have tried to attach to the w3wp.exe process; I can see the running scripts in the debug script explorer but cannot get them to break into the debugger.
I would appreciate help if anybody has actually achieved hitting a breakpoint in ASP code. Otherwise I will have to ask Microsoft for a refund!< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
It seems to me that Microsoft have been very focused on making the transition to .net as smooth as possible.
But taking out a functionality like this goes a very long way in the opposite direction. The transition will take years extra, because every developer supporting classic .asp code will have to stick to the 2003 version of visual studio.
Someone has made a big mistake here, and the only sensible thing to do, is make an update that enable debugging classic .asp code, and get it out as soon as possible.
We have lots of legacy code that must be debugged from time to time. With the new VS2005 (release version) I have no easy possibility to do this. Somehow I cannot even attach a process anymore (I could with the Beta 2) I followed all steps, but cannot break and step into my code anymore.
No, she meant IE. Can you clarify what you mean by 'refuse to debug them'. Do you see your ASP documents in the Script Explorer window
As for the many requests to bring back auto-attach support for ASP debugging, what are people looking for:
Debug classic ASP code locally
Debug ASP code + .NET code (either a .NET COM object or ASP.NET code in the same process)
Debug class ASP code on a remote computer
Case #2 and #3 are pretty hard to solve. On the other hand, Monica's work around should enable #1. Of course manually attaching to a process takes more time and thought than just hitting F5. One solution to this might be to use a macro like this one:
Sub ClassicASPAttach()
Try
Dim os As System.Version = System.Environment.OSVersion.Version
Dim IISProcess AsString = "w3wp.exe"
If os.Major = 5 And os.Minor <= 2 Then
IISProcess = "dllhost.exe"
EndIf
Dim process As EnvDTE80.Process2
ForEach process In DTE.Debugger.LocalProcesses
Dim processName AsString = process.Name.ToLowerInvariant()
If System.IO.Path.GetFileName(processName) = IISProcess Then
process.Attach2("Script")
EndIf
Next
Catch ex As System.Exception
MsgBox(ex.Message)
EndTry
EndSub
You can assign a macro to a key so that it is almost as easy as hitting F5.
I couldn't agree more. They have seriously shot themselves in the foot. It's absolutely senseless taking something out that was working perfectly well.
VS2003 has an option in Project Properties to specifically enable debugging for "ASP". VS2005 no longer seems to have this option; it only has the ASP.NET option.
They can't surely, seriously, have removed debugging support for ASP
Can anybody please explain to me what this Monica's step means. I didn't understand it
"2. Then load your ASP page in IE and attach the Whidbey debugger to the ASP worker process (dllhost.exe in IIS4 and 5 and w3wp.exe in IIS6) selecting Script as the type."
Does she mean IDE instead of IE I tried to include asp pages in the project but VS2005 refuses to debug them. Thanks .
Monica, thanks, but you've got to be kidding me. Do you realise how much extra time those steps would add to the development/test/debug cycle.
How can you possibly expect people to migrate to .Net so quickly. Our application has 1m lines of C++ source and 1,500 ASP page, and thousands of customers - many who refuse to install the .Net framework, including many Fortune 100 companies.
Do you seriously expect me to migrate this code base overnight
Can't debug ASP in VS2005
jfc kvdfhkgjvfhdsgjgchkfghjngfjk
We have made the decision in Whidbey not to explicitly support ASP debugging anymore. This is because we expect more and more customers to swithch to ASP.NET. However, actual support is not totally cut, it's just not that obvious. In order to be able to debug ASP sever side script you have to:
1. Enable script debugging for you app's virtual directory in IIS manager (In the Property dialog for your v-dir, go to the Directory tab, click on Configuration, go to the Debugging tab and check both debugging flags the reset IIS to apply the change)
2. Then load your ASP page in IE and attach the Whidbey debugger to the ASP worker process (dllhost.exe in IIS4 and 5 and w3wp.exe in IIS6) selecting Script as the type.
3. Now you can debug your ASP sript as before (you might have to open the page from the Debug | Windows | Script documents window).
This being said, if for some reason ASP debugging doesn't work or you find some bugs related to it, it's because we don't explicitly support it anymore hence we didn't focus on making sure that this is at a high quality level.
Hope this helps,
Monica
MAG
ddk
*itguy*
Thanks for the info. I am using the "Visual Web Developer 2005 Express" flavor of VS2005. It doesn't look like the "attach to process" feature is present. Is that correct
If so, is there another way to enable legacy ASP debugging I realize that this goes against the intent behind this tool, but the fact of the matter is that while I'm taking on more and more .NET projects, I'll be stuck w/ legacy ASP maintenence for quite some time and it'd be nice to use one tool to does both. I imagine that I'm not alone.
Kushi
George Earl
I agree it is appalling there is no support for legacy ASP in Visual Studio 2005.
I have bought the release version and I am currently converting our application. Unfortunately much of the ASP code has been inherited, uses very dodgy techniques to submit the form data and is virtually impossible to maintain without access to an online debugger. It was my hope to support it using Visual Studio 2005 while migrating our code to .NET.
I have tried to attach to the w3wp.exe process; I can see the running scripts in the debug script explorer but cannot get them to break into the debugger.
I would appreciate help if anybody has actually achieved hitting a breakpoint in ASP code. Otherwise I will have to ask Microsoft for a refund!< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Thanks
KrisSahoo
Adelaid
It seems to me that Microsoft have been very focused on making the transition to .net as smooth as possible.
But taking out a functionality like this goes a very long way in the opposite direction. The transition will take years extra, because every developer supporting classic .asp code will have to stick to the 2003 version of visual studio.
Someone has made a big mistake here, and the only sensible thing to do, is make an update that enable debugging classic .asp code, and get it out as soon as possible.
Nobbi
With the new VS2005 (release version) I have no easy possibility to do this.
Somehow I cannot even attach a process anymore (I could with the Beta 2)
I followed all steps, but cannot break and step into my code anymore.
Anyone
Rikard
See this:
http://forums.asp.net/906347/ShowPost.aspx
Seems they plan to fix it. I sure hope they do, it would be a serious limitation if it continues to be missing.
Bill van Melle
No, she meant IE. Can you clarify what you mean by 'refuse to debug them'. Do you see your ASP documents in the Script Explorer window
As for the many requests to bring back auto-attach support for ASP debugging, what are people looking for:
Case #2 and #3 are pretty hard to solve. On the other hand, Monica's work around should enable #1. Of course manually attaching to a process takes more time and thought than just hitting F5. One solution to this might be to use a macro like this one:
Sub ClassicASPAttach()
Try
Dim os As System.Version = System.Environment.OSVersion.Version
Dim IISProcess As String = "w3wp.exe"
If os.Major = 5 And os.Minor <= 2 Then
IISProcess = "dllhost.exe"
End If
Dim process As EnvDTE80.Process2
For Each process In DTE.Debugger.LocalProcesses
Dim processName As String = process.Name.ToLowerInvariant()
If System.IO.Path.GetFileName(processName) = IISProcess Then
process.Attach2("Script")
End If
Next
Catch ex As System.Exception
MsgBox(ex.Message)
End Try
End Sub
You can assign a macro to a key so that it is almost as easy as hitting F5.
I hope this helps.
Dajyno
sdbetatester
They can't surely, seriously, have removed debugging support for ASP
Rosie S.
Can anybody please explain to me what this Monica's step means. I didn't understand it
"2. Then load your ASP page in IE and attach the Whidbey debugger to the ASP worker process (dllhost.exe in IIS4 and 5 and w3wp.exe in IIS6) selecting Script as the type."
Does she mean IDE instead of IE I tried to include asp pages in the project but VS2005 refuses to debug them. Thanks
.
BabyGBear
Monica, thanks, but you've got to be kidding me. Do you realise how much extra time those steps would add to the development/test/debug cycle.
How can you possibly expect people to migrate to .Net so quickly. Our application has 1m lines of C++ source and 1,500 ASP page, and thousands of customers - many who refuse to install the .Net framework, including many Fortune 100 companies.
Do you seriously expect me to migrate this code base overnight
Jeremy