Applications built for the 3.0 Framework with VS2005 might not compile in VS2005

Thomas — Fri, 12 Dec 2008 21:26:01 GMT

Recently we've encountered some problems when compiling a .NET 3.0 application in Visual Studio 2005. The weird thing was that we could compile and run the application on our local machines, but the build computer we used refused to compile the application due to the simple fact that the code wouldn't compile. It called methods that existed, but an overload was used that didn't exist.

The local computer and the build computer had a 3.0 Framework or higher installed. Both had the same Visual Studio 2005 installed. Both had the same service packs installed. We just couldn't figure out what was different on those machines.

It turned out that the local computer had only a 3.5 Framework installed. All references in the project were to the 3.0 Framework, so everything compiled just fine. But Intellisense reads the metadata from the actual assebly being referenced, which was on the build computer the 3.5 assemblies. So on the build computer we had these overloads of Dispatcher.Invoke, all coming from the 3.0 assemblies:

Dispatcher.Invoke (DispatcherPriority, Delegate)
Dispatcher.Invoke (DispatcherPriority, Delegate, Object)
Dispatcher.Invoke (DispatcherPriority, TimeSpan, Delegate)
Dispatcher.Invoke (DispatcherPriority, Delegate, Object, Object[])
Dispatcher.Invoke (DispatcherPriority, TimeSpan, Delegate, Object)
Dispatcher.Invoke (DispatcherPriority, TimeSpan, Delegate, Object, Object[])

But on the local machine with only the 3.5 Framework we had these overloads:

Invoke(DispatcherPriority, Delegate)
Invoke(Delegate, array<Object>[]()[])
Invoke(DispatcherPriority, Delegate, Object)
Invoke(DispatcherPriority, TimeSpan, Delegate)
Invoke(Delegate, TimeSpan, array<Object>[]()[])
Invoke(Delegate, DispatcherPriority, array<Object>[]()[])
Invoke(DispatcherPriority, Delegate, Object, array<Object>[]()[])
Invoke(DispatcherPriority, TimeSpan, Delegate, Object)
Invoke(Delegate, TimeSpan, DispatcherPriority, array<Object>[]()[])
Invoke(DispatcherPriority, TimeSpan, Delegate, Object, array<Object>[]()[])

So if we used any overload from the latter list that is not in the first list, it'd not compile on the build computer. So, programmer beware: an application built in VS2005 might not compile in VS2005.

Automated testing en databases

Thomas — Fri, 14 Dec 2007 21:29:44 GMT

Eerlijksheidshalve gebied mij te zeggen dat ik dit artikel eerst "Unit testing en databases" wilde noemen. Maar Dennis Vroegop corrigeerde me gelijk toen ik het met hem hier over had. Zodra je een database bij je testen gebruikt, zijn het automatisch integration tests. Ik moet Dennis helemaal gelijk geven. Er worden tegenwoordig veel te veel dingen unit-tests genoemd...

Automated testing en databases is een verhaal apart. Er zijn verschillende manieren om het te tackelen, maar in feite heb je twee echte keuzes: je gebruikt mock-objects of je gebruikt een echte database. Ik gebruik zelf het liefste een echte database. Mijn argument daarvoor is dat je je triggers, stored procedures, etc., etc. ook goed wilt kunnen testen. Dat is met mock-objects gewoon niet te doen.

Een echte database gebruiken heeft wel een nadeel. Je moet er voor zorgen dat je testdata constant is. Als je testen runnen, moet het voor elke testrun wel altijd op dezelfde data zijn. En hoe ga je er voor zorgen dat als je bepaalde data nodig hebt voor een test, dat die data ook altijd bij het runnen van je test in je database zit? Als je een lege tabel nodig hebt voor de ene test en een goed gevulde (zelfde) tabel voor een andere test. Hoe ga je daar mee om op een overzichtelijke manier? Hoe weet je welke data in welke test wordt gebruikt?

De meeste unit-test frameworks hebben daar niet echt ondersteuning voor. Dus voor een hobby projectje voor een Formule1 manager spel, ben ik hier eens mee aan de slag gegaan. Nu gebruik ik zelf eigenlijk altijd de geintegreerde unit-testing van Visual Studio 2005/2008. Ik weet dat er andere, misschien wel betere zijn, maar ik vind de integratie in VS gewoon lekker. Maar hoe breid ik dit framework nou zo uit, dat ik bovenstaande problemen makkelijk kan oplossen?

De eerste stap was een base-class maken voor mijn testen. Hierin kan ik dan functionaliteit toevoegen die ik nodig heb voor het runnen van mijn database testen.

  [TestClass]
  public class UnitTestBase
  {
    public TestContext TestContext { get; set; }
 
    [TestInitialize()]
    public void TestInitializeInvoker()
    {
      TestInitialize();
    }
 
    protected virtual void TestInitialize()
    {
    }
 
    [TestCleanup()]
    public void TestCleanupInvoker()
    {
      TestCleanup();
    }
 
    protected virtual void TestCleanup()
    {
    }
  }

 

