May include but is not limited to: animation, data binding, dependency properties
Since .NET 3.5, we get a nice and neat class, PresentationTraceSources to debug some kinds of WPF-specific things, like animation, data binding and dependency properties. To make it work, first you’ll need to set a reference to the CLR namespace System.Diagnostics in your XAML code. This is how could it be done:
<Window xmlns:diag=”clr-namespace:System.Diagnostics;assembly=WindowBase” />
Then with the new XML schema prefix diag, you can use PresentationTraceSources to emit error information. You should use the attached property TraceLevel, which is an enumeration, with the following members:
- None: no additional information will be emitted.
- Low: traces some additional information.
- Medium: traces a medium amount of additional information.
- High: traces all additional information.
All hail MSDN, the best resource available. I liked the explanation very much, and copied it here, so you’ll all know that TraceLevel.Medium produces medium amount of additional information. What a shame that we won’t know what counts to be additional, and what is just basic info.
Anyway, the attached property can be set on the following classes: BindingBase and its derivatives, BindingExpressionBase and the derived types, Object- and XmlDataProvider. Oh, and an example on how to use this property:
<Binding Path=”myProperty” diag:PresentationTraceSources.TraceLevel=”Low” />
Debugging and tracing are both enables you to log information about your application’s health, current status, etc. The main difference is that debugging is only allowed (it runs only) in debug mode. You can define a debug mode by adding the #define DEBUG command at the top of your code (or compiling your code with the /d:DEBUG flag.
We’ll cover the following classes and attributes in this post:
- Debugger Attributes
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:
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.