NUnit 2.5 GUI cannot locate iBatis.NET sqlMap.config

NUnit 2.5 was released last month introducing a large set of new functionality into the NUnit framework. If you are using an earlier version of NUnit today, take a look at the following new features released in 2.5:

  • Parameterized, data-driven tests
  • New constraints
  • New asserts
  • Theories
  • Distributed parallel tests
As in previous versions, NUnit 2.5 allows running tests from multiple assemblies by using NUnit test project files. We find a lot of value in using these files on local development workstations. However, our automated build and continuous integration server, TeamCity 4.5.1, does not support NUnit project files and requires all test libraries to be listed manually. As a result, TeamCity executes tests with the value of AppDomain.BaseDirectory set to the location of the executing assembly. While we used to be able to configure the same behavior in previous versions of NUnit, NUnit GUI 2.5 no longer updates AppDomain.BaseDirectory at the assembly level and is likely to fail your unit or integration tests when they rely on the AppDomain.BaseDirectory value.

We came across this issue while upgrading our persistence tests. When iBatis.NET Data Mapper was used, tests succeeded on the build server but failed locally (could not find sqlMap.config or properties.config). I looked into the iBatis.NET 1.6.1 source code and noticed that the framework uses AppDomain.BaseDirectory to load its configuration files. To fix the problem, update AppDomain.BaseDirectory to the location of the executing assembly before creating the iBatis.NET Sql Mapper:

var  assembly =  Assembly.GetExecutingAssembly();
var  applicationBase = assembly.CodeBase.Substring(0, assembly.CodeBase.Length - assembly.ManifestModule.Name.Length);
AppDomain.CurrentDomain.SetData("APPBASE", applicationBase);

Contact us if you are interested in upgrading your applications to NUnit 2.5 or configuring them for TeamCity. Happy coding!

iBatis.NET DataMapper 1.6.1 does not support default parameters in stored procedures

iBatis.Net DataMapper is our de facto standard for implementing persistence in .NET applications. The framework works well with an object-oriented domain model and relational data store.

Today, we stumbled upon a bug in the latest production release of iBatis.Net DataMapper. A new parameter was added to the existing stored procedure and although this parameter came with a default value, the application threw the following exception: 
"Specified argument was out of the range of valid values. Parameter name: index" from IBatisNet.DataMapper.Configuration.ParameterMapping.ParameterPropertyCollection.get_Item.

One way to work around this issue is to replace the original procedure configuration:

  <procedure id="OurStoredProcedure" parameterMap="OurStoredProcedure_Parameters" >

   <parameterMap id="OurStoredProcedure_Parameters" class="OurParametersClass">
     <parameter property="Value1"/>
     <parameter property="Value2"/>

with a dynamic statement:

  <statement id="OurStoredProcedure" parameterClass="OurParametersClass" >
    EXEC up_OurStoredProcedure #Value1#, #Value2#

Happy coding!

Welcome to ModelBlog

Thank you for visiting ModelBlog. We hope the time you spend with us will be both entertaining and worth your while. Have fun!