Volgende stap was om te zorgen dat elke test een connectie naar de database heeft en een transactie start. Door na elke test een Rollback te doen, blijft de database constant qua data. Dus ik maakte een class die tegen de testdatabase kon praten: connecties creeren en openen en scriptjes uitvoeren. De scriptjes zou ik dan opnemen als resource in de test-assembly. Ook koos ik er voor om een DbProviderFactory te gebruiken, zodat ik niet vast hing aan 1 bepaald type database.

  public class TestDatabase
  {
 
    public static IDbConnection GetConnection()
    {
      DbConnection connection = DbProvider.CreateConnection();
      connection.ConnectionString = ConnectionString;
      return connection;
    }
 
    public static IDbConnection OpenConnection()
    {
      IDbConnection connection = DbProvider.CreateConnection();
      connection.ConnectionString = ConnectionString;
      connection.Open();
      return connection;
    }
 
    private static string GetSql( string resourceName )
    {
      string fullResourceName = ResourceAssembly.GetName().Name + ( String.IsNullOrEmpty( ScriptsFolder ) ? "." : "." + ScriptsFolder + "." ) + resourceName;
      Stream resourceStream = ResourceAssembly.GetManifestResourceStream( fullResourceName );
 
      if ( resourceStream == null )
        throw new FileNotFoundException( String.Format( "Resource {0} not found.", resourceName ) );
 
      TextReader textReader = new StreamReader( resourceStream );
      string sql = textReader.ReadToEnd();
      textReader.Close();
      return sql;
    }
 
    private static void ExecuteSql( string sql )
    {
      ExecuteSql( sql, null );
    }
 
    private static void ExecuteSql( string sql, IDbTransaction transaction )
    {
      if ( String.IsNullOrEmpty( sql ) )
        return;
 
      string[] splittedSql = sql.Split( ';' );
      if ( splittedSql.Length > 1 )
        foreach ( string singleSql in splittedSql )
          ExecuteSql( singleSql, transaction );
      else
      {
        IDbCommand command = DbProvider.CreateCommand();
        command.Connection = transaction == null ? GetConnection() : transaction.Connection;
        command.CommandText = sql;
        bool closeConnection = false;
        if ( command.Connection.State == ConnectionState.Closed )
        {
          command.Connection.Open();
          closeConnection = true;
        }
        if (transaction != null )
          command.Transaction = transaction;
        command.ExecuteNonQuery();
        if ( closeConnection )
          command.Connection.Close();
      }
    }
 
    public static void ExecuteScript( string scriptName, IDbTransaction transaction )
    {
      ExecuteSql( GetSql( scriptName ), transaction );
    }
 
    public static void ExecuteScript( string scriptName )
    {
      ExecuteScript( scriptName, null );
    }
 
    public static void ExecuteDefaultScript()
    {
      ExecuteScript( defaultScriptName );
    }
 
    public static void ExecuteDefaultScript( IDbTransaction transaction)
    {
      ExecuteScript( defaultScriptName, transaction );
    }
  }
}

Maar wat ik niet wilde, was om mijn base-class te laten bepalen tegen welke database de testen zouden worden gerund. Dus ik had nog een class nodig om dit te bepalen. Ik wilde niet alles in een config file stoppen, maar een aparte class laten bepalen in welke type database we testen. Door middel van Inversion of Control laat ik dat dan een andere class bepalen.

Om nu een test te laten runnen en automatisch een Rollback te doen na het uitvoeren van een test, maakte ik een Attribute.

  [AttributeUsage( AttributeTargets.Method )]
  public class AutoRollbackAttribute : Attribute
  {
 
  }

Als ik dat attribute boven een test zet, dan zorgt de UnitTestBase er voor dat de Rollback automatisch wordt uitgevoerd.

protected virtual void TestInitialize()

{

_connection = TestDatabase.OpenConnection();

StartTransaction();

}

protected virtual void TestCleanup()

{

if ( HasAutoRollbackAttribute() )

Transaction.Rollback();

}

  private bool HasAutoRollbackAttribute()
  {
    MethodInfo testMethod = this.GetType().GetMetho( TestContext.TestName );
    object[] attributes = testMethod.GetCustomAttributes( 
        typeof( AutoRollbackAttribute ), false );
    return attributes.Length > 0;
  } 

Een test zou dat alleen (behalve het TestMethod attribute natuurlijk) dan alleen het AutoRollback attribute moeten hebben, om er voor te zorgen dat de test niets veranderd in de database.

    [TestMethod]
    [AutoRollback]
    public void SomeTest()
    {
      //test implementation
    }

Hiermee ben ik dus al een heel end. Maar ik wil ook toch testdata kunnen initialiseren voor een bepaalde test. Data die je alleen voor die test nodig hebt. Maar daar blog ik een volgende keer over. Dan zal ik ook de sourcecode beschikbaar stellen van dit mini 'testframework'.

Visual Studio 2008 RTM is beschikbaar...

Thomas — Mon, 19 Nov 2007 11:40:31 GMT

Op de MSDN Subscriber site is de Visual Studio Team System 2008 Team Suite RTM beschikbaar! Ze hadden al beloofd dat ie 'early next week' beschikbaar zou zijn, en maandag, einde van de ochtend, net na de eerste koppen koffie...Ja, dat kwalificieert wel als 'early next week'.

Eindelijk source code!

Thomas — Wed, 03 Oct 2007 21:00:00 GMT

Microsoft heeft besloten om de source-code van het .NET Framework te gaan releasen. Goed idee, lijkt me. Ik, met m'n jarenlange Delphi achtergrond, vond het altijd nogal hinderlijk dat je geen source-code had van de classes die je in je applicaties gebruikt. Van de Delphi VCL had je tenminste alle sources. Maar goed, met Reflector kwam je natuurlijk al een heel eind, maar locale variabele namen miste je bijvoorbeeld. Met de komst van Visual Studio 2008 en het 3.5 Framework is dat ook weer opgelost. Hier kun je er meer over lezen op de blog van Scott Guthrie.

Thomas Huijer : .NET Framework, Visual Studio

Applications built for the 3.0 Framework with VS2005 might not compile in VS2005

Automated testing en databases

Visual Studio 2008 RTM is beschikbaar...

Eindelijk source code!