Dennis "D.C." Dietrich : Debugging

HTTP debugging for Silverlight developers (Mac OS X edition)

ddietric — Mon, 08 Jun 2009 13:00:00 GMT

Many posts have been written about how to debug problems with issuing HTTP requests from Silverlight applications, particularly in the context of web services and WCF (see for example Debugging Web Service Usage in Silverlight 2 or Faults and Exceptions when using Web Services in Silverlight 2). As they point out there are severe limitations to what information is passed to applications in case of non-200 HTTP status codes. And they also point out that sometimes you need to know what requests and responses are exactly sent over the wire in order to figure out what's going on, usually mentioning Fiddler for doing so. It is a very powerful tool allowing you to not only monitor HTTP traffic from certain applications but also letting you manipulate requests and responses (which is probably more than you need for "simple" debugging anyway).

This is all great until you hit an issue that only seems to repro on that other platform. Using a Windows application to debug on Mac OS X is impractical at best (impossible would be the better word in this case though). So, what to use instead? For my personal application development I use Wireshark which some of you may have encountered in the past under its old name, Ethereal. There are, however, a couple of differences. Wireshark is open source released under the GPL 2 but more importantly it is a sniffer and not an "HTTP debugging proxy". This means that in comparison to Fiddler it does not necessarily "know" HTTP as well since to Wireshark it is just another high-level protocol. It also means that a typical Wireshark capture picks up much more traffic than we care for (not using promiscuous mode in case of shared medium topologies at least reduces the amount of noise in the capture).

Wireshark is an X11 application so be sure that you have X11 installed and that it is up-to-date. Also, the OS X version of Wireshark uses BPFs to capture network traffic; however, access to those is denied for all users except for root (see also Enabling and using the "root" user in Mac OS X) so their permissions need to be changed first. This has to be redone after every reboot. While automatically making these changes during every startup or login has some appeal to it I prefer making them manually when they are needed. Given the nature of BPFs, keeping them locked down seems like a good idea to me.

Now we're finally ready to start Wireshark. The first start of the application can take a while (if I remember correctly this is due to X11 filling its font cache) so be patient. Also, all builds I have tried so far greet you with a nice pop-up error message. Luckily just ignoring it doesn't cause any trouble at least not in case of what I'm talking about in this post. At this point you can start capturing by simply selecting an interface from the list.

As mentioned before, this will give you much more information than you need since you'll see all traffic sent to/from your machine or all traffic hitting your interface if you are using promiscuous mode which is on by default. The screenshot below indicates 12752 captured packets after about 100 seconds which shouldn't surprise you since unlike Fiddler which is only concerned about HTTP Wireshark is capturing Ethernet frames. The simplest way to get to the information you really care about is to filter for http which is also shown in the screenshot. There's a lot more you can do like filtering for source or destination address so pay a visit to the Wireshark Wiki.

Lastly I'd like to mention that you can view a packet in its own window by selecting the command Show Packet in New Window from the View menu or by simply double-clicking on a packet in case you're running the latest development release.

This posting is provided "AS IS" with no warranties, and confers no rights.

It's all about systems - even if you're testing only a component

ddietric — Thu, 23 Oct 2008 05:00:00 GMT

Earlier this year I bought a brand new computer and wanted to play what turned out to be one of my favorite games of all times. However, it also turned out that this new computer of mine came with a pretty bad graphics card. It did work but the performance was so bad that even full screen DVD playback was impacted. So I got a new one, installed it and was ready to play. Except for the fact that the game which ran fine before crashed now during initialization. I did a quick search on the web and found reports from other users hitting a similar if not the same issue. I thought about sending an email to the developer but noticed that since others had already posted about this on the support forum it would be nothing more than a "me too" mail. Unless I provided some additional information and fortunately I had already installed Visual Studio on that machine. So I started the debugger and tried to gather some information about the crash. The first thing I saw was this:

Unhandled exception at 0x6e75f0ec (d3d8.dll) in SamMax101.exe:

0xC0000005: Access violation reading location 0x00000000.

Looked like someone was dereferencing a null pointer and then tried to read from that memory location. I did not pay enough attention to the module in which this occurred. If I had I could already have been done at this point but I kept going and checked the stack traces. There were seven threads of which only the main thread did something useful and it was also the thread on which the access violation occurred.

d3d8.dll!CD3DHal::CreateVertexShaderI() + 0x24c bytes

d3d8.dll!CD3DBase::CreateVertexShader() + 0x33e bytes

SamMax101.exe!005cc3a6()

[Frames below may be incorrect and/or missing, no symbols loaded for SamMax101.exe]

SamMax101.exe!0070a4b8()

SamMax101.exe!005cc79d()

SamMax101.exe!007a4aed()

SamMax101.exe!00556619()

SamMax101.exe!00730061()

kernel32.dll!_FindFirstFileA@8()

7ffdfbf8()

ntdll.dll!@RtlpAllocateHeap@20() + 0x3ce bytes

SamMax101.exe!00592208()

user32.dll!_NtUserPeekMessage@20() + 0xc bytes

user32.dll!__PeekMessage@24() + 0x2d bytes

