Click here to Skip to main content
15,900,461 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
Hi all,
I have a question about how to handle database dependencies in 'generic' dll's.

For example, I have written a dll that logs exception information to a database. We want to use this functionality for multiple customers.
Now let's assume I have used this functionality for customer A and a colleague has used it for customer B. The first setup is easy. Run a database script and use the dll in your code. The dll will then write to the database.

Now for customer A I make some changes to the database schema, let's say I log some extra information. Now when my colleague goes to work for customer B (perhaps a few months after I made the changes!) his software will crash because the new columns are not in his database. In a worst case scenario he forgets to update the database of customer B and the code will crash in production (shame on my colleague, but he may not be aware of any database changes at all).

What is a good way to handle this?
Should I have a database script for version 1 of the dll, version 2 of the dll (that also includes version 1 if it is not yet installed) etc.
Should I check if a table and record specifying the use and version of the dll in the database and show an error when it is not present?
Is there some kind of tool that can easily keep seperate versions of the dll with the corresponding database scripts?

Does anyone have a good solution for this that doesn't require every user of the dll to be aware of database scripts and changes?
Perhaps built-in solutions, programmable solutions or third-party solutions?

The database(s) I'm using are SQL Server 2005 and higher and the software is .NET4 (both VB and C#) in Visual Studio 2010 (we might switch to a newer version soon).


1 solution

What you are talking about is software versioning, and it's part of a very big topic - release management. Whole books can be written about this area.

So, the big question is, are there any simplistic ways of achieving this? The answer is yes, but it requires you to put quite a bit of infrastructure in place in your DLL right from the start. The first thing you need is a way of recording what version your DLL is currently at in the database. A simple table will usually suffice here consisting of a string containing the version. When your DLL is invoked, the first thing any method in it has to do is check to see what the version is in the database. If that version is less than the current version, then you need to apply your scripts to update the database in the correct order.

Fortunately, actually writing this infrastructure isn't that complicated.
Share this answer
Sander Rossel 15-Jan-14 7:12am    
Thanks for your answer.
That sounds reasonable. So in a call to my dll I do the following:
1. Check if our software version table is present in the database.
2. If it isn't create it.
3. Check if the record for the current dll + version is in the table.
4. If it isn't create the record with the correct version and put all database infrastructure for the dll in place.
5. If it is present, but the version is out of date update the record and update the current database infrastructure for the dll.
6. If it is present and up to date, do nothing.
Those steps should ideally be handled by a seperate dll that can perform those steps for every dll that needs a specific database infrastructure.

Speaking of release management, do you know any good books I should read?
So far our company has been manually copying dll's to our customers computer and so far this was never a problem.
More recently our company started to embrace more object oriented principles and we now split common functionality in dll's for re-use.
Unfortunately our release 'strategy' is not always suffient anymore and we need a more structured and automated approach.
If you know of some good book(s) I'll certainly look into it in more detail.
There are more aspects that could certainly use improvement (even though they aren't a problem yet).
Pete O'Hanlon 15-Jan-14 8:40am    
Depending on how much buy in you can get from management, you could go with this book: The big thing with release management is that it requires buy-in from all levels. It's worth pushing to get it done though. Managing it is a full time job which is why I have a release manager.
Sander Rossel 15-Jan-14 9:51am    
Thank you Pete. I'll discuss this with my managers and see if this will help me and the company.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900