You can now debug into the .NET Framework code when working with Visual Studio 2008.

There have been many times when it would have been very helpful to set breakpoints in the base classes such as Control. Until now I used .NET Reflector to see the base code implementation, but that is hard work to follow.

Follow these instructions to get started…
Step-by-Step Guide

If you have not already heard of it then I recommend you check out the useful Visual Studio visualizer called Mole. This is a handy tool that is available when you are in the debugger of you .NET application. It works with WinForms as well as WPF applications.

Mole Homepage
Mole Silverlight Videos
http://karlshifflett.wordpress.com/mole-for-visual-studio/

Mole Authors Blog
http://karlshifflett.wordpress.com/

What is the difference between a strong signed assembly and a publisher certified assembly?

Strong Signed
To strong sign an assembly you need to generate an encryption key and use this key to sign the assembly. The signing process generates a hash of the generated code and attaches this using the key to the end of the assembly. Whenever the CLR loads the assembly it notices the signing information and uses it to check that the code generates the same hash code as when it was originally compiled. If the hash code no longer matches then the assembly has been tampered with and so the CLR refuses to load it.

Placing an assembly into the global assembly cache (GAC) requires you strong sign the assembly. This is a reasonable precaution because there might be many different applications that are using the GAC assembly and you want to be sure it has not been modified to inject some malicious code.

However, just signing the assembly is not very secure. Anyone can remove the signing information from an assembly, modify the assembly and then sign it again. They cannot sign it with the same original encryption key because, hopefully, that is safely tucked away at the publishers. But they can generate a new key and use that is sign it with instead.

So the second half of the equation is the reference in the calling assembly. When the calling assembly was compiled it embedded a public token for the signed assembly into its reference information. So now when the application loads it not only knows the name of the assembly it wants to load but also it knows that it should be signed with a particular key.

This prevents the attack just mentioned. If someone takes the System.Windows.Forms assembly in the GAC, injects some dodgy code and then resigns it your application is protected. Your application starts up but the CLR loader says the GAC assembly is not signed with the right key to match the one you expected from compile time. Hey presto the load fails and you know something is wrong.

Publisher Signing
The internet adds a whole new level of threat to your machine. Any bored developer could write a Trojan horse application and offer it for download from a benign looking website. That free Spyware Remover application actually installs a key logger to grab your bank account details. They have signed all the assemblies in the application so it looks well behaved. But all the signing does is tell you the Trojan horse application is intact and in the original condition intended by the nefarious developer!

This is where the trust based security model comes into play. Whenever you download an application, or installer, from the internet and then try to run it Windows will tell show you a warning. Asking you if you really want to run this software and then present you with information about the publisher of the software. If you trust the publisher then you would let it run, it you don’t trust the publisher or if there is no publisher details at all then you should not run it.

As a publisher you can get hold of a publisher certificate from one of the big providers such as VeriSign and use that to sign the application/installer. Then the downloader gets shown you publisher details and can be sure it is from a trusted source and has also not been tampered with since it was created.

Component Factory has its own certificate from VeriSign and we sign all our installers so you can be sure it is in the original intended state and has not been tampered with.

Publisher Signing Assemblies
As well as publisher signing your application/installer you should also publisher sign all of the individual assemblies as well. This has a couple of benefits.

First of all the end user can right click any of your assemblies and see that it is signed and examine the certificate details. This should give them a nice cozy feeling and allow your support people to show that it is not your assembly that has been hacked on your end users infected machine.

But the most important benefit is that it allows your assemblies to be used by an application that is undergoing Vista certification. The certification requirements to get the Vista logo require that your application, and crucially all the assemblies that it references, be publisher signed. As a component vendor it is essential that our own assemblies are therefore signed so that applications built by our customers can pass the logo requirements.

Component Factory Assemblies
This requirement only came to light today when a customer needed publisher signed copies of the Krypton 2.5.1 release so they could progress with Vista logo certification. If you also need them just fire off an email to use and we can provide them on demand. All future releases of Krypton will have them signed automatically as part of the build process.

When you download an installer from the internet you want to know it has not been tampered with. You want to know it really is from the publisher described.

As a component vendor I want to sign my own installers so all users of Krypton can have confidence in the downloads. This is especially important with Vista as it shows the signing information, or lack of, at the slightest opportunity.

