Having finished the initial development I started testing and realised that, while useful during development,  my test stubs didn’t provide a useful testing environment. I considered writing a simple web service to mimic the customer’s but after a quick web search for web service mocking tools decided to give soapUI a try, not least because it’s available as a free open-source version.

I was sceptical of one reviewer’s claim that a mocked web service could be configured and running within a few minutes but was surprised to find that this is true. All I did was run soapUI, load the WSDL for the customer’s web service, and start the mock service.

To have the mock service return data you need to specify a response for each method called but soapUI provides an XML template for the response that makes it quick and easy to do this. There are several options to vary the response according to the method’s arguments.

Highly recommended.

This particular project has been running for almost two years but the particular interface that I’m responsible for was ‘code complete’ in July of this year. During some extended testing with large volumes of input data (around 18,000 HL7 messages) I noticed that a small number of messages were missing an identifier that the interface expects. In this implementation, the OBR-2 field of an ORU R01 message specifies the unique laboratory identifier for the test result.

No problems with the interface were found but the missing OBR-2 problem was reported to the customer’s developer responsible for the HL7 message feed. After several email exchanges it emerged that the IT Department Manager would not make anyone available to investigate the problem because the project was deemed to be a low priority as far as he was concerned. Perhaps this was understandable as the project didn’t have a ‘go-live’ date scheduled at the time but I still considered it a poor decision. At the very least, a few hours spent on determining the cause would have indicated what the cause was and how much effort would be required to fix it.

As far as I was concerned, the interface itself was finished and no further testing would be done until the missing OBR-2 problem was fixed prior to the first ‘dry-run’ of the ‘go-live’ process.

In November a project plan was written that scheduled the first dry-run for early December. This meant that the missing OBR-2 problem had to be resolved by then. Last week a member of the customer’s IT team looked at the problem and identified the cause within 20 minutes. It was not a bug but a deliberate design decision. The OBR-2 field in this particular laboratory’s data feed contains the requestor’s request id rather than the laboratory’s test identifier but if the test is unsolicited then it’s blank. The ‘fix’ agreed with the customer was to place the laboratory’s test identifier in the OBR-3 field and for the interface to use the OBR-2 value if available otherwise the OBR-3 value would be used.

This meant that the interface source code had to be updated and this in turn meant a new release build, installer, testing, deployment, etc.

So, even though I thought I was code complete at the end of July and that there was one small outstanding issue for the customer to resolve, here I was four and a half months later making code changes and going through another release cycle.

And all of this could have been avoided if the customer had allowed one of its developers to work on the problem for 20 minutes back in July.

At times like this we look for meaning in what has happened, to learn, and to improve safety in the sport. But, there’s little, if anything, that can be learned from Simoncelli’s death. This is not a ‘Senna moment’ for MotoGP. Senna’s death highlighted the fact that there were problems with the cars and the tracks that could be quickly and easily improved and they were. By contrast, Simoncelli’s death comes at a time when the bikes and tracks, and the helmets, gloves, boots, and leathers, are safer than ever before.

It’s difficult to accept that there isn’t a reason, some underlying cause, a rider error, or an equipment failure, that can explain what happened. Simoncelli’s death came as the result of a loss of control followed by a collision with other riders. The fact that this fatality occurred at one of the most modern and safe circuits underlines that this type of incident cannot be totally eliminated from the sport. The raw truth is that even in this day and age motorsport is dangerous and potentially lethal and, sooner or later, riders will die.

Any such death is a tragedy but Simoncelli’s is a particularly bitter blow. A likeable, straightforward guy who was his own man on and off the track, on and off camera. His performances at the start of this year’s season were a little erratic but his talent, enthusiasm, and will to win couldn’t be questioned. He was the epitome of the adage that a fast rider can learn to stop crashing but a slow rider can’t learn to be fast. His most recent results, a third place finish at Brno, a string of fourth places, and a second place at Phillip Island, proved that he was learning quickly. It always takes a lot of talent to put a bike on pole position and Simoncelli did it twice this year beating world champions like Casey Stoner, Dani Pedrosa, and Jorge Lorenzo in the process.

For the past few years MotoGP has been dominated by ‘the aliens’ – the elite handful of riders who are able to ride the current 800cc MotoGP bikes to the limit. This year only Simoncelli has been a regular threat to the aliens and at times has left some of them looking somewhat second rate. This is especially impressive considering that the aliens are all on full factory spec bikes in factory teams while Simoncelli is in a private team albeit on a factory bike and with support from Honda.

Honda’s problem at the moment is that they have too many riders in the factory team (three instead of the usual two) but it still offered Simoncelli a place in the factory team for 2012. Honda obviously saw a promising future for Simoncelli and wanted to bring him into the factory team despite already having a surplus of first rate riders. He turned Honda’s offer down to stay with the Gresini team for one more year but Honda agreed to continue providing a factory bike and support for 2012. The progress that he’d made this year and the continued factory support meant that he was likely to be on the podium regularly from the start of the 2012 season. With a third and a second place already secured he must have been looking towards his first race win. He clearly had the talent to win races and most, if not all, followers of the sport saw him as a likely future MotoGP World Champion.