The last two frames on the stack refer to functions in Direct3D of DirectX 8 suggesting that the game might be innocent after all (and it was). The function in which the access violation occurred was CreateVertexShaderI() according to the trace. Even without knowing all the details it's obvious that creating shaders involves the graphics card driver so there actually was another potential source for the issue that wasn't even in the stack trace. An inner voice finally said "update the graphics card driver, Luke" and after doing so the game worked flawlessly again (and with the new card also with a very high frame rate).

A couple of months later I received an email about Visual Studio crashing with an access violation when attempting to create a new Silverlight or WPF project. That sounded a bit strange so I asked for a stack trace and the trace I got back contained the following frame:

d3d9!CD3DDDIDX10TL::CreateVertexShaderFunc+0x88

With this piece of the puzzle the issue started looking similar to the game crashing because of a bad driver. So I suggested updating the graphics card driver and that once again did fix the issue. But why am I telling you all this. Well...

It's all about systems
First, let's go back to the title of this post. As testers we usually own a specific feature (area) that we focus on and there is nothing wrong with that - a complex product can't be tested by one person alone. But it is important to have an understanding of the components that your feature relies on. And of the components those components rely on and so on going down all the way to the operating system. Of course you cannot have a deep understanding of everything in a software stack down to the OS. The "further away" you are from the components you own the more basic/general your understanding of that part of the system will be. Still, any kind of knowledge you have will be an advantage. Going back to the sample of Visual Studio crashing, I have to admit I was irritated at first. But if you happen to know that WPF uses DirectX for rendering it's not surprising anymore that trying to use the WPF designer (which starts automatically when you create a new WPF application) can bring down VS in case of a bad driver. Ultimately this is about being able to determine the root cause of an issue which is essential for logging good bugs because otherwise a tester will log the issue against the feature through which the issue surfaced. That in turn puts an unnecessary burden on the developer to determine the actual cause. In my example above the developer might not even be able to repro the issue on his/her machine.
Good testers need broad debugging skills
I'm a "managed developer/tester". I love the .NET Framework and Silverlight and I try not to touch unmanaged code unless I really have to. But when you look at the software we use every day - starting with the OS itself - there is still a lot of unmanaged code in the mix which hosts our managed solutions and with which we interface/interop. Again my point is not to say that you should or even can be an expert in all possible fields. But because of the circumstances you need to be able to debug into the managed and the unmanaged parts of a system to determine the root cause of an issue or at least narrow it down. Just being able to figure out the area in which an issue originally occurred is pretty useful since it will allow you to take all the information you already gathered and hand it over to the person who actually owns the corresponding feature. More generally speaking - and also including debugging of managed code that is simply owned by someone else - testers need to be comfortable debugging into "foreign" (parts of the) codebase(s) in order to write detailed and accurate bug reports even if the issue extends beyond the features assigned to said tester.
Noticing patterns in defects
Granted, this post may not contain the best example. Either way, recognizing patterns is important as it can save you a lot of time. In my examples it was just about an access violation happening somewhere during vertex shader creation and your reoccurring issues may be more complex. The point is that if you have similar looking issues and you've already found a solution for one of them it's definitely worth checking if the same solution applies of the other ones.

This posting is provided "AS IS" with no warranties, and confers no rights.

How would you test a... C# code generator with Visual Studio Team Test

ddietric — Sat, 14 Jun 2008 15:50:00 GMT

Introduction

I spent some time this week thinking about how to test a code generator that generates C# code and is itself written in C# (so it's once again all about managed code). At first I thought about how to verify the generator output directly. Since the output is C# code - which ultimately is just a bunch of text - one approach is to create a collection of base line outputs and tests that run the generator with different inputs and compare the outputs to the base lines which have been verified when then the tests were written. There are two major flaws in this idea: Verifying the base lines in this scenario will be a manual task and even small changes to the generator output will cause tests to fail even if the new code behaves exactly the same way then before. Another approach would be to actually analyze the generator output but at the very least this would require parsing C# and I'll leave that to people who enjoy (and know how to) build compilers.

And? How would you test it?

So, coming to the conclusion that verifying the output was not an option I started thinking about the next best thing: Writing tests against the generated code and thus implicitly testing the generator. Makes sense; however, the question remains how to do that. One could run the generator manually for all interesting inputs, add the outputs to a test project and then write tests for them. This is actually worse than the approach with base lines since now there are a bunch of source files to update every time the generator output changes but the tests won’t automatically break when that happens. What I really wanted was running the code generator with every test pass. That said - and without further ado - let's look at some code. Consider a C# class library project containing the following "generator":

public static class CodeGenerator

