Archive for the ‘Code Performance’ Category

Subversion + .Net

July 21, 2006

I set up Subversion + continous integration (Cruisecontrol.Net) + testing (NUnit) + code analysis (NCover.Net) + VS2005 Subversion IDE integration on the weekend. Seems to be running pretty sweet. Why? Well its free – because I can 😛 – and its good to practise this stuff + I find on my little pet projects I seem to edit files and then sometimes need to rollback – now with some source control I can get back to where I was yesterday 🙂

I like the subversion model for editing files in a disconnected mode – makes it really good for working on stuff, when your out and about on some random machine, that may be offline for a while. Anyway, here’s all the bits that I used:

A 1 click subversion and subversion client setup:

or alternativelly: The main Subversion page: , and the TortoiseSVN install (subversion client):





Subversion VS IDE package: (this has a merge tool but maybe TortoiseMerge might be better – I havent checked it out…)

To get it all running I used the following in my ccnet server config (a snippet of the file):

<sourcecontrol type=”svn”>
   <executable>F:\Program Files\Subversion\bin\svn.exe</executable>
   <workingDirectory>F:\Program Files\CruiseControl.NET\server

    <executable>F:\Program Files\Subversion\bin\svn.exe</executable>
    <baseDirectory>F:\Program Files\CruiseControl.NET\server

    <buildArgs>checkout svn://ghost64/TestProject/trunk/ TestProject–username ccnetbuild –password *****</buildArgs>
    <executable>F:\Program Files\nant\bin\nant.exe</executable>
    <baseDirectory>F:\Program Files\CruiseControl.NET\server\TestProject\

     <file>F:\Program Files\CruiseControl.NET\server\TestProject\WorkingDirectory

     <file>F:\Program Files\CruiseControl.NET\server\TestProject\WorkingDirectory


I found I needed a task to pull the source and build it – the main source block didn’t seem to want to do it… I don’t know what that was about… anyway I just put in a task to get a working set and away it went. After that I had the main nant build task (where the build, tests, and coverage where run) and finally I merged all the results in :-). I edited the main environment path variable to include the paths to the nunit and ncover executables and then I could run the following from my nant file (actually this was in a batch file the nant script called out too – note TestLibrary was the name of the test project in the solution):

ncover.console nunit-console TestLibrary.dll //w .\TestLibrary\bin\Debug

By wrapping ncover around the nunit tests it has something to run against… you cant just run it against a raw dll – it needs something to be running the code – this way nunit will exectue the code so you can cover a dll.

Anyway, overall it seems to be running really well 🙂 Check it out some time!


March 4, 2006

The base for the dataset generator I released the the other day uses Sql SMO (the replacement for Sql DMO) to extract the bits and pieces it needs from the database (things like the table schema – What are the names of the columns?, What foreign keys are on a column?, Is the column a primary key? etc) Sql SMO in .Net 2.0 extents the meta data model exposed by Sql DMO and seems a little more intuitive to use. The problem was the dataset generator seemed a little slow at getting the job done – Was it the file access? Was it the string manipulation? Where was the biggest performance hit coming in? This can be very hard to find (you have to guess) and can waste a lot of time improving your program without a tool like a profiler.

The profiler I was using was the Jet Brains Dot Trace 1.1. This is a simple application which launchs your application and then monitors the calls that are going on and how long they take. The report it gives back allow you to drill down and find out what is really going on behind the scenes. The thing I really liked is that it doesnt really seem to interfer with the execution time of your program (not noticably) so it doesnt take long just to fire it up and check out whats going on. The little performance fixes here and there (these can be hard to do even with a profiler – but refactoring with tests should come in handy there 😀 ) can really make a big difference to how useful/good your final program really is 🙂 Its probibly something that a lot of people already know about but I just thought I’d mention it – If your trying to improve the perfromance of your .Net app then a profiler can be one really handy tool – Dot Trace seems to be a good one out there – I’d recommend it 🙂

With the dataset generator I found that the calls to Sql SMO get_Type() were causing the biggest performance hit (after removing a few obvious bits and pieces here and there). I did a few fixes but nothing too major – just not on the highest list of priorites at the moment – it did high light a few interesting bits and pieces in Sql SMO though.