Like many others I became a Simoncelli fan while watching him in the 250 GP class. I predicted great things for him in his first season in MotoGP and while he definitely made an early impact it wasn’t clear until halfway through the 2010 season that he had made a successful switch to the premier class. It’s worth remembering that even champions of the 125 and 250 (now Moto2) GP classes sometimes fail to make the transition to the premier class as the machines, their performance, and the riding style required, are vastly different. I didn’t fully realise how much of a fan I’d become until I experienced very mixed loyalties when Simoncelli and Cal Crutchlow were battling for seventh place in the closing laps of of a recent race. I was willing Simoncelli on when I suddenly realised that I ought to be supporting Crutchlow, the British rider. After a few seconds of confusion, I went with my heart and continued to shout encouragement for Simoncelli at the television screen.

Simoncelli’s performances on the track this year have provided most of the season’s excitement. His riding has been tough and uncompromising and has delivered some fantastic battles that he usually won. His quick but rough edged style was slowly being honed into something quite sublime. With the current 800cc MotoGP bikes, races are won and lost in the corners and Simoncelli’s ability to carry speed through a corner placed him among the best of the current riders. Not only did he take places by riding into and through a corner faster than his rivals, despite the disadvantage of his weight and size, he sometimes did it by riding the long way around rather than up the inside. His refusal to accept defeat, for example in the closing laps of this years Japanese GP, resulted in some of the most dramatic racing of the past few years.

His performances off the track were often as entertaining. For example, the press conference at Estoril this year where he joked, “Okay… I will be arrested!” when Jorge Lorenzo made an unprompted complaint about Simoncelli’s riding style. Or, his comment to a magazine reporter regarding the riders who complained about his allegedly dangerous riding: “They are not hard men – they are girls…”

To paraphrase a comment one poster made in a motorsport forum in relation to Simoncelli’s death: we are all defined by the date we are born and the date we die; it’s what we do between those two dates is that matters. Or as Simoncelli himself put it, “You live more for five minutes going fast on a bike like that than other people do in all of their life.” Few doubt Simoncelli’s comment that he’d be racing motorbikes even if he wasn’t being paid to do so.

He was a breath of fresh air in MotoGP and it’s difficult to imagine the sport without him. It will be a pale and bland imitation of what it was when we he was with us. We should be thankful to have witnessed a talent and personality such as his in the sport, no matter how briefly.

recursion  86, 139, 141, 182, 202, 269

You need to add a DWORD setting called NoSearchBox with a value of 1 under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Infodelivery\Restrictions

More info here:

http://www.vistax64.com/tutorials/68167-internet-explorer-search-box-add-remove.html

This is a Visual Studio 2010 solution with four projects that targets the .NET 2.0 Framework. One of the projects references a common assembly called Vitality.Common.Data.dll containing routines to access MySQL databases.

When she tried to build the solution, one of the projects failed to build and the single error message indicated that namespace specified in a using statement and implemented in one of the other projects, which was referenced, was not found. This was very puzzling as there was no indication that the referenced project was failing to build.

At this point I was ignoring the warning messages and just concentrating on the error message. After a few minutes of unsuccessfull investigation I looked at the warning messages which, initially, seemed to make the problem even more puzzling:

The primary reference “Vitality.Common.Data” could not be resolved because it has an indirect dependency on the .NET Framework assembly “Accessibility, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” which has a higher version “4.0.0.0″ than the version “2.0.0.0″ in the current target framework.

As the solution targets the .NET 2.0 Framework and references a .NET 2.0 assembly, why did the warning messages reference .NET 4.0 assemblies ?

But the main puzzle was why this solution could be successfully built on other machines. Using the most basic diagnostic approach, what was different on this machine ?

I vaguely remembered that my colleague had recently been working on a .NET 4.0 project that used the MySQL .NET Connector and guessed that she had installed the .msi package for this. Neither my machine nor the build server had the MySQL .NET Connector installed and relied on the solution including a copy of the referenced MySQL assembly. Could that be the difference ?

Well, an install of the MySQL .NET Connector would almost certainly have put the assemblies in the GAC and this particular version, 6.3.6, includes assemblies built for both the .NET 2.0 and .NET 4.0 Frameworks. Could this be why references to .NET 4.0 assemblies were appearing in the warning messages ?

Suddenly, it made sense…

Project A references Project B
Project B references Vitality.Common.Data.dll
Vitality.Common.Data.dll has a dependency on MySql.Data.dll

There is no direct reference in the solution to MySql.Data.dll so when it’s built this dependency has to be resolved by probing for the assembly. This is where the difference between the machines becomes significant as it appears that the GAC is searched for the dependency, MySql.Data.dll, first and then, if not found, the directory where the directly referenced assembly, Vitality.Common.Data.dll, resides.

So, on both my machine and the build server, the copy of MySql.Data.dll that is in the same directory as the referenced assembly, Vitality.Common.Data.dll is used but on my colleague’s machine it is the copy in the GAC that is used.

