For what it is worth there is a Windows User Experience Interaction Guidelines document that goes into great detail on how to ‘properly’ design a Windows UI. It will even tell you how many pixels a Cancel button should be from the lower and right side of a dialog.

With the advent of WPF and more unique / natural user interfaces I’m not sure how much coding to the specific guidelines matters any longer. However, I am assuming they take things such as this into account when certifying software for Windows Logo and the like.

One of the Visual Studio tester folks has a pretty cool website demonstrating various techniques and designs using WPF and Silverlight. Worth checking out: http://www.nokola.com

The Microsoft Biology Initiative (MBI) is an effort in Microsoft Research to bring new technology and tools to the area of bioinformatics and biology. This initiative is comprised of two primary components, the Microsoft Biology Foundation (MBF) and the Microsoft Biology Tools (MBT).

Microsoft Biology Foundation
The Microsoft Biology Foundation (MBF) is a language-neutral bioinformatics toolkit built as an extension to the Microsoft .NET Framework—initially aimed at the area of Genomics research. Currently, it implements a range of parsers for common bioinformatics file formats; a range of algorithms for manipulating DNA, RNA, and protein sequences; and a set of connectors to biological web services such as NCBI BLAST. MBF is available under an open source license, and executables, source code, demo applications, and documentation are freely downloadable from the project page. Learn more...

Microsoft Biology Tools
The Microsoft Biology Tools (MBT) are a collection of tools that enable biology and bioinformatics researchers to be more productive in making scientific discoveries. The tools in this catalog are free and, when available, include links to the source code and open source collaboration projects. Browse the catalog...

It is not often that I need to dig into the bowels of a system by pulling out WinDbg to examine the heap memory. I often stumble through the command syntax and/or try to find a quick reference (one of which I have posted previously on this blog). The following post from the Is This Thing On? blog entitled The Immediate Window: Running WinDbg and SOS (Son of Strike) Commands, could help reduce the need for working in WinDbg directly for some issues though. I am reposting the article here for future reference:

I could take a long time to teach you about WinDbg and SOS (Son of Strike) so I will avoid that here.  I want to give you a quick view into how SOS works in the Immediate Window.  If you want to get hardcore with debugging then the absolute best places to learn are these two blogs:

John Robbins over at Wintellect:  http://www.wintellect.com/CS/blogs/jrobbins/default.aspx

Tess Ferrandez an ASP.NET Escalation Engineer at Microsoft:  http://blogs.msdn.com/b/tess/

Loading SOS In The Immediate Window

With that said, let's take a look at what it takes to get SOS going in the Immediate Window.  As we go along I will also show you the most common messages you will encounter when trying to set this up.  First, open the Immediate Window (CTRL + ALT + I) and put in ".load sos" then press ENTER.

x86

You will most likely get this message:

"SOS not available while Managed only debugging.  To load SOS, enable unmanaged debugging in your project properties."

The fix is, obviously, to go to your project properties (the Debug tab):

and enable unmanaged debugging:

Now go back to the Immediate Window and type ".load sos" again.  It may take a few seconds but eventually you will see this message (your version will be different based on the CLR being used):

x64

If you get this message:

"Error during command: extension C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll could not load (error 193)"

Then that means you are attempting to debug an x64 (64 bit) application.  There is no support for interop (managed / unmanaged) debugging on x64 currently in Visual Studio.  You can fix this by going to the project properties (Compile tab) and clicking on the "Advanced Compile Options" button:

Then change the "Target CPU" to x86:

Using SOS

Threads and Symbols

You can now get all kinds of great information.  Type "!threads" to see threading info:

Do you see the error that says "PDB symbol for clr.dll not loaded"?  This is a common error that is trying to tell you that you need to get symbols (http://en.wikipedia.org/wiki/Debug_symbol).  The easiest way to do this is to go to Tools -> Options -> Debugging -> Symbols and check the "Microsoft Symbol Servers" box in the symbol file locations area:

Dump the Managed Heap

You can dump the managed heap by typing "!dumpheap".  Just watch out as this is pretty verbose output by default:

Current Thread Call Stack

If you want to display the call stack for the current thread you can use "!clrstack".  Here is a sample of the output:

These are just a few of the commands you can use.  You can get as deep or as shallow into this as you want but the moral of this story is you can run WinDbg and SOS commands from the Immediate Window.  Very cool stuff!

I ran across this list of attributes for .NET that while it is not comprehensive, it did appear useful to keep around for future reference. The list was provided originally on the DevCurry blog in a post entitled Attributes Every .NET Developer Should Know About.

I ran across a list of command line tools in a nice, succinct format in a blog post at DevCurry entitled Important .NET Framework 4.0 Command Line Tools You Must Know. It looks like a list that would be handy to have around, so I am reposting it here:

Security Tools

Debugging Tools

Interop Tools