Archive for the ‘Visual Studio’ Category

Here’s a list of links to the free tools in my current Development Environment (in no particular order):



Integration / Build


Metrics / Profiling


Analysis / Visualization

Use them, they’re good :)

This article will introduce the Conditional Attribute and give an example of its usage. The technical level is kept low to make the text as accessible as possible. More info can be found in the official C# Programming guide, in particular the section called ‘Conditional’.

When it comes to debugging, the world (of IDEs) is full of tools to make life easier for us as developers. The latest version of Visual Studio (2008) features a vast array of built in debugging aids that help diagnose and keep track of a running application/assembly. This is all well, and maybe what I am about to say next may sound a bit old or odd, but I for one would never do away with my trusty old output console. I have talked about this before in a post that gave a brief walk through on how to open console windows from an existing and running application in Windowed mode (that is sporting one of those fancy graphical interfaces that seem to be so in fashion lately ;) ).

I have written a small dll that I hook up to must of my projects, through which you can ‘report’ debugging messages to one of 5 pre-defined ‘channels’. The report can be set to write to:

1) The Visual Studio output console (default)
2) A regular text file (you set the path)
3) A console window
4) Email
5) Wreq (my own custom project management tool)

This little tool uses reflection to keep track of what the application is up to, but you can also tell it to ‘report’ any message you choose at any time.


“[Application Name]”,
“Creating and setting Auto Save path” +
“\nPath: ” + _path.ToString());




One thing about reporting debug info this way is that when you switch to a Release build you want all of those messages to go away automatically, so that you do not have to comment out all these calls.

One way of acheiving this would be to use the #if-endif construct such as:

“[Application Name]”,
“Creating and setting Auto Save path” +
“\nPath: ” + _path.ToString());

This pre-processor directive would tell the compiler to skip the encapsulated block of code. However, in a typical small application I usually end up with a lot (hundreds) of calls like this and decorating them all with #if-endif just isn’t a very elegant solution. Fortunately the designers of the CLR thought about this and gave us a much better way of dealing with this situation.

One thing you can easily discern from the above code is that all these calls access the same static method on the same static class. Thus, instead of decorating all the method calls, what if we could decorate the method itself?

In .net there is a concept called Attributes that allows you to add custom behaviour and ‘properties’ to methods. The framework contains a lot of pre-defined attributes that deal with for example security, compiler-options, discoverability and much more. Also, as a developer you can define your own attributes, but that is beyond the scope of today’s topic. (See the ‘.NET Framework Developer’s Guide’, in particular the section on ‘Writing Custom Attributes’.)

One such pre-defined attributes is the ‘Conditional’ attribute. This works pretty much like an inverse version of the #if-endif construct. it tells the compiler when to, for example execute a particular method.

