Many times we came across in debugging legacy applications built on ASP and COM. Debugging of legacy applications are error prone and complex.
We have an application built on ASP and C#.Net 1.1. User Interface defined using ASP and the business logic is in C#.Net. C#.Net project build to a COM component using the NAnt Build (http://nant.sourceforge.net/) tool.
For incorporating new requirements we need to debug the C# project. We have faced many issues in debugging C# project hosted as COM component and used by the ASP pages. In this small article, we are discussing about the various debugging issues faced and how we resolved the same.
Technologies Involved
UI design: ASP
Business Logic: C#.Net
Deployment: COM using NAnt Build tool
Problem
Unable to debug the C#.Net project hosted as COM component in Visual Studio 2003.
Issue 1: Unable to attach to the process
For debugging the COM component used by the ASP pages, we used the dllhost.exe. We have attached the dllhost using the process attach and received the below error message.
Figure 1: Attach failure
Solution: Select Native along with Common Language Runtime under program types.
Default it CLR is selected under the program types. When we selected Native, for debugging the unmanaged code, dllhost got attached properly to the solution.
Issue 2: The breakpoint will not currently be hit. No executable code is currently loaded at this location.
Once after attaching the dllhost, start debugging the C# project and noted the ? mark appearing in every breakpoint with the specified error message.
Figure 2: Breakpoint not hit
Solution: Change Isolation Level to High
Stop debugging the project and open the IIS. Right click on the ASP site and select properties. Move to the Home Directory tab. Change the Application Protection to “High (Isolated)”
Figure 3: Application Protection to High (Isolated)
Browse the ASP page in IE and open C# project in Visual Studio 2003. In attach process window, we can see two dllhost executables.
Figure 4: Select proper dllhost
Select the one contains Title as Microsoft Active Server Pages with application name. Now in attach window, you can observe that the selected program types as Common Language Runtime and Script. For debugging ASP pages, we required the “Script” program type, not the Native.
Issue 3: Breakpoint is not hit.
Breakpoints are appearing properly, but it is not hit.
Solution: Clean temporary asp.net files
Clean the temporary asp.net files (C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\) and redeploy the C# project in debug mode.
Conclusion
For debugging ASP pages with C#.Net code behind, follow the steps
1. Clean .Net assembly cache
2. Redeploy the debug assemblies
3. Set the Application protection in IIS site properties to High (Isolated)
4. Attach to dllHost.exe with program types Script & CLR
5. Start Debug