In case you aren't familiar with it, VistaDB is a lightweight, embedded database engine written entirely in managed code. It is a fantastic product that is coming on in leaps and bounds. Their aim is to be fully SQL compatible with SQL Server and are even adding support for TSQL.

I've used in on a few of my own projects and have been very impressed (I have a forum application with a 4Gb SQL Server database and approximately 2.5 million posts that I have just started converting to use it).

Even if you decide that you don't need it though it may still be worth looking at for testing purposes.

The client project I'm currently working on uses NHibernate for the persistence layer. Having developed an NHibernate Dialect and Driver for VistaDB (which I need to publish!) we've been able to use this when running unit tests. Instead of having to setup databases we can just create an in-memory database for use by the unit tests which is destroyed when they are finished. It is quick, convenient and avoids a lot of dependency issues PLUS it runs Linux / MONO (our app is cross platform).

The current project that I am working on has experienced a few problems recently where developers have made changes to the build files (such as adding assembly references) but not the Visual Studio project files or vice versa which results in the rest of the team coping with a broken build or a solution that appears broken when first opened.

While the obvious and probably most common solution would be to use the Visual Studio definition of the projects as the master and create the build file from that (or use MSBuild directly) we do have some added complications that prevent this approach:

• The application is cross-platform and has to run on Linux / MONO as well as Windows / .NET
• There are C#, C++ and FORTRAN modules in the application (scientific computing)
• Some developers work on Linux and do not want to use Visual Studio

I have evaluated and had some success with the Prebuild project which lets you define all the project settings and dependencies in an Xml file (which isn't too dissimilar to the Visual Studio format but is probably 'politically acceptable'). From this Xml file the tool generates the Visual Studio solution & project files plus the (NAnt) build files. It can also generate Mono Develop or Sharp Develop projects for use on Linux to keep everyone happy.

While it's a great tool there are a few things I don't like - I wish you could define your own templates for build files instead of being forced to use the one provided (although you can change the source to alter what it generates). Also, it doesn't directly support the build tool we are using (SCons) but I'm hoping we can switch to using NAnt at some point to fix some other issues.

It does address the main problem though - ensuring that there is only one 'truth' and a single way to add project references (in the Xml file). Adding it to the build files or the project files directly is pointless as they are both generated as part of the build process (which will then fail if the Xml definition is wrong).

Also, it's quite nice to just have source code checked into the repository ... no build files, no solution, no projects. Everything is created as needed which may also help as the team migrates to VS.NET 2008.

Let's face it, the evidence is that Phishing works and that there is little the banks and other sites can do because anyone can setup a site that looks like another one and lure users to it.

Banks will obviously do what they can to shutdown phishing sites but they only need to stay alive for a short while and fool enough customers to make it worthwhile and it is obviously worthwhile because they keep doing it.

So, the answer is to make it *not* worthwhile.

Someones bank account details with logon information is a valuable commodity and can no doubt to sold or used directly.

What would be less valuable and less use to a phishing site owner is a list of millions of false accounts. Would they be able to sell 10,000,000 useless accounts that perhaps had a few genuine ones sprinked in it?

Perhaps when a phishing site is discovered the banks could deluge it was false account logons thus making the captured list of data practically worthless and adding to the time and effort required to copy the list around.

Would this work? I don't see why not.

Another benefit is that the bank could use the fake account logon information to detect attempts to logon to the accounts and potentially trace the people using the information illegally.