In (the now famous) Project P, working with Microsoft CMS’s security model had me ripping my hair out.

Whenever I made a call to the context.Searches.GetByGuid() method, the system would throw a COMException, citing the quite unhelpful message “Server Error. Please contact your administrator”

For future reference (in case anyone comes across this themselves) the problem was caused because the GUID i was passing into the application was not formatted in the correctly for what CMS was expecting.

My code was doing:
string inputGuid = myGuid.ToString();

But it turns out it actually needed to be:
string inputGuid = myGuid.ToString(“B”);

The difference (according to MSDN) is that .ToString() with no overload assumes the format identifier of “D” which results in a GUID formatted without curly braces. Format “B” provides the same guid string but with curly braces.

Why this needed to throw a “Server error” exception, is beyond me. A simple ArgumentException would have sufficed, or better still it could take in a Guid as the parameter instead of a string.

For a blow-by-blow account of this problem, visit my newsgroup post about UserHasRightToBrowse Always Returns True

Covariance and Contravariance are terms used in programming languages and set theory to define the behaviour of parameter and return types of a function.

Yes, that’s a mouthful, but in a nutshell:

  • Covariance mandates that the return type and the parameters of a function must be a subtype of the original base class type for any superclass
  • Contravariance allows the return type and/or the parameter types to be super-types of the defined types and not necessarily sub-types

Nothing better than using an example:

[HTML1]

In this example:

  • Animal is a superclass.
  • Human is a subclass of Animal, with a covariant (no change) override to the CreateChild method to return the looser type Animal
  • Dog is a subclass of Animal, with a contravariant override to the CreateChild method to return the stronger type Dog

More reading on Eric Lippert’s blog series on Covariance and Contravariance in C#

EDIT: I thought it best prudent that I clarify that this is only one example of where variance is used. Method signatures, delegates and arrays are some more examples of where the theory of co and contra variance can be found.

All i can start with at this stage is wow…..

I went through by feeds this morning and innocently picked up an article introducing mocking using Moq. I’ve read a little about it, followed the fact that it’s gathered quite a following, and figured it best I give it a spin to see for myself.

And then I followed the links in that article….
And then I read the links in that article…..
And i was shocked to learn about the bad blood between the very two opposing camps, which i’d never realised….

Incidentally, I started off trying to learn more about Moq, and now i’m reading up about TypeMock Isloator…all in a day’s work i suppose ๐Ÿ˜‰

Inspired by a colleague at work who was required to research an area of audio technology as part of his audio engineering degree, i’ve been dabbling over the last few weeks with a Nintendo Wii Remote and DirectSound.

Basically, what he needed was a piece of software which could simulate a audio-centric virtual environment. The audio simulation would involve a sound being modified based on the head-orientation of the user. If the user looks to the left, the sound “appears” to come from the right side of the head, and the same vice-versa. In order to perform the head-tracking we were going to rely on the capabilities of the Wii remote and all it’s IR camera glory. As with all clients, there really wasn’t anything much clearer specified, and I was left to kind of work out the rest ๐Ÿ˜‰

The general concept behind the head-tracking is to use two points-of-reference on the user’s head to determine which side is left/right. Just like Johnny Chung Lee had done with his head-tracking exercise. With a little nudge forward from my old high-school electronics days, and $10 at JayCar, I’d soldered and constructed 2 purpose-built head-mounted IR LEDs. Blu Tack is an amazing product, and there’s nothing I found it won’t stick to. I won’t go into the detail of making one of these. It took me 20 mins, and the following article on making an IR LED pen was sufficient enough. As a tip, to check if your IR light is working correctly, you can use a digital camera and point the IR light toward the camera. Our eyes can’t pick up infra-red light, but the CCD on a camera can.

Post-hardware construction, the first phase of this project basically entailed a proof of concept, and an opportunity for me to learn about the two major components of this project i knew close to nothing about:

  1. Connecting and using the the Wii remote on a PC
  2. Using DirectSound to control audio

But first there would be more pressing matters. Like getting my Soleil Bluetooth receiver to work under VirtualBox on Linux. I don’t run any development software under my windows-boot partition. My windows partition has one intended purpose….To cut a long story short, it looked like it would be a bigger hassle trying to get the BT dongle to work under linux than to just install VS in my gamebox partition…So that’s that.

The BlueSoleil software worked like a charm, and within minutes I was hooking up the Wiimote to the laptop. no problems. The Wiimote is detected as just another HID, so it pretty much worked out of the box on XP.

At this point, I went out to find *how* to actually do each of the individual unknowns for this project. And it’s at this point I need to credit two articles which pretty much gave me everything I needed to get going. I was fortunate enough to find this article on CodeProject on using DirectSound, and an MSDN blog with a managed library for controlling the Wiimote. Too easy.

Hooked up the sample Wiimote library, turned on the Wiimote, turned on my IR lights and voila – worked a treat.

And that’s it for this post….next post, i’ll describe in a bit more detail the putting together of the software – certainly more interesting than all this drivel – and with pictures…..

short post…..

In some cases, the .NET framework will throw an exception internally, and then (using it’s own exception handling routines) re-throw something else based on that exception. if you’re getting an exception thrown from the Framework which you don’t really understand, and can’t work out what is causing the problem, try turning on the First Chance Exception for the .NET CLR in VS (Debug –> Exceptions).

This allows VS to catch any CLR exceptions when they are thrown, and will give you more insight into what’s the root cause of the problem.

Also, make sure you turn it off when you’re done otherwise you could end up constantly chasing your tail catching unnecessary exceptions ๐Ÿ˜‰

Also known as a CodeSniffer, this tool analyses your source code and outputs statistics of whether the code fails key standards which should be followed across your entire codebase.

    Source Analysis is similar in many ways to Microsoft Code Analysis (specifically FxCop), but there are some important distinctions. FxCop performs its analysis on compiled binaries, while Source Analysis analyzes the source code directly. For this reason, Code Analysis focuses more on the design of the code, while Source Analysis focuses on layout, readability and documentation. Most of that information is stripped away during the compilation process, and thus cannot be analyzed by FxCop.

Sweet. I’m going to try and push it into one of our local projects here ๐Ÿ™‚

[UPDATE]
….bugger. Looks like it is reliant on VS2005/.NET 2.0

why am i still stuck on this lousy 1.1 project? ๐Ÿ™

I love this one. I don’t know the name of the pattern, but i love using it.

Imagine your system uses strings to represent the value of a status field. potential values of this field are:

  • New
  • Requested
  • Open
  • Closed
  • Deferred
  • In Progress
  • More Information Required

…and you want to write a method (or webservice) called UpdateStatus, which takes in one of these values.

Standard signature would look something like this:

public void UpdateStatus(string newStatus)

The use of “string” for the static type has the problem that someone could pass through a rubbish value as a string, and the UpdateStatus method is now responsible for domain validation of the input.

However, following the pattern below, you’re able to statically define your domain (if known at design-time) and enforce the stronger type in subsequent method calls.

public class IssueStatus
{
	void IssueStatus(string description)
	{
		this.description = description;
	}
		readonly string description;

	public static IssueStatus New = new IssueStatus("New");
	public static IssueStatus Requested = new IssueStatus("Requested");
	public static IssueStatus Open = new IssueStatus("Open");
}

and you can then use the strong IssueStatus type in your signatures:

public SaveButton_Clicked(object sender, EventArgs e)
{
	bo.UpdateStatus(IssueStatus.New);
}

public void UpdateStatus(IssueStatus newStatus)
{
	if (newStatus == IssueStatus.New)
	{
	// do something here
	}
}

I learnt this one on the job a few years back, and think it’s fantastic.