Note: This is not a pre-processor directive in the form we know it from of a C/C++, in fact the .net framework as no such concept since the code is JITed upon execution. Thus the above statement that the compiler executes a piece of code is sort of correct, if by compiler to mean the CLR, and by executing you mean Just-In-Time compilation… The C# Programming Guide calls this a ‘preprocessing identifier’.
(See the ms-help page ms-help://MS.VSCC.v90/MS.MSDNQTR.v90.en/dv_csref/html/e1c4913b-74d0-421a-8a6d-c14b3f0e68fb.htm)

When using the Conditional attribute you define a constant condition that has to be met for any code-path that access the decorated mehod to be executed. Naturally this can help us in the debuggin scenario. One such constant that is defined automatically when building a Debug build in Visual Studio is the DEBUG constant. Thus we can do the following:

public static void Report(…)


Using this attribute is what invokes the magic. Now, if the DEBUG constant is not set, any method call to the Report method will simply be excluded from the build, keeping our Release build nice and neat and without cluttering the code with those #if-endif. In fact, the method itself wont event be present in the emitted MSIL :). That, is clean!

There are a few restrictions on using the Conditional Attribute. In particular, the method you want to decorate must have a return type of Void.

Note: This actually makes a lot of sense as the method will no longer be available and the compiler would have a hard time tracing all the possible usages of the eventual return value that might be expected by later code…

I still see a lot of (c#) code written that is full of #if-endif (almost exclusively to defer execution paths in/out of debugging), but I would highly recommend you start experimenting with using the Conditional Attribute instead (where applicable of course ;).

There are still some legitimate use for the #if-endif of course, for example when you want to skip a particular code-block within a method, or when the method you call has a return type other than Void. Thus you should not rely on the Conditional attribute to solve all of your conditional execution, but keep it around as a powerful and simple technique. Also, it might give you an excuse to learn more about the power of Attributes in .NET, and how to write your own custom Attributes.

There’s been some buzz around the web lately around ASP.NET MVC, particularly after Mix where it was a reoccurring topic amongst the more technically oriented visitors. I’ve kept an eye on it for some time, mostly because I like the MVC (Model-View-Controller) pattern a bunch, but I never took the time to actually download the extensions and play with it. For the past few weeks though I’ve been spending a lot of time in planes and airports, and what better way to kill some time than to code?

The MVC pattern may be old news, and I’m sure that most people with at least some application development experience have already used it at some point, though they may not have been aware of it. In software systems architecture we like to think of three distinct layers of abstraction that help us organize and manage code and functionality. Or at least we did until the number 3 started to feel old and was replaced by the much more sexy ‘n’ ;).

MVCThose three layers are Data, Logic and UI, though they may be called by different names depending on your platform/environment/religion. What MVC does is it focuses on the UI layer, or the presentation layer, and splits it further into one or more Controllers and Views.

Controllers are the handlers and responders to UI events such as user interaction. The Controller responds to a user action and then updates the Model to reflect this action. The Model is roughly equal to the Data layer in the 3 tier architecture described above, though there are some important differences. A model is a contextually skewed data layer in the sense that there may be several models representing the same data from various ‘viewpoints’. The Model is what gives contextual meaning to the data by ‘modelling’ it in accordance with the current domain of the application.

The View presents the Model to the user in accordance with its context, e.g. as a UI that is updated to reflect the state of the Model. The model has no knowledge of the View and the View cannot directly change the state of the Model.

This basic explanation of the MVC pattern should be obvious to most .NET developers who are used to mantras like “Applications = Code + Markup” and keywords like code-behind. The MVC pattern is more or less implemented in any pattern/architecture that says ‘Thou shalt not mix UI and logic’ or ‘Get your XML out of my code!’.

What makes ASP.NET MVC so interesting is that it brings this pattern to the ASP.NET programming model, offering a much cleaner, simple to maintain and natural way (for app-devs that is) to program the web. One of my friends recently rewrote his blog using it, and I can’t wait to get an excuse to use this in a live project!

I highly encourage you to download the Visual Studio extensions and try them out. More info can be found here:

So today Microsoft revealed to the public that they will make the source code of major parts of the .NET framework available for viewing and debugging under the Microsoft Reference License. I’m not going to go into a lot of details of what the offering actually contains and I am sure a lot of people have an issue with this being called ‘Open Source’ in some channels. Me personally I would not call this Open Source at all, more as Microsoft themselves put it, a reference resource. Through this offering, if you are using Visual Studio 2008, you will be able to ‘step into’ the framework code while debugging to follow the code execution that goes on behind the scenes so to speak.

While this will make it a lot easier to figure out why things aren’t quite working as you expected, there is also another great winning here. If you, like me, spend a lot of time in Lutz Roeder’s excellent disassemble tool Reflector, and then use reflection to invoke, instantiate and work with internals of the framework, I think you will find it very valuable to be able to follow the actual execution paths taken by the framework code, and also to see how parameters passed to internal/private methods get cast and handled. From Scott Guthrie’s Blog:

“For example, in our scenario above I could also double click up the callstack and review the private ProcessRequest method on the System.Web.UI.Page class…”

I believe this is going to have a very big impact on the accessibility of the framework and I also this it will provide great aid and help to many .NET developers who are interested in understanding the internals of the base on which all their code relies.

I can’t wait to get my hands on this.

Check out Whurley’s blog post for the full announcement.

Miguel has some intersting thoughts on the impact on the Mono project.

ScottGu gives you the details.


Posted on: April 11, 2007

Today I held a 3 hour introduction to building user experiences (that’s UI’s for those who don’t like Buzz words :) using the Microsoft Expression suite of applications.

Focusing mainly on Expression Blend and how to integrate it into the workflow, I took the class from understanding the relationship between code-behind files and XAML, walked through data-binding, control templates & styles, animations and events, and finally built a small RSS reader.

I also gave a short introduction to the .NET framework and how its various parts come together to form the basis of the Expression/Visual Studio workflow.

The whole presentation was in Japanese and I suspect I did some interesting mistakes in both grammar and vocabulary. Sometimes translating technical terms from English to Japanese can be really tricky. A few times I managed to mix the word for Relationship with the one for Jump-Suite, causing some very confused looks :). 


This blog has no clear focus. It has a focus though, it's just not very clear at the moment...

Dev Env.

Visual Studio 2008 Prof / NUnit / Gallio / csUnit / STools (ExactMagic) / doxygen / dxCore / TypeMock / TestDriven.net / SequenceViz / CLRProfiler / Snoop / Reflector / Mole / FxCop / Subversion / TortoiseSVN / SlikSVN / CruiseControl.net / msbuild / nant

Blog Stats

  • 81,261 hits