Software Publishers Credentials
In order to sign an installer you a private key (extension .pvk) and a software publishers certificate ( extension .spc). Obviously signing system would not be very secure if just anybody could create their own software publishers credentials with whatever company name they like. So instead you need to get your credentials from an approved provider that will then perform some background checking. They check you really are the company you say you are and not just impersonating someone at Microsoft!

I used VeriSign to purchase my publisher credentials at a cost of $499.

I would recommend you start the process of getting your credentials before you need them as it can a few days to work your way through the process. In my case I had to get a legal notary to sign a document proving I was the person I said I was. This is a reasonable precaution when dealing with a small one man company, you might find the process quicker and easier if you work at a large corporation.

So once you have paid your money and proved your identity you end up with two files.
MyCompany.pvk
MyCompany.spc

Signing the Installer
If like me your are signing several installers and/or signing on a regular basis then you will want to automate it as part of your build process. In this case you want to use the SignTool utility to perform the actual signing of the installer .msi file. But you cannot provide your two files as parameters directly because SignTool only takes a personal information exchange file (extension .pfx) as input. As luck would have it there is a utility called pvk2pfx that takes our two input files and outputs a .pfx file.

So to sign your installer you need to perform the following two commands:-

Pvk2pfx
-f
-pi “password”
-pvk “MyCompany.pvk”
-spc “MyCompany.spc”
-pfx “MyCompany.pfx”

Signtool
sign
/p “password”
/f “MyCompany.pfx”
/d “Product Description”
/du “http://www.myCompany.com”
/t “http://timestamp.verisign.com/scripts/timstamp.dll”
/v “MyInstaller.msi”

In practice I put these into a batch file and then just pass to the batch file the password, product description and installer filename. All the other parameters will remain constant.

Now when the user downloads and then tries to run the installer you get some publisher information in the warning dialog.

You can examine the certificate information in more detail by right clicking the installer and looking at the digital signature tab.

How do you track down a memory leak in .NET? Well here is a simple and effective technique that should work for you most of the time.

Just because you have a garbage collector does not prevent you from having a memory leak. In this context a memory leak is where you are not releasing all references to an object; so that object is never garbage collected.

So how do you work out where that rogue reference is that prevents it from being cleaned up?

Use the following steps inside Visual Studio 2005.

Step 1
You need to set your managed project to allow unmanaged code debugging. To do this you right click the project and select Properties. The project properties will be shown and from there you select the Debug page of settings. Then ensure the Enable unmanaged code debugging option is ticked. Just like below.

Step 2
Run your application in Debug and set a breakpoint at the place where you know the problem will have already occured. Use your application until you hit your breakpoint.

Step 3
Show the Immediate window so you can begin entering some debugging commands. If the window is not present then use the View -> Other Windows -> Command Window menu option to bring up the Command window. Inside the command window you use the Immed command and then the Immediate window will be displayed.

Step 4
Use the !load sos command in the Immediate window to load the Son Of Strike debugging extensions that allow us to examine managed memory.

Step 5
Use the !dumpheap -stat command. This will then list out all the different types of object that are on the heap.

Each line gives the number of instances of that type, the total amount of memory those instances occupy, the name of the type and a MT address. The MT (Method Table) address is the address of the type and not of any particular instance of the type.

You can see below an abbreviated example of the output.

You need to search this list for the type of the object that you think should have already been garbage collected and so should not actually be present.

We will use System.Drawing.Color[] as the example type from this point onwards. Looking at the above output you can see it has four instances.

Step 6
Use the !dumpheap -mt 7ae7bde4 command to list out the four individual instances of the type. Obviously you need to substitute the address from the MT column of the type you are actually interested in.

In our debugging session the four instances are listed as.

Step 7
Use !dumpobj 013070f8 to list out information about the specific object instance we are interested in from step 6. Again, you need to substitute the actual address with the relevant value found in the previous step. Here is the actual output for the Color[] instance.

Step 8
Now that we have found the rogue instance we believe should not exist we need to find the reference that points to it. Use !gcroot 013070f8 in order to search for all the references to the instance and also display the call stack for each reference.

In our example there is a single reference to the Color[] and the call stack of the object that references it is displayed in the output.

The first object in the stack is the windows form which references the next object down; which itself referencs the one below it and so forth.

In summary, the set of commands are as follows…

List all types of objects
!dumpheap -stat

List instances of a type
!dumpheap -mt {addr}

Examine an instance
!dumpobj {addr}

Find references to instance
!gcroot {addr}