DesignAndCode software development thoughts..

I recently bought the book "Inside Windows Debugging: Practical Debugging and Tracing Strategies" by Tarik Soulami. The book begins with the software packages you need to download. You need to be aware of your OS being a 32 or 64bit OS - and get the right version. I am using the 64 bit version of Windows, and for the Windows 7.1 SDK you need to download the GRMSDKX_EN_DVD.iso (that X in the name is the 64 bit version - there are 3 links you will find for the ISO installs).
With Visual Studio 2010, SP1 already installed on the machine - the Setup on my machine got errors. I finally found some posts that indicated that with SP1 - the Redistributable software was newer than what the SDK Installler was expecting.
I had to uninstall the Visual C++ Redistributable x64 version, on a 64 bit machine, that had anything after the version 10.0.30319 (if you are using the 32 bit - the same apparently goes there too).  Uninstalling the newer version of the Visual C++ 2010 Redistributable seems to allow the install to work.
I found another post that said to uncheck the Visual C++ 2010 compiler on the install -(when I ran a repair - I only found the Redistributable checked).
From what I read it seems like this release of the SDK had some issues - in multiple ways - with SP1 for Visual Studio.
The Error I was getting that helped me find the idea of uninstalling the Redistributable was

DDSet_Warning: Setup failed while calling 'getDLLName'. System error: Cannot create a file when that file already exists

There were some posts that suggested uninstalling everything and applying the SP1 bits after getting the SDK installed.
I hope others that hit the issue find this helpful. Some people apparently spent a great deal of time working out the issues.
It took me a while - a few hours to find and get the solution to work. Others said they had been searching for days to find this fix.

A few years ago, I heard about  a product that was in development called Mole that was used for .Net debugging visualization(now the company is called Moloscope). Today, I came across a "topic category" called "moles" in a question on Stackoverflow- initially I thought this was the same thing- but it is not. Apparently, Microsoft research developed an  Isolation framework that allows test code to create a "detour" - a detour can replace the .Net framework calls with your own delegate - to execute your unit test with - by reworking the IL code for the .Net Framework code. The Microsoft Research group named it Moles. A one letter difference between very different tools.

The Moles Framework was new to me,  and since it was connected to Pex, a "white box" testing tool I heard about back in 2008, - I was very interested in knowing more on this. Code Project has an article on the combination of Pex and Moles usage in testing applications.

In the StackOverflow question I started with, there were links to three training videos on the use of Pex and Moles, delivered by Peli de Halleux in a class in Spain, so it starts in Spanish but the class is in English.  'Video Part 1'(00:58) starts with a software test that requires access to a hard disk - and by the end of the video they have replaced that test disk access with a Moles delegate and even step into the debugger with it. This video used overlays to ensure you had a camera view of the instructor or monitor - even when people were walking in front of a camera - your view is of the subject (some walk throughs do occur) -so it is one of the better live presentation video recordings I have seen. 'Video Part 2' (1:57), and 'Video Part 3'(2:26).

InfoQ has a video presentation entitled "Test First v.Next with Pex and Moles"  presented by David Star (from Pluralsight) given at DevTeach in Belgium during October 2011. In the presentation he introduces Pex, and then the use of Code Contracts which Pex recognizes, and then works in how to use Moles framework. This presentation is a good introduction to the use of all three tools for development work. Mr Star clarifies the framework as not being a "mock" framework.

The combination of the tools should prove useful in the right context. With an end goal of having good tests for your code, and where you need to fake, detour, round some difficult bits that can cause issues.

In a recent project, I decided that I would use NUnit for testing functions during my development. There were a couple of things I learned in using it within Visual Studio 2010.

First, I read that the Nunit.config tags were needed within 2010 - as it defaults to .Net 4. NUnit installs to the "C:\Program Files\Nunit<version>". Within that is the "bin\.Net-2.0 folder. There is a config file "nunit.exe.config" that is used when using the GUI for testing. right after the configuration tag  I read that you need to add:

<startup>
<requiredRunTime version ="4.0.30319"/>
</startup>

I am using Nunit 2.5.9 - and without those tags - it still worked for me.

The other thing I learned was what would normally be an App.Config file needs to be a totally different file. You need to create a config file that matches the NUnit Project file name - and it must be located in the same directory as the NUnit Project file - so the NUnit GUI can find it.

Our project structure has a folder for Dependencies where we store DLLs that get used in the project - but might not have the source in the project. I created my NUnit Project file  in that folder. If that file is called NUnitProjectTests.nunit - there must be a config file called NUnitProjectTests.config - and that is used as your App.Config while running the GUI tests. In my project it is not in the "bin\Debug" folder - it's in a totally different folder.
You just need to remember to set the values in there and make them match your real app.config for your project output.

I found a link tonight that led to a Codeplex project http://www.codeplex.com/cracknetproject.

From the Codeplex site

Crack.NET is a runtime debugging and scripting tool that gives you access to the internals of a WPF or Windows Forms application running on your computer. If you love Snoop and Mole for Visual Studio, you’ll love Crack.NET, too. Crack.NET allows you to “walk” the managed heap of another .NET application, and inspect all values on all objects/types.

This looks like a good tool in becoming familiar with what is going on in WPF and Winform apps.