TestDriven.NET by Jamie Cansdale

It has been over a month since my last update. I just want to put to rest any rumors of TestDriven.Net's early demise. With the help of my lawyers, I responded to Microsoft's lawyers' letter and am now attempting to come to a resolution of the issues. Continuing to play this out on the blogosphere would unnecessarily antagonize the situation and undo the good progress which has been made.

To be clear I am not anti-Microsoft. I am simply a passionate advocate of unit testing for developers of all experience levels. To my mind test driven development is like climbing with ropes. Beginner climbers can gain the confidence to climb without the fear of landing in a mess at the bottom. Expert climbers can take on overhangs and other hard problems that they wouldn't otherwise have the confidence to try. Climb without ropes if you like, but I am certainly not going to encourage it for anything outside your comfort zone.

To end on a happy note the Wells for Zoë charity that many of you supported last year through the .NET Developer's Charity Auction is about to enter a new phase. You can read about the pump workshop which is being set up in Mzuzu, Malawi later this year. There is also a photo blog which is being updated by our guy in the field (when the Internet works). Perhaps the people who suggested I put up a PayPal button to help with legal fees would prefer to save their money for something worthwhile and make a donation here instead. :-)

Jamie A comments to an article on Channel Register:

Here's a slightly less technical way of looking at the issue:

Microsoft essentially have 2 editions of a program. The first edition speaks English (User Interface) to the user, but in behind can speak French (COM) to other components.

The second edition also speaks English and French, but can also speak Russian (VSIP - Visual Studio Integration Programme).

Microsoft intends that your components speak Russian in order to extend Visual Studio. Their VSIP license agreement also states that you can only try to speak Russian to the second edition of the software. Attempting to speak Russian to the first edition is not allowed (even if it does speak the language).

Rather than try and speak Russian, Jamie has been using French. He has asked Visual Studio if it talks a certain dialect (COM interface), and it has said "oui". So he uses that dialect to talk to Visual Studio in order to do what he needs.

The main problem from Microsoft's point of view is that they didn't intend for anyone to use that dialect of French in order to talk to Visual Studio. They only expected Russian to be used. However, there's nothing that explicitly states this. Microsoft even has public notes on the French dialect.

Therefore, Jamie thinks he's in the right because Microsoft have not said that speaking French is forbidden. Microsoft sees it the other way. And the way things are going, it looks like the decision is going to come from a judge or jury.

There will be some French lessons in a follow up post.

Today Microsoft kindly extended my deadline by 24 hours so that I could further consult my lawyers. So far they have done a very good job of keeping the pressure on. This isn't simply a case of knocking out a quick email Pirate Bay style!

Before I released support for Visual Studio Express, I made a point of carefully reading the Express EULA. After reading it I was confident that the technique I was using wasn't in breach of the license. I am now acutely aware that if I turn out to be wrong I could end up losing everything. This isn't a situation that any developer wants to find themselves in.

Unfortunately the alternative to fighting this is bowing down to a vague catchall clause. I am an anxious person and don't want live in fear of this kind of thing.

I have just received another courier delivered letter from Microsoft's lawyers. That makes a total of 3 letters in 4 working days! I can see how these things can get expensive very quickly.

I'd like to highlight a couple of things in the letter.

They say that I have been in correspondence with Microsoft about these issues for many months. What they don't take into account is that in over a year of correspondence - Microsoft consistently refused to tell me which license I was allegedly in violation of.

For example on Feb 26, 2007 Jason Weber said:

Jamie, for the reasons we discussed at great length, we believe your
various extensions to the Visual Studio Express products necessarily
violated the relevant license terms. We don't think it's productive to
rehash those discussions.

We may have discussed this at great length, but I was never told what that the "relevant license terms" actually were! I only re-enabled Express support when Microsoft yet again failed to tell me where I was in violation. A straight answer with something I could tell my users would have resolved this.

I'm not sure where on my website this was suggested. It's possible that they're referring  to one of the comments on the last post. They do however bring up an interesting point. The license attached to their first letter was the one for "Visual Studio 2005 Standard and Academic Editions". It didn't matter that the license wasn't the Express SKU license because the wording is the same. What if it turns out that the reason I can't add buttons to Express SKU also applies to Visual Studio 2005? I would then be forced to take down TestDriven.NET entirely. What if it also means I can't use PopFly Explorer for Visual Studio Express? :-(