{

public static string Generate(string name)

{

return @"

public static class PersonalizedHelloWorld

{

public static string Name { get { return " + (name != null ? "@\"" + name.Replace("\"", "\"\"") + "\"" : "null") + @"; } }

public static string GetHelloWorldMessage()

{

if (Name == null)

return ""Hello World! Hello anonymous user!"";

else

return ""Hello World! Hello "" + Name + ""!"";

}

}";

}

I say "generator" because obviously it doesn't do anything useful and I just wrote it for demonstrating my approach to testing generators which is also why I'm not using the CodeDOM. Now, let's think about the output we get for the string John "\/\/" Doe as the input. What I would normally do to test that code is create a new test project and write a test class like this one:

[TestClass]

public class NonemptyNameTests

{

[TestMethod]

public void NameProperty()

{

Assert.AreEqual<string>(@"John ""\/\/"" Doe",

PersonalizedHelloWorld.Name);

}

[TestMethod]

public void GetHelloWorldMessageMethod()

{

Assert.AreEqual<string>(@"Hello World! Hello John ""\/\/"" Doe!",

PersonalizedHelloWorld.GetHelloWorldMessage());

}

Apparently I can't do that because the class this code calls into does not exist when the test assembly is built. So instead I add a new source file to the test project with the following code and set its build action to Embedded Resource.

public static class NonemptyNameTests

{

public static void NameProperty()

{

Assert.AreEqual<string>(@"John ""\/\/"" Doe",

PersonalizedHelloWorld.Name);

}

public static void GetHelloWorldMessageMethod()

{

Assert.AreEqual<string>(@"Hello World! Hello John ""\/\/"" Doe!",

PersonalizedHelloWorld.GetHelloWorldMessage());

}

The idea is to compile this code together with the compiler output for the input John "\/\/" Doe during test execution. In order to do this I introduce a little helper method - we need to run and test the generator multiple times with different inputs after all.

public static class TestCompiler

{

private static string unitTestFrameworkAssemblyPath = typeof(Assert).Assembly.Location;

public static Assembly Compile(string generatedCode,

string generatedCodeFileName,

string dynamicTestCodeResourceName,

string dynamicTestCodeFileName,

string assemblyFileName)

{

string dynamicTestCode;

using (StreamReader reader = new StreamReader(Assembly.GetExecutingAssembly().GetManifestResourceStream(dynamicTestCodeResourceName)))

dynamicTestCode = reader.ReadToEnd();

File.WriteAllText(generatedCodeFileName, generatedCode);

File.WriteAllText(dynamicTestCodeFileName, dynamicTestCode);

CompilerParameters parameters = new CompilerParameters();

parameters.GenerateExecutable = false;

parameters.GenerateInMemory = false;

parameters.OutputAssembly = assemblyFileName;

parameters.ReferencedAssemblies.Add(unitTestFrameworkAssemblyPath);

#if DEBUG

parameters.IncludeDebugInformation = true;

#else

parameters.IncludeDebugInformation = false;

#endif

CSharpCodeProvider codeProvider = new CSharpCodeProvider();

CompilerResults results = codeProvider.CompileAssemblyFromFile(parameters,

generatedCodeFileName,

dynamicTestCodeFileName);

#if DEBUG

foreach (string message in results.Output)

Debug.WriteLine(message);

#endif

return results.CompiledAssembly;

}

All Compile() does is take a couple of names and generated code and return a new assembly. A key characteristic of this implementation is that the source code as well as the assembly are written to the file system which allows further analysis in case the code does not compile or test execution fails (the code provider does write code passed in as strings to the file system automatically - but it writes it to a temp directory and it is very quick to delete those temporary files as soon as the compiler finishes execution). Now we can add what VSTT/MSTest.exe will consider to be the test class:

[TestClass]

public class NonemptyNameTests

{

public const string AssemblyFileName = "NonemptyNameTests.dll";

public const string GeneratedCodeFileName = "NonemptyNameTests.target.cs";

public const string DynamicTestCodeFileName = "NonemptyNameTests.dynamic.cs";

public const string DynamicTestCodeResourceName = "CodeGeneratorTests.NonemptyNameTests.dynamic.cs";

private static Type dynamicTestType;

[ClassInitialize]

public static void ClassInitialize(TestContext context)

{

string generatedCode = CodeGenerator.Generate(@"John ""\/\/"" Doe");

Assembly assembly = TestCompiler.Compile(generatedCode,

GeneratedCodeFileName,

DynamicTestCodeResourceName,

DynamicTestCodeFileName,

AssemblyFileName);

dynamicTestType = assembly.GetType("NonemptyNameTests");

}

[TestMethod]

public void NameProperty()

{

dynamicTestType.GetMethod("NameProperty").Invoke(null, null);

}

[TestMethod]

public void GetHelloWorldMessageMethod()

{

dynamicTestType.GetMethod("GetHelloWorldMessageMethod").Invoke(null, null);

}

Note that the only real work this class does is run the code generator, build another test assembly with the generator output and the test code we embedded as a resource and store a Type instance for the new test class. Even more important, it does so in the class initialization method meaning that if an exception is thrown during the generation or the compilation step it will cause all tests in this class to fail. Furthermore, for every test to be added you need to add two methods: One in the class with the actual test logic which gets compiled at runtime and one in the class above that just calls the first one using reflection. And that's actually all we need to make this work. What's left for this post is a non-exhaustive list with the advantages and disadvantages of this approach.

Advantages

No manual steps
Running the code generator is an integral part of the test pass (which I considered to be a requirement) and so is compiling the code.
Unit test framework friendliness
Just to be clear - it doesn't matter if you consider any of this to be unit testing or not. The point is that you can use any unit testing framework you're already using anyway (like VSTT/MSTest.exe, NUnit, [insert favorite unit test framework here]) as long as it allows defining an initialization step for a test class.
Agnostic to changes not affecting behavior
Tests do not have to be updated in case of changes to the generated code unless its behavior changes (meaning changes in comments, white space, formatting and refactoring without API changes are free).
Test assembly is self-contained
In terms of test execution and from VSTT's/MSTest.exe's point of view there is absolutely no difference between the test project I described in this post and a "normal" one. All you need to run the tests is the assembly with the code generator (and of course its dependencies) and the test assembly (and its dependencies). This is also the reason why I chose to embed the test code to be compiled during text execution as a resource instead of keeping it as an external file.

Disadvantages

Can be difficult to write actual test code
Since the test classes actually doing the work are embedded as resources and refer to types not available when building the test project it can be more difficult to write them since IntelliSense and some other IDE features are not available unless you keep switching the build action from Embedded Resource to Compile and back and - if that is not enough help - temporarily copy the generator output into one of the test project's source files.
Can be difficult to debug
This applies primarily to the compilation failing since you have to rely on the raw compiler output to figure out why it failed. Failing tests are less of a problem because the debugger will open the source files compiled at runtime when it is configured to break when a first chance exception occurs. However, this can also be confusion at times because one must refrain from editing the file the debugger opened and fix issues in the original source file or generator code respectively. Also, since the test methods marked with the TestMethod attribute invoke the actual test methods through reflection, failing asserts will cause the test to fail because of a TargetInvocationException instead of the failed assert. Luckily, the original assert information is available through the InnerException property.
Cannot verify comments, formatting, etc.
One of the strengths of this approach is also a weakness. As the tests never look at the generated source code there is also no way to easily hook in steps to check things like comments or formatting.

Full annotated sample source code

/**********************************

* Project: CodeGenerator *

* File Name: CodeGenerator.cs *

* Build Action: Compile *

**********************************/

public static class CodeGenerator

{

// Useless code generator method for

// demonstration purposes only.

// DO NOT USE IN PRODUCTION ENVIRONMENTS!

public static string Generate(string name)

{

return @"

public static class PersonalizedHelloWorld

{

public static string Name { get { return " + (name != null ? "@\"" + name.Replace("\"", "\"\"") + "\"" : "null") + @"; } }

public static string GetHelloWorldMessage()

{

if (Name == null)

return ""Hello World! Hello anonymous user!"";

else

return ""Hello World! Hello "" + Name + ""!"";

}

}";

}

/************************************

* Project: CodeGeneratorTests *

* File Name: TestCompiler.cs *

* Build Action: Compile *

************************************/

using Microsoft.CSharp;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using System.CodeDom.Compiler;

using System.Collections.Generic;

using System.Diagnostics;

using System.IO;

using System.Reflection;

public static class TestCompiler

{

private static string unitTestFrameworkAssemblyPath = typeof(Assert).Assembly.Location;

// Use by test class initializers to compile the generated

// code together with actual test code into an assembly

// during the test pass.

public static Assembly Compile(string generatedCode,

string generatedCodeFileName,

string dynamicTestCodeResourceName,

string dynamicTestCodeFileName,

string assemblyFileName)

{

string dynamicTestCode;

// Reads the actual test code from a resource

// stream in the static test assembly.

using (StreamReader reader = new StreamReader(Assembly.GetExecutingAssembly().GetManifestResourceStream(dynamicTestCodeResourceName)))

dynamicTestCode = reader.ReadToEnd();

// Writes the generated code as well as the actual

// test code from the resource stream to the file

// system in order to allow debugging the actual test code.

File.WriteAllText(generatedCodeFileName, generatedCode);

File.WriteAllText(dynamicTestCodeFileName, dynamicTestCode);

// Parameters for the code provider telling it to generate

// a DLL and write it to the file system.

CompilerParameters parameters = new CompilerParameters();

parameters.GenerateExecutable = false;

parameters.GenerateInMemory = false;

parameters.OutputAssembly = assemblyFileName;

// The paths to/names of all assemblies containing types

// referenced in the code to compile need to be added to

// the CompilerParameters object ReferencedAssemblies collection.

parameters.ReferencedAssemblies.Add(unitTestFrameworkAssemblyPath);

#if DEBUG

// Need to make debugging easy in case a class initializer or

// test fails by having the compiler include debug information

// and create a PDB file.

parameters.IncludeDebugInformation = true;

#else

parameters.IncludeDebugInformation = false;

#endif

// Creating code provider instance and invoking C# compiler.

CSharpCodeProvider codeProvider = new CSharpCodeProvider();

CompilerResults results = codeProvider.CompileAssemblyFromFile(parameters,

generatedCodeFileName,

dynamicTestCodeFileName);

// Writing full compiler output to trace listeners in debug

// builds to preserve all errors in case the generated/dynamic

// test code does not compile.

#if DEBUG

foreach (string message in results.Output)

Debug.WriteLine(message);

#endif

// Returning new assembly to caller.

return results.CompiledAssembly;

}

/**************************************

* Project: CodeGeneratorTests *

* File Name: NonemptyNameTests.cs *

* Build Action: Compile *

**************************************/

using Microsoft.VisualStudio.TestTools.UnitTesting;

using System;

using System.Reflection;

// Test class verifying the code generator

// by testing its compiled output.

[TestClass]

public class NonemptyNameTests

{

// File and resource name constants for this test class.

public const string AssemblyFileName = "NonemptyNameTests.dll";

public const string GeneratedCodeFileName = "NonemptyNameTests.target.cs";

public const string DynamicTestCodeFileName = "NonemptyNameTests.dynamic.cs";

public const string DynamicTestCodeResourceName = "CodeGeneratorTests.NonemptyNameTests.dynamic.cs";

private static Type dynamicTestType;

[ClassInitialize]

public static void ClassInitialize(TestContext context)

{

// Running the code generator we want to test

// with one set of the inputs we need to cover.

string generatedCode = CodeGenerator.Generate(@"John ""\/\/"" Doe");

// Compiling the generated code together with the test code

// for the chosen generator input into a new assembly. Note

// that if the generator produced code with syntax errors

// all tests in this test class will fail because of an

// exception in the class initializer.

Assembly assembly = TestCompiler.Compile(generatedCode,

GeneratedCodeFileName,

DynamicTestCodeResourceName,

DynamicTestCodeFileName,

AssemblyFileName);

// Storing a Type instance for the test class type in the new

// assembly to be used by the test methods in this class.

dynamicTestType = assembly.GetType("NonemptyNameTests");

}

// The following two test methods do not contain actual

// verification code. Instead they call methods in the new

// assembly using reflection.

[TestMethod]

public void NameProperty()

{

dynamicTestType.GetMethod("NameProperty").Invoke(null, null);

}

[TestMethod]

public void GetHelloWorldMessageMethod()

{

dynamicTestType.GetMethod("GetHelloWorldMessageMethod").Invoke(null, null);

}

/**********************************************

* Project: CodeGeneratorTests *

* File Name: NonemptyNameTests.dynamic.cs *

* Build Action: Embedded Resource *

**********************************************/

using Microsoft.VisualStudio.TestTools.UnitTesting;

// Class containing the actual verification logic for a specific set

// of code generator input. This code is not compiled into

// CodeGeneratorTests.dll but embedded as a resource. It is compiled

// together with the generator output and called by methods marked

// with the TestMethod attribute using reflection during the test pass.

public static class NonemptyNameTests

{

public static void NameProperty()

{

Assert.AreEqual<string>(@"John ""\/\/"" Doe",

PersonalizedHelloWorld.Name);

}

public static void GetHelloWorldMessageMethod()

{

Assert.AreEqual<string>(@"Hello World! Hello John ""\/\/"" Doe!",

PersonalizedHelloWorld.GetHelloWorldMessage());

}

/************************************

* Project: CodeGeneratorTests *

* File Name: NameNullTests.cs *

* Build Action: Compile *

************************************/

using Microsoft.VisualStudio.TestTools.UnitTesting;

using System;

using System.Reflection;

[TestClass]

public class NameNullTests

{

public const string AssemblyFileName = "NameNullTests.dll";

public const string GeneratedCodeFileName = "NameNullTests.target.cs";

public const string DynamicTestCodeFileName = "NameNullTests.dynamic.cs";

public const string DynamicTestCodeResourceName = "CodeGeneratorTests.NameNullTests.dynamic.cs";

private static Type dynamicTestType;

[ClassInitialize]

public static void ClassInitialize(TestContext context)

{

string generatedCode = CodeGenerator.Generate(null);

Assembly assembly = TestCompiler.Compile(generatedCode,

GeneratedCodeFileName,

DynamicTestCodeResourceName,

DynamicTestCodeFileName,

AssemblyFileName);

dynamicTestType = assembly.GetType("NameNullTests");

}

[TestMethod]

public void NameProperty()

{

dynamicTestType.GetMethod("NameProperty").Invoke(null, null);

}

[TestMethod]

public void GetHelloWorldMessageMethod()

{

dynamicTestType.GetMethod("GetHelloWorldMessageMethod").Invoke(null, null);

}

/******************************************

* Project: CodeGeneratorTests *

* File Name: NameNullTests.dynamic.cs *

* Build Action: Embedded Resource *

******************************************/

using Microsoft.VisualStudio.TestTools.UnitTesting;

public static class NameNullTests

{

public static void NameProperty()

{

Assert.IsNull(PersonalizedHelloWorld.Name);

}

public static void GetHelloWorldMessageMethod()

{

Assert.AreEqual<string>("Hello World! Hello anonymous user!",

PersonalizedHelloWorld.GetHelloWorldMessage());

}

This posting is provided "AS IS" with no warranties, and confers no rights.

Setting up Silverlight 2 remote debugging on Mac OS X

ddietric — Thu, 06 Mar 2008 00:20:00 GMT

Let's face it: Silverlight is awesome! So are the Visual Studio Tools for Silverlight. One reason why it is so awesome is that you can run your applications on Windows and Mac OS X. But what if you need to debug an application while it is running on a Macintosh? Since there are no development tools for the Mac we have to resort to remote debugging which will allow us to debug the application running on OS X using Visual Studio on Windows. In order to do this we need to set up the CoreCLR debugging proxy on the Mac and then configure VS accordingly.

We start off by configuring the Mac. Everything we need on the Mac is part of the VS Tools for Silverlight installation and can be found in the directory %ProgramFiles%\Microsoft Visual Studio 9.0\Silverlight\MacIntel\ (or %ProgramFiles(x86)\Microsoft Visual Studio 9.0\Silverlight\MacIntel\ if you're running a 64-bit version of Windows). We just copy the whole folder over to the Mac e.g. into /Applications/ (you may also want to rename the copy on the Mac as MacIntel doesn't really describe the content that well). After that we have to mark the files configcoreclrdebug and coreclr_dbg_proxy as executable and then run configcoreclrdebug which will set up the debugging proxy and create a Windows executable containing all the information required to set up VS. It only requires two inputs: A port number in the range from 49152 to 65535 which will be used by the proxy to listen for incoming connections (you can also just hit Enter to accept the default in squared brackets) and a password used to protect the data in the Windows executable.

HOSTNAME:~ username$ cd /Applications/MacIntel/

HOSTNAME:MacIntel username$ ls -la

total 384

drwxr-x--- 6 username admin 204 Mar 3 05:25 .

drwxrwxr-x+ 42 root admin 1428 Mar 3 05:26 ..

-rw-r----- 1 username admin 62464 Mar 3 05:25 ConfigureWindowsCoreCLRDebuggingBase.exe

-rw-r----- 1 username admin 55383 Mar 3 05:25 MacDebuggingReadme.rtf

-rw-r----- 1 username admin 23604 Mar 3 05:25 configcoreclrdebug

-rw-r----- 1 username admin 48944 Mar 3 05:25 coreclr_dbg_proxy

HOSTNAME:MacIntel username$ chmod u+x configcoreclrdebug

HOSTNAME:MacIntel username$ chmod u+x coreclr_dbg_proxy

HOSTNAME:MacIntel username$ ./configcoreclrdebug

Generating debugger certificate and private key...

Done.

[...]

Select a TCP port number to be used for debugging: (49152-65535) [58752]:

[...]

Please specify a password at least eight characters long that will be used to

protect the debugging private key during transportation to the Windows machine

from which debugging will be performed.

Password:

Re-type password:

The CoreCLR debugging environment has been successfully configured on this

machine for the current user. In order to enable debugging from a remote machine

running Windows it will be necessary to propagate these same configuration

settings. To aid in this a Windows executable has been created in the following

file:

/Users/username/.coreclrdbg/ConfigureWindowsCoreCLRDebugging.exe

[...]

HOSTNAME:MacIntel username$

We now copy ConfigureWindowsCoreCLRDebugging.exe from the location mentioned in the output of configcoreclrdebug back to our Windows machine and execute it. All it will ask us for is the password we used to generate the executable.

C:\Users\username\Desktop>ConfigureWindowsCoreCLRDebugging.exe

Password: ********

This machine and user account has been successfully configured.

C:\Users\username\Desktop>

And we're done. We can now test this by creating a little app, copy the ClientBin folder over to the Mac and execute it there. Then we'll attach to it by using the Attach to Process... command from VS' Debug menu. We select CoreCLR Remote Cross-platform Debugging as the transport and enter the name or IP address of the Mac as the qualifier which will get us a list of the processes running on the remote machine. We just need to select the right instance of the web browser hosting the Silverlight runtime (its type will be CoreCLR Remote) and hit Attach. After that we can set breakpoints, check the value of variables and so on as usual.

This posting is provided "AS IS" with no warranties, and confers no rights.

Referenced assembly 'filename' is a localized satellite assembly (why it's not wise to ignore warning al1056)

ddietric — Sat, 13 Oct 2007 08:28:00 GMT

Usually you should fix all warnings you see when building your code right away and personally I'm a big fan of treating warnings as errors. Here is one more reason:

Marking an assembly with the AssemblyCulture attribute using a non-empty string will make that assembly look like a satellite assembly. Even if it isn't. So, although the metadata says that an assembly is a satellite assembly it can still contain code (although it should only contain resources) and if you actually manage to load the assembly you will be able to call the methods in it. However, loading the assembly can become a problem. Let's say you have a Visual Studio solution containing a class library project with one source file and the following code:

[assembly: System.Reflection.AssemblyCulture("en")]

public static class Foo

{

public static int Add(int i1, int i2)

{

return i1 + i2;

}

Compiling this code will result in an assembly that appears to be a satellite assembly according to its metadata. Let's add a second project to the solution, a console application. We then add a project reference to the library to the console application, paste in the following code and rebuild the solution.

class Program

{

static void Main(string[] args)

{

System.Console.WriteLine(Foo.Add(42, 23).ToString());

}

It builds fine except for the warning "Referenced assembly 'filename' is a localized satellite assembly" which is warning al1056 of the assembly linker. According to the assembly linker warning and error reference the full explanation for this warning is:

"An assembly created using the AssemblyCultureAttribute attribute was referenced in the creation of the current assembly. The AssemblyCultureAttribute attribute indicates the file is a localized satellite assembly and it is not normal to reference a satellite assembly. You should probably reference the main parent assembly instead."

In our case we have to remove the AssemblyCulture attribute that shouldn't be there in the first place because when we try to run the console application it will crash with a FileNotFoundException exception stating: "Could not load file or assembly 'assemblyname, Version=0.0.0.0, Culture=en, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified." But why? Visual Studio happily ignores the AssemblyCulture attribute and copies the assembly into the bin folder (ConsoleApplication1\bin\Debug\) when building the console application. At runtime the CLR on the other side will try to load what it thinks is a satellite assembly which by definition has to be located in a specific subfolder. You can simply verify that by moving the class library assembly into the correct subfolder (ConsoleApplication1\bin\Debug\en\). After that the application will work as excepted.

This posting is provided "AS IS" with no warranties, and confers no rights.

Fun with events and delegates

ddietric — Mon, 01 Oct 2007 12:57:00 GMT

So how can you verify that a given class raises an event? Well, you can simply write some code that registers an event handler and then cause the target to raise that event. Now, how do you verify that a given class does actually handle an event raised by another class? Basically it’s the same thing – just the other way round. You create test code which raises the event in question, makes the target register an event handler, raises the event and verifies that the target handles the event correctly. But how do you verify that a given class does not handle an event raised by another class? And why do you even need to worry about this?

The last two questions only make sense in a scenario in which a class under test registers an event handler in the first place and is then expected to unregister that handler later on. The obvious reason why you need to care is that the behavior of your software is probably incorrect if it keeps on handling an event although it shouldn't. The less obvious reason is that event handlers affect the lifetime of the object that handles the event because the delegate passed to the object that raises the event contains a reference back to the event handling object. This means that failure to unregister event handlers before getting rid of all other references to an object can lead to issues that are hard to debug. The best case scenario is that because of the remaining event handlers your software is behaving strangely so you at least notice that there is something going wrong (which might still be difficult to track down). The worst case scenario is that the remaining event handlers won't really do anything because of their internal state so unless you inspect your software and specifically look for method invocation counts, class instance counts or memory consumption you may not even notice the defect.

With all that said, how can we actually verify that a given object unregisters its event handlers? As mentioned before, simply raising the event may not give us any clue on whether or not there are handlers left. However, we can examine an event at runtime. But before I show some simple code that will help us to achieve this let's have a look at what an event really is. I most cases when you declare an event it will probably look something like this:

public event EventHandler SomeEvent;

The fun begins when we look at the IL generated by the C# compiler because of that one innocent line of code:

.field private class [mscorlib]System.EventHandler SomeEvent

.event [mscorlib]System.EventHandler SomeEvent

{

.addon instance void TestProject1.TestClass::add_SomeEvent(class [mscorlib]System.EventHandler)

.removeon instance void TestProject1.TestClass::remove_SomeEvent(class [mscorlib]System.EventHandler)

}

.method public hidebysig specialname newslot virtual final instance void add_SomeEvent(class [mscorlib]System.EventHandler 'value') cil managed synchronized
{
    .maxstack 8
    L_0000: ldarg.0
    L_0001: ldarg.0
    L_0002: ldfld class [mscorlib]System.EventHandler TestProject1.TestClass::SomeEvent
    L_0007: ldarg.1
    L_0008: call class [mscorlib]System.Delegate [mscorlib]System.Delegate::Combine(class [mscorlib]System.Delegate, class [mscorlib]System.Delegate)
    L_000d: castclass [mscorlib]System.EventHandler
    L_0012: stfld class [mscorlib]System.EventHandler TestProject1.TestClass::SomeEvent
    L_0017: ret
}

.method public hidebysig specialname newslot virtual final instance void remove_SomeEvent(class [mscorlib]System.EventHandler 'value') cil managed synchronized
{
    .maxstack 8
    L_0000: ldarg.0
    L_0001: ldarg.0
    L_0002: ldfld class [mscorlib]System.EventHandler TestProject1.TestClass::SomeEvent
    L_0007: ldarg.1
    L_0008: call class [mscorlib]System.Delegate [mscorlib]System.Delegate::Remove(class [mscorlib]System.Delegate, class [mscorlib]System.Delegate)
    L_000d: castclass [mscorlib]System.EventHandler
    L_0012: stfld class [mscorlib]System.EventHandler TestProject1.TestClass::SomeEvent
    L_0017: ret
}

First, we have a private field of the type we used to declare our event. This type is a delegate type derived from MulticastDelegate which means that it holds an array of delegates. The field being declared as private is also the reason why you cannot raise an event from a derived class. Second, there is the actual event which points to the methods add_SomeEvent() and remove_SomeEvent(). This is similar to how properties are compiled into getter and setter methods. The add and remove methods of an event are automatically called when you use the += and -= operators. Now that we have a clear understanding of what an event is we can go through some sample code. Say I have an interface that contains an event and a class that hooks up event handlers for that event in my production code:

public interface IRaisesEvent

{

event EventHandler SomeEvent;

}

public static class MyClass

{

private static Collection<IRaisesEvent> registeredObjects = new Collection<IRaisesEvent>();

public static void RegisterObject(IRaisesEvent obj)

{

if (obj == null)

throw new ArgumentNullException();

registeredObjects.Add(obj);

obj.SomeEvent += new EventHandler(EventHandler);

}

public static void ReleaseObjects()

{

foreach (IRaisesEvent item in registeredObjects)

item.SomeEvent -= new EventHandler(EventHandler);

registeredObjects.Clear();

}

private static void EventHandler(object sender, EventArgs e)

{

Debug.Print("Object of type {0} raised IRaisesEvent.SomeEvent", sender.GetType());

}
}

The next thing we need is a test class that implements the interface so we have something to pass to the static class. In addition to implementing the interface I also defined a read-only property that allows a caller to access the private MulticastDelegate instance. Please note that I do not advice you to do so in production code since this exposes detailed information about the event (which, however, is exactly what we want for testing purposes).

public class TestClass : IRaisesEvent

{

public event EventHandler SomeEvent;

public MulticastDelegate SomeEventMulticastDelegate

{

get

{

return SomeEvent;

}

This actually does the trick. We can now examine the state of the event (i.e. its currently registered event handlers) by calling MulticastDelegate.GetInvocationList() and the properties Delegate.Method and Delegate.Target allow us to get detailed information on each of those delegates. Of course creating some extension methods once for the most interesting scenarios will simplify our actual test code.

public static class MulticastDelegateExtensions

{

public static int GetDelegateCount(this MulticastDelegate d)

{

if (d == null)

return 0;

else

return d.GetInvocationList().Length;

}

public static Type[] GetTargetTypes(this MulticastDelegate d)

{

Delegate[] invocationList;

Type[] types;

if (d == null)

return new Type[0];

else

{

invocationList = d.GetInvocationList();

types = new Type[invocationList.Length];

for (int i = 0; i < invocationList.Length; i++)

types[i] = invocationList[i].Method.ReflectedType;

return types;

}

The methods above for example allow us to get the number of event handlers and the types of the objects that will handle the event. This is a reasonable setup for the test given that you can reuse the extension methods throughout your test projects. The test method itself is short and easy to understand:

[TestMethod]

public void DelegateTest()

{

TestClass c = new TestClass();

MyClass.RegisterObject(c);

Assert.AreEqual<int>(1, c.SomeEventMulticastDelegate.GetDelegateCount());

Assert.AreEqual<Type>(typeof(MyClass), c.SomeEventMulticastDelegate.GetTargetTypes()[0]);

MyClass.ReleaseObjects();

Assert.AreEqual<int>(0, c.SomeEventMulticastDelegate.GetDelegateCount());

}

This posting is provided "AS IS" with no warranties, and confers no rights.

A good reason for calling GC.Collect()

ddietric — Sun, 23 Sep 2007 12:11:00 GMT

You've probably heard that you should not call GC.Collect() and generally speaking this is absolutely correct. Yes, there are probably exceptions to that rule but unless you know for sure that calling GC.Collect() will improve the runtime behavior of your application you should refrain from making that call. Also, let's not forget that implementation details of the garbage collector can change between releases of the CLR. However, the possibility of forcing a garbage collection can come in very handy for testing or debugging purposes. Let's consider the following static class:

public static class MyClass

{

private static Collection<object> objects = new Collection<object>();

public static void RegisterObject(object o)

{

objects.Add(o);

}

public static void ReleaseAllObjects()

{

objects.Clear();

}

This class is of course pretty pointless. But it is suitable for illustrating a scenario in which a class holds references to an object created by a caller thus influencing the lifetime of that object. Instead of a ReleaseAllObjects() method you could for example think of a class that releases references when certain events occur. Either way, you might want to write a test which actually verifies that all object references have been deleted at a certain point. This is a problem GC.Collect() helps us to solve as an object without any references to it is automatically destructed by the garbage collector and because of the nondeterministic nature of the collector we have to manually trigger a collection. So, a step-by-step description of the test looks like this:

Create an object
Pass a reference to the MyClass class by calling RegisterObject(object)
Delete the local reference on the caller side
Call MyClass.ReleaseAllObjects()
Call GC.Collect()
Verify that the object has been destructed

Obviously we are still missing an important piece that allows us to do the actual verification that the object is no more. And that piece is a weak reference. Automated tests checking the lifetime of objects aside, weak references allow an object to keep a reference to another object without keeping the garbage collector from collection it (in other words, the garbage collector will ignore all weak references when determining if an object is still referenced or not). By creating a WeakReference referencing the object before deleting the regular reference to it we can verify that it has been collected by checking the IsAlive property which must be false at the end of the test:

[TestClass]

public class MyClassTests

{

[TestMethod]

public void ObjectLifetimeTest()

{

object someObject = new object();

WeakReference weakObjectReference = new WeakReference(someObject);

MyClass.RegisterObject(someObject);

someObject = null;

MyClass.ReleaseAllObjects();

GC.Collect();

Assert.IsFalse(weakObjectReference.IsAlive);

}

This posting is provided "AS IS" with no warranties, and confers no rights.