Managing external assemblies within source control

We all know how important source control is, without it writing code would be a nightmare. Along with your actual code, any other development items should be checked into source control – automated tests, manual tests, designs and documentation.

However, another important, often overlooked, items are external frameworks and dependencies. For example, in the past, I’ve generally only committed the main assembly of a unit testing framework (lets say xunit.dll).  While xUnit is a relevantly small framework, it still has additional assemblies which I didn’t require (such as the ReSharper integration) – well at least I thought I didn’t. Turns out life is much easier if you simply commit the entire framework with all dependencies instead of just the ones you need to build and run. If everything is committed, when someone wants to run your unit tests on a clean machine, they can do so without your interaction.

This hit me even harder with ASP.net MVC releases. While I had commit System.Web.Abstractions.dll, System.Web.Mvc.dll, System.Web.Routing.dll for deployment, I mistakenly not included the actual installer. As a result, when I moved onto a different machine, I had a much harder time in getting the application up and running because I was missing the various parts of the Visual Studio integration.

If your not committing the entire framework into source control at the moment, I would really recommend you started.

Technorati Tags: ,

DDD7 Slides and Code – Pex – The future of unit testing

Pex

Yesterday, Developer Day (DDD) 7 was held at Microsoft UK. I delivered a presentation on Pex, a new project from Microsoft Research. I provided an introduction into Pex, the problem it attempts to solve, how Pex works in the real world and finally where I think the future of unit testing and Pex is heading.

I had a great day and I was very happy with my session – the demo gods where with me. Based on tweets via twitter and other comments, it was generally well received.  Thank you to everyone who attended, when feedback opens on the website please be sure to leave your comments as they are all taken into account.

 

Code Samples: http://blog.benhall.me.uk/downloads/DDD7/Code.zip

Slides: http://blog.benhall.me.uk/downloads/DDD7/Slides.zip

DDD7 also had Channel 9 recording all the sessions, if you couldn’t attend – don’t worry, hopefully the videos will be online in the new year!

Technorati Tags: ,,

.Net Fault Injection – It’s not just about exceptions

I had a interesting comment on my previous post about .Net fault injection. ‘Losing Side’ asked if this would work for simulating other faults such as timeouts. It’s a good point and one I didn’t think about yesterday, but there are other faults which are interesting when testing the application. Performance is one of those areas, creating performance problems, such as slow disk IO or a slow server is difficult if you don’t have the setup in place, and even then not always possible. How can you effectively, repeatability test for a slow hard drive (and using a virtual machine doesn’t count). Tools such as ANTS Profiler will help tell you where the problems are, but only if you can reproduce the problem.

First demo of the day, I ask the question – how can you simulate a slow write process when using StreamWriter?  Based on my previous post, I’ve changed the method to this:

private static void MethodFails()
{
    Console.WriteLine(“Writing to a file @ ” + DateTime.Now);

    string path = Path.GetTempFileName();
    StreamWriter sw = new StreamWriter(path);
    sw.WriteLine(“This is a test @ ” + DateTime.Now);
    sw.WriteLine(“This is a test @ ” + DateTime.Now);
    sw.WriteLine(“This is a test @ ” + DateTime.Now);
    sw.WriteLine(“This is a test @ ” + DateTime.Now);
    sw.Close();
    Console.WriteLine(“Done”);

    foreach (var s in File.ReadAllLines(path))
        Console.WriteLine(s);
}

Running my console application normally, I get the following output, notice no delays between each write:

Writing to a file @ 15/11/2008 13:23:48
Done
This is a test @ 15/11/2008 13:23:48
This is a test @ 15/11/2008 13:23:48
This is a test @ 15/11/2008 13:23:48
This is a test @ 15/11/2008 13:23:48

Running this using my injector, I have a five second delay (which I set, easily could have been a random number) between each of my writes to the file.

Writing to a file @ 15/11/2008 13:19:45
Done
This is a test @ 15/11/2008 13:19:51
This is a test @ 15/11/2008 13:19:56
This is a test @ 15/11/2008 13:20:01
This is a test @ 15/11/2008 13:20:06

I now get the same five second delay each time this happens, creating a scenario repeatable.