There are a few things I need to get off my chest.

When I started working on TestDriven.Net I was a hobbyist .NET developer. My day job was as a Java consultant. TestDriven.Net was something I did for fun between consultancy gigs. Working on open source projects can be a great way to learn a new technology. I enjoyed being part of the fledgling .NET community and positive reception TestDriven.Net (then NUnitAddIn) was getting.

When TestDriven.Net 1.0 was released I was still hobbyist .NET developer. It was only natural that I use the Visual Studio Express editions which were being targeted at other hobbyist developers. In fact I developed the whole of TestDriven.NET 1.0 using C# Express, MSBuild and WiX (as described in this post).

A few months after TestDriven.Net 1.0 was released Microsoft made me an MVP. According to Ben Miller (my then MVP lead) I was "very well known" for having created TestDriven.Net. As far as I'm aware this was the primary reason I received the award.

On Dec 1, 2005 I received an email from Jason Weber the lead for the Visual Studio IDE and Visual Studio SDK. Apparently Jason wanted to better understand my product and strategy. It was clear from the email subject that Jason incorrectly assumed TestDriven.Net was a VSIP Package. The interesting thing about VSIP packages being that they require a special key from Microsoft in order to function.

This is where the story begins. I'm not going to summarize what happened. I'm going to give you all the information so you can make up your own mind.

The first set of emails are between Dec 1, 2005 and Mar 30, 2006. They culminate in a teleconference between Craig Symonds (the General Manager for Visual Studio), Grant Drake, Jason Weber (who doesn't say a word) and myself. The second set of emails are between March 31, 2006 and Apr 17, 2007. They culminate with Jason finally letting me know which license I'm supposedly in breach of (the Express EULA). I'm still none the wiser about which clause. Finally I receive two letters (delivered by motorcycle courier) from Microsoft's UK lawyers. For the first time ever I am told which exact clause I'm supposedly in breach of (allegedly I'm working around some unspecified limitation). The second letter lets me know that they are reading my weblog and the TestDrivenUsers group.

Less than a year ago I was still a hobbyist .NET developer. I created TestDriven.Net as a tool for myself and something that I hoped other .NET developers would find useful. I have no intention of selling out and giving in to this kind of petty bullying.

I'm happy to report that TestDriven.NET is working on Orcas Express! If you'd like to try out the new C# 3.0/VB 9.0 language features without installing the full Visual Studio Orcas Edition then now's your chance. You should find this version works with Visual C#, VB and C++ Orcas Express CTP/.NET 3.5 Beta 1. Due to some changes Microsoft made to Orcas it works even more seamlessly than it does in Visual Studio 2005 Express!

NOTE: There is a chance this functionality will be disabled at 4 PM London time next Friday, 1 June 2007. Why find a technical solution to a problem when you have an army of lawyers?

Congratulations to Andrew Stopford and the MbUnit team for getting MbUnit 2.4 RTM out the door! This has been over 6 months of hard work. Well done everyone who was involved in this release. Not forgetting Peli who originally started this project (he was taken from us ;).

Andy has created a Facebook group for MbUint users. Join up and show your support.

Last week Ernie Booth announced a SilverlightBrowser plugin for Reflector. The plugin allows you to browse web pages that contain Silverlight elements and display their constituent Javascript, XAML and assembly files.

 

Ernie released the 0.1 Alpha code so people were free to modify it. The way the 0.1 code obtained the .js, .xaml and .dll files was by searching the HTML and Javascript source for specific patterns. For example it would search the HTML file for 'Silverlight.createObject' and extract the .xaml link from its parameters. This is similar to how Lutz's SilverlightLoader plugin works.

The problem with this technique is that it assumes that the 'Silverlight.js' and API (which comes with the Silverlight SDK) is being used. Unfortunately this won't always be the case. Some people may include the <object> or <embed> tags directly in the HTML or embed the XAML in a <script> block. A good example of this is Sam Ruby's Inline SVG in MSIE demo. This demo creates a Silverlight <embed> element and converts the SVG content into XAML on the fly!

I've modified Ernie's code so that is searches the WebBrowser object model for the .js and .xaml files. This means it is no longer making the assumption that 'Silverlight.js' is being used. It doesn't yet support XAML that is emended in a <script> block. I'm hoping to have it working with Sam's demo in the next version.

