This reference tutorial will help you grasp the power of WinDebug debugging tool and quickly start using it in your daily development tasks. So, before we start, let me explain what WinDbg is.

WinDbg is a multipurpose debugger for Microsoft Windows, distributed on the web by Microsoft. It can be used to debug user mode applications, drivers, and the operating system itself in kernel mode. It is a GUI application, but has little in common with the more well-known, but less powerful, Visual Studio Debugger. WinDbg can be used for debugging kernel-mode memory dumps, created after what is commonly called the Blue Screen of Death which occurs when a bug check is issued. It can also be used to debug user-mode crash dumps. This is known as Post-mortem debugging.

WinDbg also has the ability to automatically load debugging symbol files (e.g., PDB files – Program DataBase file with debug information) from a server by matching various criteria (e.g., timestamp, CRC, single or multiprocessor version). This is a very helpful and time saving alternative to creating a symbol tree for a debugging target environment. If a private symbol server is configured, the symbols can be correlated with the source code for the binary. This eases the burden of debugging problems that have various versions of binaries installed on the debugging target by eliminating the need for finding and installing specific symbols version on the debug host. Microsoft has a public symbol server that has most of the public symbols for Windows 2000 and later versions of Windows (including service packs).

I’ve used WinDbg mostly in .NET applications, and that’s what I’ll be sharing this time around. To keep things simple and fast, because if you need WinDbg you are probably dealing with some memory issues and time is precious, I’ll put put it in steps:

1) You can start by downloading debugging tools from the Microsoft Windows SDK for Windows 7 and .NET Framework 4. You may also opt to download the ISO version. Take into consideration the target instruction set, either x84 or x64, depending on your application requirements.

2) Run WinDbg.exe executable. Search for WinDbg in "C:\Program Files (x86)\Debugging Tools for Windows (x86)" or “…WinDDK\7600.16385.1\Debuggers\windbg.exe” if you have the Windows Driver Development Kit.

3) Load mscorlib by writing:

        > sxe ld:mscorlib
        > g
       
        NOTE: Press enter after each line. "g" continues debuger execution.

4) Load the SOS Debugging Extension (SOS.dll). This allows debugging of managed programs in the WinDbg.exe debugger and in Visual Studio by providing information about the internal common language runtime (CLR) environment. First command in example loads SOS for debugging framework 2.0. The second is used for Framework 4.0.

        > .loadby sos mscorwks
        > .loadby sos clr (Framework 4.0)
        > g

5) Quick usage scenario #1: View memory consumption for all objects of a given type

        > !DumpHeap -type MyAppRootNamespace.ViewModels.ClientProfileViewModel

6) Quick usage scenario #2: View the managed call stack

        > !CLRStack

7) Quick usage scenario #3: View which object(s) are holding a reference to a specified address

        > !gcroot 29682dc0

Here’s a little script you can use to detect Framework 4 and load it in WinDbg.
   
    > !for_each_module .if(($sicmp( "@#ModuleName" , "mscorwks") = 0) ) {bp mscorwks!WKS::GCHeap::SuspendEE ".if (dwo(mscorwks!WKS::GCHeap::GcCondemnedGeneration)==2) {.echo start of gen 2}"} .elsif ($sicmp( "@#ModuleName" , "clr") = 0) {bp clr!WKS::GCHeap::SuspendEE ".if (dwo(clr!WKS::GCHeap::GcCondemnedGeneration)==2) {.echo start of gen 2}"}

Also, a full list of WinDbg commands, organized by category: http://windbg.info/doc/1-common-cmds.html.

And a PDF for you to print and keep it around your workspace.

Happy sessions.

There’s a time when new feature or frameworks arise and you get to know them and immediately grasp that new and useful way of doing things, but there are also times when clarity only comes after a bit of blurriness. From what I’ve read, the new Dynamic type in c# 4.0 is currently one of such cases, when compared to var. I read many developers say “What’s the point?” or “Why do I need this?”. Well, I believe it’s a matter of architectural needs, mixed with coding style. To break this discussion into pieces, and because I feel the force is strong with this one I found myself with the task of enlightening things up a bit.