Disappointingly, I tried to use the SQLConnection object, but I couldn’t get this to work. I don’t know if its a limitation or a bug.  Still a lot more work to do until its even remotely useable, but I’m finding the concepts interesting.

Technorati Tags: , ,

.Net Fault Injection – Very early proof of concept

I’ve just completed my first proof of concept which I’m very excited about and I just had to write a quick blog about it – plus it breaks my blogging silence.

I find fault injection an interesting concept, I’ll explore it in more detail in later posts, but the aim is to insert exceptions at various points in order to test certain behaviours and how the application copes when an error occurs. However, raising exceptions is not a easy task, you have to create the scenario and environment in order for the exception to occur. With my fault injection application, you don’t need to create the scenario, you simply say when you want the exception to occur. For example, I would be able to throw an IOException when System.IO.File.ReadAllLines() is called without actually having to create the scenario for the exception to be raised – saving me time and effort but also allowing me to test more scenarios and error handling.

Tonight, I created a very simple concept to throw exceptions on method calls. I’ve got a very simple console application which calls two methods – nothing special about this.  When MethodFails() is called, my injector will step in and throw a MethodAccessException (could be any exception) which will be caught by the console application with the details of the exception being outputted.

using System;

namespace ConsoleApplication2
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(“Should output 1 message then fail”);
            try
            {
                MethodA();
                MethodFails();
            }
            catch (Exception e)
            {
                Console.WriteLine(“Exception caught”);
                Console.WriteLine(“Type: ” + e.GetType());
                Console.WriteLine(“Message: ” + e.Message);
            }
        }

        private static void MethodA()
        {
            Console.WriteLine(“This should work”);
        }

        private static void MethodFails()
        {
            Console.WriteLine(“this should have failed”);
        }
    }
}

The output of the execution is the following information:

Should output 1 message then fail
This should work
Exception caught
Type: System.MethodAccessException
Message: You attempted to call ConsoleApplication2.Program.MethodFails, this has been blocked. Goodbye

 

Technical details to come at a later point, it’s getting late in the UK. However, I would love to hear your comments on this idea.

Technorati Tags: ,

Windows 7 – What have you done to UAC?

After my week at PDC, this afternoon I installed Windows 7 on a spare machine. While I have noticed a few bugs, it generally appears to be very good – if not very similar to Windows Vista.

During the 2nd keynote I noticed they have changed UAC, so I decided to investigate what they have done.  When Vista was launched, Microsoft spent a lot of time and effort in trying to educate developers into understanding why its important for people not to run as administrator. Personally, I think it worked – for a large part of applications, you can run without needing to be an administrator. UAC has had a direct result on making improved more secure software.

However, things are different with Windows 7. By default (PDC build 6801), only certain actions will cause the UAC dialog to appear. For Administrators, you will not be notified via UAC when you make a change to the Windows settings, but you still will when a program installs. However, during the install the user you create is set as an Administrator. This means it will apply to a large portion of the Windows user base as they will all be running as Administrator.

If your interested, the new control panel dialog for UAC looks like this with 4 different levels based on the amount of security you wish to have:

UAC_DefaultSettings

The result of this default level is that Windows won’t cause UAC, but other 3rd party applications will (until hackers figure out to work around this).  The users perception is now that UAC is only annoying when using other people’s programs, but not Windows. Marketing are happy while the end user is left confused and vulnerable as they are unaware of when UAC should be displayed with the core message of protecting you and your system being lost.  

My Mother recently got a new HP laptop with Vista pre-installed which she happily configured from new, hence running as Administrator at the time. She had been hit with viruses and malware before with XP, but Vista the message to stay secure was simple. ‘If you see this a dialog with the darken background, call me or click cancel’. As a result, the laptop still works. No settings has been changed, no random applications installed and I’ve been asked once during the last 6 months why it has appeared.

With Windows 7, the message is more like ‘You can play around with all the Windows settings without being prompted, however you might be if other things change it, as a results it’s just best if you don’t touch anything.’