I have kicked off a community project for the SilverlightBrowser plugin on CodePlex (with Ernie's blessing). You can download latest version of the plugin from here.

Dare Obasanjo puts it best when he writes:

Although Pete does a good job of explaining the goals of Adobe Apollo with a great example, I think there is a simpler and more cynical way of spelling out the difference between Silverlight and Apollo. I'd describe the projects as:

Apollo is Adobe's Flash based knock off competitor to the .NET Framework while Silverlight is Microsoft's .NET Framework based knock off competitor to the Flash platform.

A lot shorter and more to the point. :)

If you're not already subscribed to Dare's blog you're missing out.

Henning Degn recently contacted me with a problem he was having running XNA code from TestDriven.NET. The code would run fine when executed from the application's 'Main' method. However when executing it as an ad-hoc test from TestDriven.NET he was seeing the following exception:

Microsoft.Xna.Framework.Content.ContentLoadException: Error loading "Content\myTexture". File not found. ---> System.IO.DirectoryNotFoundException: Could not find a part of the path  'C:\WINDOWS\assembly\GAC_32\Microsoft.Xna.Framework\1.0.0.0__6d5c3888ef60e27d\Content\myTexture.xnb'

It turns out that XNA tries to load its content files from a directory relative to the 'Assembly.GetEntryAssembly()' code base. The problem occurs when no 'Main' method is called (which happens when an ad-hoc or unit test executed) and no entry assembly is set. When this happens XNA defaults to using 'Assembly.GetCallingAssembly()' instead. Unfortunately the calling assembly is 'Microsoft.Xna.Framework' which is located in the GAC.

What we needed to do was find a way to set the entry assembly. Henning has documented our solution here. It basically involves calling a utility method 'AssemblyUtilities.SetEntryAssembly()' the beginning of each test.

Happy game development. :-)

Note: You will need TestDriven.NET 2.5 Beta or greater for XNA Game Studio Express support.

On the Silverlight promo video did anyone notice one of the actors using a device that looks for all the world like an Apple iPhone? ;-)

 

Talking of the iPhone. Since its OS is based on a slimmed down version of OS X - I wonder if we can expect to see Silverlight running on the iPhone some point in the future?

I have just released a new version of TestDriven.NET (2.7 Beta) with support for Silverlight/CoreCLR. Simply right click on the method you would like to execute with the CoreCLR and select 'Test With... Silverlight'. You can use this to execute any public methods (ad-hoc tests). I recommend you use 'Console.WriteLine' for any output messages. 'Trace.WriteLine' is supported by Silverlight's version of 'System.dll' but you would need to use something like DebugView to see the output.

Here is an example method being executed with Silverlight:

As shown above you do have access to the 'System.Windows.Browser.HtmlPage' static methods and properties (from the 'System.Silverlight' assembly). Hopefully people will find this feature useful for spelunking the Silverlight functionality.

I am working on proper unit testing support for Silverlight projects. At the moment none of the unit testing frameworks supported by TestDriven.NET (NUnit, MbUnit, MSTest or Zanebug) are compatible with the CoreCLR. I have had some success getting unit tests running using NUnitLite. You are welcome to contact me if you would like to try an early version of this.

Last week Harry Pierson wrote:

I wonder what the hosting model for the Silverlight CLR looks like? According to the "essential architecture", Silverlight includes the .NET Framework, the Core Presentation Framework and the Browser Host. But can you host somewhere other than the browser?

When I examined the Silverlight mscorlib assembly I noticed that Console.WriteLine and Console.ReadLine were still available. The functionality left in the Silverlight system assemblies has been pretty ruthlessly trimmed down. This lead me to believe that the Console class had been left there for a reason and there must be a way to run Silverlight console applications.

After some experimentation I have come up with agx.exe - a Silverlight console runner. The agx.exe name is a mixture of agclr.dll (one of the Silverlight assemblies) and clix.exe (the SSCLI/Rotor managed code runner).

Below is an example that shows some environment information and demonstrates Console.ReadLine working:

Hear is the IronPython interactive shell running as a console application inside Silverlight. I did have to tweak the source a bit to get this working. A few things like Assembly.Load(...) behave a little differently to their .NET 2.0 equivalents. A few IronPithon features appear not to be implemented when compiled for Silverlight.

