Multiple versions of the .NET Framework can run on a single computer at the same time. This means that you are able to specify which version of the Common Runtime Language you’d like to use on an application level. The tool that helps you in this is called aspnet_regiis.exe.
When you install a more recent version of the .NET Framework on a computer, all of the ASP.NET applications installed will be configured to use the newer version, by default. You can then use the above mentioned aspnet_regiis.exe for changing this behavior.
When multiple versions are installed in your computer, each version has its own ASP.NET ISAPI extension (Aspnet_isapi.dll). With the aspnet_regiis.exe tool, you are able to define which version of the DLL you’d like to use on an application level, in IIS. The IIS Registration tool then sets your application’s script map to the appropriate DLL.
A script map is built from three elements: a file extension, an HTTP verb, and the version of the ASP.NET ISAPI extension, with which they’ll be associated. You can set the script mappings in an application (or application-pool) level basis, in IIS.
First I’d like to introduce a new feature: I’ll provide the relevant MSDN links for each topic reviewed here at the end of each post, so you will be able to read more material. I’ll update the older posts constantly, so all links will be available I suppose in a week.
When we build an application, we spend a considerable amount of time with debugging, removing the flaws, logical errors, etc. to create something that seems perfect. Then we deploy our app on other machines as well, and start the whole debugging process over again. There are many errors or exception that won’t occur on our development machines, because we configured it well (or just forgot one or two assemblies to include). For solving these errors, we can use remote debugging.
The process is simple. First, we need to set up the remote computer to let us debug it from our local computer. Then, we need to attach to the process we want to debug, and lastly, we should debug. Let’s examine these steps:
Health Monitoring, just like tracing, lets you review of a running applications state, stability, performance. It can be used for a number of reasons, such as:
- Getting notified of errors
- Catching errors
- Performance analyze
- Inspecting the payload of an application.
The Basic Structure of Health Monitoring
To enable health monitoring, head for the web.config, and search for the system.web section. The markup is the following:
<healthMonitoring Enabled=”true||false” heartBeatInterval=”seconds”>
Debugging an ASP.NET AJAX application presents its own issues. It is not the classic debugging process, because here, our code is hosted within a browser (in other words, the code is interpreted by another process). So first, we must configure our browser to enable script debugging. This is not a big thing to accomplish, just open Internet Explorer, select tools, Internet Options, and then the Advanced tab. There, you should seek for a checkbox names Disable Script Debugging (Internet Explorer). Clear it, and script debugging is enabled. Clear the other one with the same name and you can debug client script in other browser, too.
There is a little problem yet. You will notice it when you start browsing whatever site you would like. A pop-up window will constantly shows up, and informs you about the found script errors on a given page. This behavior cannot be turned off, so you should only enable script debugging, when you are debugging, otherwise you can debug the whole Internet.
Attach to script
Attaching to a running script is easy. Just use Visual Studio’s (note that Express editions cannot attach to processes) Attach to Process, and select the script you’d like to attach to. You can narrow the available processes considerably if you look only for Script processes (in the Category column).
With tracing, you can access data from a running application, with the help of a browser. In ASP.NET, you can access to the following information:
- The details of the request
- Trace information: performance information of the Web page’s life cycle events
- Control tree: size information about controls.
- Session state: displays session variables and values
- Application state: displays application variables and their values
- Request cookie collection: list of cookies passed to the server as part of the request
- Response cookie collections: list of cookies passed to the browser as part of the response
- Headers collection: the list of HTTP headers sent with the request
- Form collection: postback values.
- QueryString collection: the variables of the query string.
- Server variables: all server variables.
To debug an ASP.NET application, first you need to configure debugging. This is a process requires two steps to be taken. First, you must activate the ASP.NET debugger for your current project. To do this, right click on the project in solution explorer, and select Property Pages. In the dialog box, then select Start Options. Look for the Debuggers section in the bottom, and make sure ASP.NET is checked.
The second step is to enable debugging either for your whole application, or just different pages of it. To do so, in the compilation section of the web.config file, set debug=”true”. This causes debugging symbols to be added to your whole page. If you want to debug only some pages, you should set Debug=”true” in the @Page directive of them.
If you have the necessary rights for debugging (the application is running locally under your own user entity, or you’re an administrator) you can debug by now. If it is not the case, you should seek a way to grant yourself these rights. It’s because debugging an application needs more rights than just running it. Debugging can be harmful if not implemented carefully.
If you need to perform remote debugging then check back later, I’ll post how to do it very soon.
When you want to debug a deployed application (which is currently in production usage) you need to attach to the (possibly) remote ASP.NET worker process, and then use Visual Studio to debug it. Note that when you set a breakpoint in the application, any production user will be halted there, so be careful when using one.
When you published your web application to a production server, it is suggested that you set compilation debug to false, because it may slow down your application.