Our blog feed has changed

As part of the BlogEngine.NET upgrade, we started using Feed Burner to syndicate our blog feed and better understand our subscribers. Special thanks to Bob MacNeal for recommending Feed Burner.

If you subscribe to our blog, please update your link to  http://feeds2.feedburner.com/ModelusBlog. Our old link will continue to function for a few more months. Let me know if you have any questions. Thank you.

We have updated our blog from BlogEngine.NET 1.3 to 1.5

Please let us know if you see anything unusual on the site. Thank you!

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:

<statements>
  <procedure id="OurStoredProcedure" parameterMap="OurStoredProcedure_Parameters" >
    up_YourStoredProcedure
  </procedure>
</statements>

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

with a dynamic statement:

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

Happy coding!

How to automatically fail TeamCity 4.0 build when MSTest 2008 webtests fail

Out of the box, there are two options to configure MSTest 2008 webtests with TeamCity 4.0 build server. The first option is to add webtest names to the MSTest assemblies list. The second option is to specify MSTest configuration and .vsmdi metadata files. In both cases, TeamCity 4.0 does not fail a project build when webtests fail. Nor does TeamCity display webtests results as it does for unit tests.

To solve this issue, we created a custom command-line file to execute MSTest webtests:

set ConfigPath=<Path to your webtest configuration and .vsmdi files>
set ResultPath=<Path to .trx and .txt result files>
set MSTestPath=<Path to your MSTest.exe>

"%MSTestPath%\MSTest.exe" /runconfig:%ConfigPath%/Your.testrunconfig
/testmetadata:%ConfigPath%/Your.vsmdi
/resultsfile:%ResultPath%\Your%1.trx >> %ResultPath%\Your%1.txt

if not %errorlevel% == 0 exit 1

This file takes a build number as the first positional parameter, executes webtests listed in Your.vsmdi, and saves .trx result file as well as the execution summary report so that TeamCity could store them as build artifacts. We then configured a dependent build configuration to run this command-line file as part of our build process.

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!

Authors

Search

Archive

Tags