Take changing the time for example, by default a dialog will not appear when you click the ‘Change date and time…’, however it does have the UAC shield, which according to Microsoft means you should expect to see a UAC dialog (hence causing more confusion). Under the covers, Windows is silently evaluating the process, as a result it does have UAC permissions granted by Windows.

image

When applications are installing, you will see the UAC screen, however it no longer has the darkened screen.  Why this makes for a more fluent experience, the dialog is just that – a dialog. It means I have to spend even less time reading and thinking about it hence I will just click Yes.  At least when the screen changed, people (mainly me) woke up and looked at what was happening. 

 UAC_NoSecureDesktop

One more serious note – by default – from the default level to off doesn’t cause a confirmation UAC dialog!

To me, this is the extremely bad decision. UAC was designed to be annoying for a reason!! It was designed to make users click before confirming their action.  Please Microsoft, don’t change this. Please don’t make us go back to the dark days of having to run as Admin without UAC for all of our applications to work.

Technorati Tags: ,

Red Gate and I @ PDC 2008

PDC is fast approaching with some amazing technology due to be announced. You can’t help but get excited by Windows 7, VS10 and who knows what else? Don’t forget technologies such as the Pfx, IronRuby and Pex who will all be talking about their future plans.  PDC is partly the reason why I haven’t been blogging as much, but trust me – there is content lined up!

But PDC is not just about the sessions!! Don’t forget about the partner expo where I’ll be working on the Red Gate stand!  If you haven’t had chance to try our tools before, we have some great demos lined up for you so you can see for yourself how more productive you can be with our tools!

If you are already a user of our tools, why not stop by anyway for a chat and let us know what you think about our products!

If you want to know more about the rest of the team who will be at PDC, read the post on the [email protected] blog.

The Red Gate PDC team will be at booth numbers 410 and 412! Why not stop by for a chat and a quick demo!

Finally, keep an eye on the blog, I’m planning to write a few posts live from the stand.

Technorati Tags: , , ,

DDD7 – Microsoft Pex – The future of unit testing?

I received my email last night confirming that my Microsoft Pex session for DDD7 has been selected by you, the voting ‘potential’ attendees! I’m honoured that the session has been voted for, DDD is an amazing conference (registration is free, opening very soon) and based on the tweets from various people, there should be some great sessions.

If you would like a quick overview of Pex before DDD, then I suggest you read my MSDN Flash article.

What:
DDD 7

When:
Saturday, November 22, 2008 9:00 AM to 5:00 PM

Where:
Microsoft

Thames Valley Park
Reading, Berkshire RG6 1WG England

Technorati Tags: , ,

UK MSDN Flash – Pex: Automated testing for .NET

A quick heads up regarding a short Microsoft Pex article I wrote for the UK MSDN Flash newsletter. If you want a quick introduction, or a link to share with your colleagues then the article can be found here – 01 October 2008- Pex- Automated testing for .NET

On a side note, if you haven’t registered for the newsletter, now is a great time to do soon.  If you sign up before 28th November 2008, you will be entered into a prize draw where you could win a XBox 360 Elite (plus other prizes). Register on the website:

http://msdn.microsoft.com/en-gb/flash/default.aspx

Technorati Tags: ,

xUnit TeamCity Integration

Last night I was doing some experiments with xUnit and TeamCity. TeamCity has a nice UI for reporting tests, however by default it only supports NUnit. Luckily, extending this to support other tests is easy as it just listens for MSBuild outputs in the right format (##teamcity[testStarted name=’Test1′]).

This worked and my tests where appearing in the report.

My TeamCity Runner

On the other side of the ocean, Brad was actually working on extending the existing xUnit MSBuild runner for TeamCity integration.

The advantage of Brad’s runner is that you don’t need to edit your MSBuild script, as long as your using the xunit msbuild task it will know when TeamCity executed the build and log to the correct place. Otherwise, it will log to the standard MSBuild output – very cool!

image

If you want to use this today, download the source code from CodePlex and build it yourself (Get3rdParty.cmd is a great script to run before you build), but I suggest you wait for the next release (1.0.0.4), where support will be included.

Documentation on how to use the MSBuild task can be found here, as I mentioned, using it via TeamCity is no difference.

Technorati Tags: ,