Category Archive

Let’s say you have a third party library that you want to reference from your project. By default platform target in Visual Studio is “Any CPU”. But the library is compiled for specific target – x86 or x64. When you’re working in a team, have a build server and all of them is in different platforms you’ll start to have issues. Like, project with an x64 referenced assembly working ok on your x64 machine and failing on x86 computers and so on.

For us it was the “System.Data.SQLite” – the ADO.NET provider for SQLite. It is provided compiled separately for 32 and 64 bit systems. It was not easy to figure out how to manage references to SQLite provider without making too much changes in our projects and build scripts.

I’ve found an elegant solution for it: manually modifying project files that are using it to add a condition to “Reference” task of MSBuild. Look at this code:

<Reference Include="System.Data.SQLite, Version=…, … , processorArchitecture=AMD64"
  Condition="$(PROCESSOR_ARCHITECTURE) == 'AMD64' Or $(PROCESSOR_ARCHITEW6432) == 'AMD64'">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\Lib\x64\System.Data.SQLite.DLL</HintPath>
</Reference>
<Reference Include="System.Data.SQLite, Version=…, … , processorArchitecture=x86"
  Condition="$(PROCESSOR_ARCHITECTURE) == 'x86' And $(PROCESSOR_ARCHITEW6432) == ''">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\Lib\x86\System.Data.SQLite.DLL</HintPath>
</Reference>

We’ve added the “Condition” attributes to “Reference” task and we specify when we’re making the reference and specify in “HintPath” the assembly for current platform.

Detection of the current platform is based on checking of two environment variables: PROCESSOR_ARCHITECTURE and PROCESSOR_ARCHITEW6432 to detect “bitness” of running OS/processes. Details of this you can find in the post of David Wang HOWTO: Detect Process Bitness.

Working like a charm for us.

A snippet from a project I’ve been reading:

// -- FILE ------------------------------------------------------------------
// name       : UserConfig.cs
// created    :
// language   : c#
// environment: .NET 2.0
// --------------------------------------------------------------------------
using System;

namespace TheNamespace.Configuration
{

    // ------------------------------------------------------------------------
    public class UserConfig
    {

        // ----------------------------------------------------------------------
        public UserConfig( System.Configuration.Configuration configuration )
        {
            if ( configuration == null )
            {
                throw new ArgumentNullException( "configuration" );
            }

            this.configuration = configuration;
        } // UserConfig

        // ----------------------------------------------------------------------
        public System.Configuration.Configuration Configuration
        {
            get { return this.configuration; }
        } // Configuration

        // ----------------------------------------------------------------------
        public string FilePath
        {
            get { return this.configuration.FilePath; }
        } // FilePath

        // ----------------------------------------------------------------------
        // members
        private readonly System.Configuration.Configuration configuration;

    } // class UserConfig

} // namespace TheNamespace.Configuration
// -- EOF -------------------------------------------------------------------

It’s a matter of taste, of course, but I’m wondering, what is the reason to decorate the code with a such ceremony?

Much of the time we, developers, are spending reading the code. That’s why the code that is clean, easy to read and understand is so much appreciated.

Jimmy Bogard has a very nice summary of steps you can do to speed up building of your project or solution. By “build” I mean not just rebuilding solution from scratch, but doing also a complete run down: cleanup, rebuild and run your tests. This can be a local build performed on a developer’s machine, or a continuous integration build performed by dedicated build/integration server.

Some time ago, when build times grew to intolerable limits, we cut down number of projects in our solution. Along with a common output folders, this improved dramatically performance especially on integration server, where a single committed change threw running of few cascading builds and code analyses.

Now, slowest part of our build process are integration tests. A big part of them are “testing integrations” with database. Since we’re using real MS SQL Express 2008 instances to run them, tests are very slow. A natural solution is using of an in-memory database like SQLLite. We spent some time on this, but since our database interactions are not trivial (kind of multi-tenant & multi-database application) we gave up until better times. But I think we will be back to finish that, because with more tests written we’re pushing up build times. To give an idea how this can be done, Ayende Rahien has a very basic example how to use in-memory database to run NHibernate integration tests.

In our projects we’re using Binsor to configure services in our Windsor container. Main reason to do that is Binsor’s extreme expressiveness. It’s much easier to write and maintain next fragment:

import MyApp.Services
component IMyService, MyService

compared with standard way of configuring components in Windsor:

<component
    id="my_service"
    type="MyApp.Services.IMyService, MyApp"
    service="MyApp.Services.MyService, MyApp" />

Difference is more evident when you have to maintain files with tens and hundreds of components. Sure, you can use some kind of “autoregistration” for components, this can reduce dramatically size of configuration files.

But, since Binsor is a kind of DSL, is not always evident how to configure complex components that have dependencies and configuration properties to specify. The Binsor’s unit tests are the place where to look for samples, but they don’t cover everything.

Today, I had to configure a NHibernateIntegration facility from Castle with Binsor. After some time I had next solution for configuring two factories:

import Castle.Facilities.NHibernateIntegration
import Rhino.Commons
import NHibernate.Playground

facility NHibernateFacility:
    configuration:
        factory:
            @id = 'factory_1'
            settings(keymap):
                dialect = 'NHibernate.Dialect.MsSql2005Dialect'
                connection.provider = 'NHibernate.Connection.DriverConnectionProvider'
                connection.driver_class = 'NHibernate.Driver.SqlClientDriver'
                connection.connection_string = "Server=.\\SQLEXPRESS;initial catalog=test;Integrated Security=SSPI"
            assemblies:
                assembly = 'NHibernate.Playground'
    configuration:
        factory:
            @id = 'factory_2', alias = 'test2'
            settings(keymap):
                dialect = 'NHibernate.Dialect.MsSql2005Dialect'
                connection.provider = 'NHibernate.Connection.DriverConnectionProvider'
                connection.driver_class = 'NHibernate.Driver.SqlClientDriver'
                connection.connection_string = "Server=.\\SQLEXPRESS;initial catalog=test2;Integrated Security=SSPI"
            assemblies:
                assembly = 'NHibernate.Playground'

You can see here the XML way to configure NHibernate facility.