The reason I'm experimenting with Silverlight console applications is so that unit tests can be executed inside the CoreCLR. I will then be able to add a 'Test With... Silverlight' option to TestDriven.NET. If you would like to try an early version of this functionality, feel free to drop me an email.

Joe & The VB Team has a tip for building Orcas projects with Expression Blend 2. This trick allows Blend2 to build projects using MSBuild 3.5 (the version Orcas uses). This should mean that projects created using Silverlight tools for Orcas will be compatible with Blend2. It does appear to fix the compile errors I was getting before.

Save the following text to '\Program Files\Microsoft Expression\Blend 1.1\Blend.exe.config':

<?xml version ="1.0"?> 

<configuration>
    <startup>
        <supportedRuntime version="v2.0.50727" safemode="true"/>
        <requiredRuntime version="v2.0.50727" safemode="true"/>
    </startup>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                 <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="3.5.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Build.Engine" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
                    <bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="3.5.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime> 
</configuration>

Syndicated from Kiwidude's Geek Spot

Some of you may already have noticed the long awaited release of NCover 1.5.7 yesterday - hoorah! That now being out of the way and in conjunction with some easing of my day job pressure, has made it a good time for me to finally rollout an NCoverExplorer update.

Note - if you have downloaded NCoverExplorer or TestDriven.Net over the last week or so you may want to do so again. I have been sneaking in fixes for issues right up until this blog posting. Check the downloads page to make sure you have the very latest build number.

This is predominantly a bug-fix release, addressing a range of issues that have accumulated over the last six months. Of utmost importance was improving the coverage result accuracy from either the merging of multiple coverage.xml files or multiple AppDomains within a single file. Some of you have experienced issues with the "optimisations" of removing noop sequence points that NCover 1.5.4, 1.5.5 and 1.5.7 apply in different ways. This resulted in duplicated nodes in the treeview, or lower than expected coverage with brackets being shown as not hit etc. My thanks to everyone who contributed to the testing of this with their coverage files/repro projects and patience while I got the kinks out.

On the new feature front, the biggest is a "Find Type" dialog (ctrl+F) allowing you to navigate to types by entering their name (supports * for a wildcard).

A change to previous behaviour is to the fail on minimum coverage option for NCoverExplorer.Console. Based on feedback this has now been changed so that any assembly not reaching the threshold will cause the build to fail, rather than total coverage.

All the other tweaks and fixes can be found in the release notes.

I have updated the NCoverExplorer Extras download containing the NAnt and MSBuild tasks. The <ncover> task now uses a reference counting style approach to the registration of coverlib.dll, which should get around issues reported on build servers of simultaneous build issues if you got unlucky with the timings.

The task now includes a registerProfiler optional attribute for those of you using TypeMock - you can set this to "false" to ensure the NCover task does not try to register CoverLib.dll itself.

There is an enhancement to the <nunitproject> task to support the appbase property for people using multiple testing folders (thanks to Garth Williams).

Another addition is a new <ndoc2> NAnt task in there for anyone using NDoc2 Alpha as I blogged about in this post. Documentation is available via the links on this page but anyone familiar with the <ndoc> task should be happy. I've used it for generating CHM documentation without any problems.

For any issues with the release or further enhancement suggestions, please post to the NCoverExplorer forums or send me an e-mail (Help -> Send Feedback).

A quick further mention on NCover 1.5.7. This is a mandatory upgrade for every NCover user as far as I am concerned. Peter Waldschmidt's major rewrite of the profiler core and the addition of an integration test suite sets up a great platform for future releases. I've been fortunate to be able to chip in here and there on this release, although arguably more nuisance than help at times to Peter I'm sure!

I am highly optimistic however that this is the most solid NCover beta to date and was worth the wait to get it right. Top stuff Peter and many thanks for all the effort!

Last but certainly not least, Jamie Cansdale has made available a new build of his excellent TestDriven.Net add-in. Amongst other goodies this now includes the latest build of NCoverExplorer, NCover 1.5.7 and Visual Studio Express SKU support. Right-clicky clicky goodness...

Downloads
Release Notes

Filed in: ncoverexplorer ncover ndoc