In one of my previous blog post, Identifying Worker Process (w3wp.exe) – IIS 6.0 and IIS 7.0 for Debugging ASP.NET Application – I have explained about how we can identify the list of currently running worker process using command prompt while we need to attach process from visual studio . But do you know for IIS 7.0 and IIS 7.5 we can get the worker process (w3wp.exe) details like Application Pool name, Process ID, CPU Usages from IIS Manager itself. Even you can get details of each worker process for a “Web Garden” scenarios. So when you need to attach some process for debugging from Visual studio, Instead of going to command prompt, you can easily identify the worker process Id from IIS itself.
Watch windows is one of most commonly used debugging tool with Visual Studio. We generally used to explore the objects, values, properties and other nested objects as a tree structure. Most of the time we used watch window to only view the values or change the current object properties values to see the effects of changed object during debugging. But we can use watch windows for many different purposes. In this blog post I am going to show 10 Tips, that may help you while dealing with Watch Window.
In Mastering in Visual Studio 2010 Debugging article I have discussed about the basic of Object ID creation while debugging. I received some request from some readers to explain the use of “Make Object ID” in details. In this blog post I am going explain how we can track an Object which is already out of scope using by creating a Object ID while debugging.
By using “Make Object ID” option we are informing Visual Studio Debugger to keep track of that object no matter it’s within scope or out of scope for the current context. We can create “Object ID” either from Locals, Autos or from Watch Windows. Object ID is a integer number followed by a pound (#) sign. When we create Object ID for an particular object, Visual Studio Debugger ( CLR Debugging Services ) use an integer value to uniquely identify the object. This “Object ID” allows you to get the object details even if it is out of scope.
In this blog post I am going to explain how you can customize the complete view of the debugging window during debugging of application. By complete view means, where you can add own Properties, can customize the result, manipulate the data, hide properties which may not need during debugging etc. In one of my previous blog post, I have explained how we can customize the view of the debugging windows using DebuggerBrowseable and DebuggerDisplay attributes over Few Tips on Customizing Debugging Window View in Visual Studio . But, both these two attributes are limited to customize the view for a specific class and they can only show you the information for the particular class members . In this blog post you will see how we can create new view for some existing debugging view using “DebuggerTypeProxy” attributes. From the below snaps you can understand what kind of customization we can do inside a debugging window.
I have just encountered one issue while start the debugging one of my Silverlight 4 application. Silverlight 4.0 with VS 2010 was working fine few weeks back, but today when I started debugging to test one of my application, I got the error message as below.
I thought, It may be the problem with the Silverlight version which is selected for this project. I checked the Silvelight “Target Silverlight Version” from the Project Properties. But the Silvelight version was correct.
Published Date : September 12, 2010
Published Date : September 14, 2010
Published Date : September 22, 2010
Published Date : September 24, 2010
Published Date : September 19, 2010
Published Date : September 7, 2010
If you want to check all previous Weekly Archives, Please read https://abhijitjana.net/blogbox/ Section.
In my few previous blog post I have explained how we can customize the Debugging windows view during debugging of application using “DebuggerBrowseable “ attributes and “DebuggerDisplay” , then I have also explained use of “DubuggerHidden” attribute which tells the Visual Studio debugger that the method is hidden from the debugging process and while debugging. In this blog post I am going to explain one similar features of “DebuggerHidden” attributes, named “DebuggerStepThrough”
Marking a piece of code using DebuggerStepThrough attribute tells the Visual Studio debugger that, the code block will be stepped over from debugging process. you can mark methods, properties with DebuggerStepThrough attributes where you don’t want to stop your code to break.
If there is any break point inside a code section which is marked as “DebuggerStepThrough” attributes, that code block will be marked as “[External code]” in stack Trace. Where as “Debugger hidden” attributes didn’t marked is External code.
DubuggerHidden attribute tells the Visual Studio debugger that the method is hidden from the debugging process and while debugging. This is quite helpful when you don’t want to go to stepping inside of a method while debugging.
When you mark a method with DebuggerHidden() attributes, It’s explicitly tells the debugger not to step inside of that methods and no break point will be hit over that method. Now I am going to explain the same using a Example with Intellitrace debugging.
In this blog post I have going to list out all of my IIS articles that I have published over last few years. Why I am going to do such post ? Because, I have been asked many question on IIS and different debugging options related with IIS and ASP.NET Applications by many readers. Many times I have had given reference of my different articles. This post will be the single reference for all of those articles. In this blog post I have given link and small overview of all of my IIS articles, so that I can refer a single articles to who ever wants to learn about IIS.
This article describes details of IIS configuration, Virtual Directory creation, Application Pool Creation, Application Pool settings, IIS Request processing for ASP.NET .
In this post I am going to discuss about few tips on customizing debugging debugging windows. This may be very helpful during debugging of application. While debugging, you may want to simplify debug window or you may want to clean up all the unnecessary fields that are not important during debugging from debugging windows. Here is few tips for customization of debug window.
To use above attributes you have to use System.Diagnostics namesapce
If you are debugging a ASP.NET web application which is hosted on IIS, you need to attach the particular worker process in Visual Studio to start debugging. To Attach a process we can go to Tools > Attach Process or use shortcut key Ctrl +P. The process window will show the worker process (w3wp.exe) which is currently running on IIS. You need to select the process and click on attach button to start the debugging.
Problem starts when you have multiple worker process running on IIS. If you have multiple sites hosted on IIS and each site having their own application pool then you will see the list of all worker process in the Process Attach window.
Here you need to identify the particular worker process which is associated with your application pool.
Note: Whenever we create a new Application Pool, the ID of the Application Pool is being generated and it’s registered with the HTTP.SYS (Kernel Level of IIS) . So whenever HTTP.SYS Received the request from any web application, it checks for the Application Pool and based on the application pool it send the request
Recently I have published one complete tutorial on Visual Studio 2010 Debugging. Which covered almost all main features of debugging in Visual Studio 2010 like Basic of Breakpoints, breakpoint labeling, data tips, multithreaded debugging, and parallel debugging and IntelliTrace debugging. You can read the complete article from My Blog or from CodeProject.
While preparing the article I had created one small video on IntelliTrace Debugging which will show you the demo of using IntelliTrace Debugging. Hope you will enjoy this video.
Visual Studio IDE gives us a lot of tools to debug our application. Sometimes debugging activity takes a very long time to identify the root cause. But VS IDE provides a lot of handy tools which help to debug code in a better way. Debugger features include error listing, adding breakpoints, visualize the program flow, control the flow of execution, data tips, watch variables and many more. Many of them are very common for many developers and many are not. In this article, I have discussed all the important features of VS IDE for debugging like Breakpoint, labeling and saving breakpoints, putting conditions and filter on breakpoints, DataTips, Watch windows, Multithreaded debugging, Thread window, overview of parallel debugging and overview of IntelliTrace Debugging