In fact, this article hopes to settle the dust on this. I’ve seen a number of articles and posts on the web comparing and debating advantages and disadvantages, but I didn’t find them clear or eligible for training purposes. And even after knowing what each one really represent and allow, their usage and necessity is somewhat cloudy. Specially when it comes to dynamic.

So, to get the discussion started, I believe that we first must make sure we understand the basics of each one of these types, and build our structured thinking from there. You all know the System.Object type. Or its alias, object. Everything in the .Net Framework is an object, right? You can even refer to any type as object, by boxing it like this:

//Boxing
object var1 = 23;

// This will produce a compiler error
object sum = 3 + var1;

Since we specified 23 as var1’s value, it will be inferred and internally assumed as System.Int32. However, adding 3 var1 produces an “Operator ‘+’ cannot be applied to operands of type ‘int’ and ‘object’” compiler error.

This is where var comes in handy. If, instead of object we use the var type, the compiler will infer the underlying type and take it into consideration along the method scope. I say method scope because the var type can only be declared inside a method. So, the following would work:

var var2 = 23;

object sum2 = 3 + var2;

You can see the differences when boxing an Int32 value, but the same kind of difference arises when unboxing. Assigning var1 to an int variable produces a compiler error “Cannot implicitly convert type ‘object’ to ‘int’”, suggesting a cast, while assigning var2 compiles successfully:

// Produces compiler error
int var3 = var1;

// Compiles successfully
int var4 = var2;

var is still statically typed though. The only difference is, for instance, that you don’t need to repeat the type upon initialization:

// Type is specified only once
var x = new Collection();

It’s a nice bonus, but not it’s main purpose. The true purpose behind var is so that we can declare a strongly typed variable without needing to know the name of the variable’s type. This is crucial in order to enable C# 3.0’s anonymous types. You wouldn’t be able to declare a variable of an anonymous type if you always had to include the type name as part of the variable declaration. That’s the main reason var has been added to the language.

In some cases, when software architecture enables you to do so, you also have the advantage of changing return types without producing compilation errors.

Consider the following two classes. Event though they are similar in functionality, they are, nevertheless, different types and so, bound to the usual rules:

public class Human
{
    public int Age { get; set; }

    public string Name { get; set; }
}

public class Dog
{
    public int Age { get; set; }

    public string Name { get; set; }

    public string Breed { get; set; }
}

Now, imagine the following method from any given business layer, that returns a new instance of type Human:

public Human GetInstance()
{
     return new Human();
}

And a consumption example:

var o = GetInstance();

o.Name = "Alex";
o.Age = 23;

If, in the future, someone changes GetIntance()’s return type to Dog, you won’t need to change the previous code, because the same rules apply to the new type, since var’s type is implicit. Weird architectural approach, but an advantage to consider nevertheless.

And then there’s the dynamic type. dynamic is a static type, but an object of type dynamic bypasses static type checking. It’s like a type closing the door to the compiler when he knocks asking who’s in. And, as such, you don’t get the usual intellisence information. You’ll simply get the following:

 At compile time, an element that is typed as dynamic is assumed to support any operation. He simply doesn’t know what it is, nor where it comes from. You are in control

dynamic var1 = 23;

// Sum operation resolves successfully.
object sum1 = 3 + var1;

// This also works
int var2 = var1;

As you see in the previous snippet, it behaves just like var, but without intellisence. “No intellisence? Why bother then??” – you ask. We’ll get to that shortly. For now, consider the following extended Human class:

public class Human
{
    public int Age { get; set; }

    public string Name { get; set; }

    public void Punch(int intensity)
    {
        Console.WriteLine(string.Format("Punched with {0} strength.", intensity));
    }
}

A typical consumption example would be:

Human h = new Human();
h.Punch(100);

But if we used dynamic, we could do this:

dynamic h = new Human();
h.Punch(100, "Right in the face!");

Even though there’s no corresponding method signature in the Human class, the dynamic type made the compiler became passive, and he didn’t analyze the underlying/resolving type. So the snipped compiles just fine, but resulting in a runtime error later on.

The dynamic type has a broader usage than var. It can be used as a property, field, indexer, parameter, return value, local variable, or type constraint; it can be the target of an explicit conversion and it can be the right side assignment of both is or as operators or typeof argument. The following example demonstrates some of these arguments:

public MainWindow()
{
    InitializeComponent();

    // Prints ".net Brainwork rocks!" to the output window
    Console.WriteLine(ExampleMethod(23));
}

public dynamic ExampleMethod(dynamic number)
{
    dynamic dyn;

    int num = number;
    dyn = (dynamic)num;

    string str = ".net Brainwork rocks!";
    dyn = (dynamic)str;

    return dyn;
}

So what the dynamic type really does is telling the compiler to skip operation analysis and validation at design time, and instead, it resolves the types and operations at runtime. It accomplishes this through a new engine called Dynamic Language Runtime. The dynamic language runtime (DLR) is a new .Net Framework 4.0 runtime environment that adds a set of services for dynamic languages to the common language runtime (CLR). The DLR makes it easier to develop dynamic languages to run on the .NET Framework and to add dynamic features to statically typed languages. IronRuby and IronPython are two examples of languages developed by using the DLR.

Dynamic languages can identify the type of an object at run time, whereas in statically typed languages such as C# you must specify object types at design time.

The purpose of the DLR is to enable a system of dynamic languages to run on the .NET Framework and give them .NET interoperability. The DLR introduces dynamic objects to C# and Visual Basic in Visual Studio 2010 to support dynamic behavior in these languages and enable their interoperation with dynamic languages.

So, all in all, dynamic has an entirely new operation going on. It’s not just a matter of making it easier for developers to produce code or improve its quality, but it’s a new system for dynamic type handling, that improves how the language interacts with external data objects or services, whose types are only known at runtime like COM.

References:

Dynamic Language Runtime Overview – MSDN

Microsoft recently released an updated version of their Facebook SDK for .NET developers. This is the result of a joint partnership between Clarity Consulting and the Concept Development Team at Microsoft.

 According to Microsoft “the goal is to enable .NET developers to quickly and easily leverage the various features of the Facebook Platform.” The software giant has provided samples and tools for helping develop Facebook applications in the various .NET platforms including: ASP.NET, Silverlight, WPF and WinForms. Microsoft has also release the source code for the API, components, controls, and samples.”

 The main goals driving the release of version 3.0 are:

• Provide better doc and samples
• Provide support for Silverlight
• Provide support for ASP.NET MVC
• Provide improved support for WPF
• Provide improved support for FBML (FBML Server Controls)
• Provide a login control that can be used to replace the BasePage and/or MasterPage for Canvas Development
• Improve out of the box support for Extended Permission Prompts
• Refactor core source to improve maintainability and design
• Fix known bugs

The team worked closely with the Concept Development Team at Microsoft to help design the Silverlight and WPF support. Also, after discussions with Microsoft it was decided that the namespaces and methods should be updated again to be more consistent with traditional .NET apis. This will cause some breaking changes to everyone as they move to 3.0. But, the main goal is that we wanted to get it right this time so that this could become an officially supported client library. Microsoft is working with Facebook to get the toolkit identified as the officially supported library. The plan is to provide real-time support and updates to keep the toolkit in synch with the Facebook API.

The developer toolkit and SDK is available on CodePlex. You can download it here.

The Patterns & Practices team recently released their second version of the Application Architecture Guide 2.0. This guide is an essencial key for everyone who wish to step up to the next level of .NET Framework software development, by applying the best practices on their software technologies. It provides design-level guidance for the architecture and design of applications and focuses on the most common types of applications, partitioning application functionality into layers, components, and services, and walks through their key design characteristics.

You can reach their codeplex website here.

Download the guide here (released 15 Jan 2008).

Nice readings!

Microsoft released today the .NET Framework 3.5 SP1 GDR (General Distribution Release). This release addresses some issues and should only be installed if you have some kind of issue. Otherwise, it is not recommended to do so. You better wait.

In case you don’t know what a GDR is, here’s a quick explanation:

A GDR addresses an issue that has a broad customer impact, that has security implications, or that has both. It is determined and issued by Microsoft as appropriate and when appropriate. GDRs are kept to a minimum and cannot be requested by a customer. Microsoft internally determines whether a reported hotfix is classified as and delivered as a GDR. A GDR is released through the download center and is also released through Microsoft Update, through Windows Update, or through both.