TrialBalance Update
I had an old desktop at home that I hadn’t used for a while, so a few months ago I decided to convert it into my own Team Foundation Server machine. It’s running the Workgroup edition of Team Foundation Server in single-tier mode, and I’ve been using it to store the code for TrialBalance and other personal projects since I set it up.
Yesterday I spent the day working on TrialBalance, and I reckon I accomplished quite a bit:
- I setup Readify’s TFS Integrator on my server, and got it building TrialBalance.
- I hooked the TrialBalance build up to the TrialBalance website builds page, using the steps I outlined in my TrialBalance Build System series.
- I changed TrialBalance to use .NET 3.0’s System.IO.Packaging namespace instead of Microsoft Access as the data store. TrialBalance now stores its data in “.TBDX” files, which you can rename to a “.ZIP” and look at how they’re structured.
- I re-wrote the way accounting transactions work, so that instead of storing both the debit and credit account for a transaction, it only stores the “parent” account (the account who’s ledger the transaction appears on) and a text description for the other account. This allows users to make mistakes just as they would with paper-based systems, which is in line with the major feature I’ll be adding: tests and exams.
- I added some advanced change auditing code to the domain model. Now, if a user changes an account or transaction, TrialBalance will record: who changed it, what properties were changed, what they were previously, what they were changed to, and the date of the change. I want to blog about this one in detail, because I think it’s a fantastic example of why a rich domain-model kicks ass over generated code.
- I created an installer using Inno Setup, and also publish it as part of the continuous build.
One of the things that kept me from using Inno Setup in the past with TrialBalance was that I wanted to warn users if they didn’t have .NET 3.0 installed, and download it automatically for them. I did a little digging around, and bumped into a code segment you can add to the bottom of your Inno Setup script that does exactly that:
http://discuss.joelonsoftware.com/default.asp?biz.5.402705.9
The code above only checks for .NET 2.0, so I modified it to check for .NET 3.0. I found a blog entry by Aaron Stebner from Microsoft that states what registry keys to check when determining the presence of .NET 2.0:
http://blogs.msdn.com/astebner/archive/2006/01/15/513125.aspx
As I couldn’t find an officially supported way of checking for .NET 3.0, I used the following registry key which seems to work for me:
HKEY_LOCAL_MACHINE\Software\Microsoft\Net Framework Setup\NDP\v3.0
If you know a better way to check for .NET 3.0 I’d love to hear it.
Filed under: Trial Balance

Paul,
Thanks very much for sharing your work and experience here. I found it really useful.
I am a technologist. I am developing a product which will eventually need ‘revenue life cycle’ feature. While seaching related topics (Open source i.e FREE), I came across your trial balance application. I do have the following questions. I hope you will kindly respond.
1. How much work is needed to change this prototype and be able to use track revenue life cycle.
2. I am not sure about what made you not use some version of SQL Server. If I need to this for some commercial purposes, data need to stored in some kind of database. What is effort involved here?
Again, thanks for sharing your work.
Hi Paul,
There is a .NET Framework 3.0 deployment guide at http://msdn.microsoft.com/en-us/library/aa964978(vs.85).aspx that describes how to detect whether or not the .NET Framework 3.0 is present on the system. The exact key/value you want to use is the following:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.0\Setup]
InstallSuccess=1
I’ve also posted some sample code that demonstrates how to detect the install state and service pack level of various versions of the .NET Framework. You can find more info about it at http://blogs.msdn.com/astebner/archive/2007/11/29/6608419.aspx.