The simple solution was to add a reference to the project that referenced Vitality.Common.Data.dll for the copy of the MySql.Data.dll assembly in the same directory as the Vitality.Common.Data.dll assembly. Once this was done the solution could be successfully built.

The only remaining question is why the dependency resolution process selected  the .NET 4.0 version of the MySql.Data.dll assembly from the GAC rather than the .NET 2.0 version…

I started with an abstract base class but changed my mind and used an interface instead. Then I changed my mind again when I realised that I needed the class constructors to be part of the contract.

There are times when it’s obvious that an interface definition is needed and similarly there are times when it’s obvious that a base class is the solution. But in situations where it’s not obvious, for example the implementation of internal code in an assembly, then deciding whether constructors are part of the implementaion contract may guide you to the answer.

Perhaps I’ve led a sheltered life but until now I’ve only needed to use overloads of Activator.CreateInstance() that return an Object. This just needs casting in order to use it.

I’m not sure why this difference exists but it’s easy enough to deal with as the ObjectHandle class implements an UnWrap() method that returns the Object that the handle references.

The updated code passed its unit tests and I created a new releae build but a few days later I found that the code repeatedly threw a NullReferenceException when called from the Main() method of a Windows console application.

After a few hours of debugging and head scratching the cause eventually became clear. The problem only occured with Release mode compiled code and initially I thought the problem might be due to code optimisation. After ruling this out by disabling optimisation in Release mode compiles, I realised that it was the Debug Info setting that is accessed using the Advanced button on the Build tab of the project properties page. The problem didn’t occur when this was set to Full (as used in Debug mode builds) but did occur when it was set to PDB Only (used in Release mode builds) or None.

Using the debugger to step through the tracing code it became clear that when Debug Info is set to Full there is an extra frame on the stack between the stack frame for Main() and the tracing code’s constructor. Presumably, the Full setting causes some interception code to be generated by the C# compiler that results in the additional stack frame. So, in Release mode builds the tracing code was stepping too far up the call stack and when the caller was the program entry point this caused a NullReferenceException.

I considered updating the tracing code to examine the stack frames and determine how far up the call stack it needed to step but was concerned that this might add a significant performance overhead when tracing is active. Instead, I decided to define conditional compilation constants to indicate which Debug Info setting is active. The stack frame constant is then defined conditionally. The tracing code needs to step nine frames up the call stack when Debug Info is set to Full or eight when set to PDB Only or None:

#if DEBUGINFO_FULL
        private const int BaseStackFrameOffset = 9;
#endif
#if DEBUGINFO_PDBONLY || DEBUGINFO_NONE
        private const int BaseStackFrameOffset = 8;
#endif

The xsd.exe utility that ships with Visual Studio and the Windows Platform SDK supercedes XsdInfer.exe and XsdObjectGen.exe but while I’ve used xsd.exe to generate custom datasets over the past six years I’ve never used it to generate XmlSerializable data classes. So, it was a relief to find that xsd.exe successfully the C# classes  I needed and that these performed without any problems.

Over the past few weeks I’ve been updating our build processes and this seemed to be a good opportunity to phase out XsdInfer.exe and XsdObjectGen.exe in favour of an up to date distibution of xsd.exe.

In hindsight I shouln’t have wasted the time and effort because I just encountered one bug after another. Do a search for xsd.exe at Microsoft’s Knowledgebase web page:

http://support.microsoft.com/search/default.aspx?query=xsd.exe

and you’ll get a list of 21 bugs and problems.

Even when I wasn’t encountering bugs, the data classes it generated appear to be a step backwards. For example, repeating elements are represented as arrays without an IEnumerable implementation so that the foreach() syntax I’ve happily been using for years can no longer be used.

Amongst the behaviour that I’d classify as odd if not an outright bug is that when using inferring an XSD from an XML file, an attribute on an element causes it to be treated as a repeating element. If the intention is for the element to be a single item then this requires that the element is referenced as the first element type in an element type array rather than just the element type, e.g.

ConfigurationFile configFile = myClass.ConfigurationFile;

 
must be replaced with

ConfigurationFile configFile = myClass.ConfigurationFile[0];

 
which implies that there might be multiple ConfigurationFile elements.

This can be fixed by editing the XSD created by xsd.exe but this is not a viable solution in our automated build processes.

A related problem that definitely is a bug is that in some circumstances the serialization attributes in the class code generated by xsd.exe do not correctly describe the types being serialized. This shows up as a serialization failure at runtime with the following error messages:

Unable to generate a temporary class (result=1).
error CS0030: Cannot convert type 'xxxxxxxx[]' to 'xxxxxxxx'
error CS0029: Cannot implicitly convert type 'xxxxxxxx' to 'xxxxxxxx[]'

 
Examination of the class code shows that the the relevant XmlArrayAttribute has been specified with typeof(xxxxxxxx) when it should be typeof(xxxxxxxx[]). There’s a good blog post on this problem here.