Wednesday, September 28, 2005
For those of you who are willing to learn more about C# generics in .NET 2.0, this article is a very nice introduction to this topic. It is written by Juval Lowy of IDesign (http://www.idesign.net). This website is definitly worth a visit.
John Gossman is blogging about "Sparkle", the Expression Interactive Designer. His blog can be found here. This is a fully managed application written in .NET and uses the Windows Presentation Foundation (Avalon) for it's user experience. You can see a very impressive demo at the Microsoft website. I can't wait to use the Windows Presentation Foundation in my own applications.
Monday, September 12, 2005
I've read this excellent introduction to the first beta of the Windows Communication Foundation (Indigo) last weekend. It's written by David Chappell. He provides an excellent situation of this new technology and he also describes some neat features of the new System.Transaction namespace in .NET 2.0. http://www.davidchappell.com/IntroducingIndigo_v2.pdf Recommended reading!
Saturday, September 03, 2005
In Visual Studio 2005, you now have the ability to use the pdb-only debug information option. This underestimated debug option is available for the command- line C# compiler, but could not be configured through Visual Studio 2002/2003 (only enable/disable debug information). This is finally possible with Visual Studio 2005 by clicking the Advanced button on the Build page of the project properties. There you have the option Debug info. What is the use of this extra feature? First of all, let's get through some background information. When having a project in Visual Studio, you can perform a debug build (default) that is used throughout the development stage or you can use a release build. This release build outputs the binaries that are used in the production environment. Now I always considered using debug information in release builds as a best practice. You can remotely debug your software in production when a problem occurs or when a bug has been noticed. It's a tricky business with the optimize switch turned on, but it's still better than nothing. A small performance penalty is imposed when doing this but in most of the cases this is an acceptable offer. When debug information is turned on, a .pdb file is automatically generated containing the necessary debug information. This .pdb file maps the IL code that is generated by the compiler to the original source code. But the Visual Studio debugger needs more information in order to debug your application. The mapping described above is only half the work. The JIT compiler, which translates IL code into native machine code, needs to create a mapping between the generated machine code and the IL code. This is accomplished by decorating the assembly with the Debuggable attribute, whose IsJITTrackingEnabled property needs to be enabled. When the JIT compiler loads the assembly it looks for this attribute. When this IsJITTrackingEnabled property is enabled, a slight performance penalty is imposed. In most cases this is not an issue because the JIT code is compiled only once into native machine code. Once a method has been JIT compiled, no additional costs are associated. So far, so good. There are some situations though, where these additional costs are not allowed when your application is running in the production environment unless your application is experiencing a problem. Here is where the pdb-only debug information option comes in. A .pdb file will be generated as usual, BUT the IsJITTrackingEnabled property will NOT be enabled. The application will run without the generated tracking information by the JIT compiler. No performance penalty is implied. When you want to debug your application, you can enable the IsJITTrackingEnabled property in two ways: - Creating an ini-file with the same name as the assembly you want to debug: f.e. MyApp.exe -> MyApp.ini [.NET Framework Debugging Control] GenerateTrackingInfo=1 AllowOptimize=0 - Using the debugger (opening an existing project of type executable(.exe) and selecting the executable you want to debug). With this option, everybody wins. The application runs without the extra penalties of debug information and when necessary the application can be debugged. Only one exception to this is with applications that are being executed in a seperate worker process like ASP.NET (aspnet_wp.exe). I know for sure that all this wasn't possible with versions 1.0/1.1 of the ASP.NET runtime, but I don't know if version 2.0 of the ASP.NET runtime provide a means of setting the debug options at run time. I'll have to find out. I will make a sequel to this post if I have some new information regarding this matter. Questions? Remarks? Please let me know. Greetz