I had an accident last week, my Vista hard disk crashed . Fortunately I didn’t lose any valuable (it has happened to me before so I now know better and keep backups of everything important) data but my Vista Installation was gone. So after getting a new hard disk and completing the system rebuilt I decided to import my Outlook data (yes I had a backup ;-) I only lost a day’s mail). When the restore process completed all of my mail and RSS Feed folders were successfully imported. Now I only had

I usually nag about VSS but VSS is not always to blame when issues arise.  In the old VS2003 days when someone created a new Web Project, a  project (*.csproj or *.vbproj) file was automatically generated storing information about your website, its references and any used binary files. Thus when you needed to use source control for your web site project files binaries (dlls) didn’t have to be stored as well. Using the new feature of file system based web sites, all project files are now saved in a plain file system folder and there is no project file defining the web site references.  The referenced assemblies are just saved in a special folder called “bin” and the compiler knows that it has to look in that folder in order to get the required assemblies and built the site.

That’s all fine when you reference assemblies that don’t change (already built dlls). In this case, you just add them to source control as well. After they will be needed if someone else downloads the site from source control in order to build it. The problem arise when you reference another library project in your web site.  In this case the library assembly gets copied in your web site bin folder each time you built your solution and assuming that you’ve already added your website to source control, it will show the just copied assembly as a file that needs to be added to source control. If you go ahead and add it you’ll have to check it out each time you build your web site. If you choose to let VSS complain about it (it really gets on my nerves) and decide not to store binaries in your source control database (as you’ve probably learned at school) then the you’ll certainly be able to build without vss prompting you to check it out, but any other user that downloads your web site project from source control won’t be able to built it because of the missing assemblies.

I’m curious, how are you handling this issue?

I don’t know how long it’s been since I wrote my last Data Access Layer or piece of SQL Code, it certainly has been too long to even remember. Since then I’ve used a number of ORMs (Object Relational Mappers) or/and DAL Code Generators to perform all the tedious data access manipulation  I needed.

The ones I’ve used are
LLBGen : Unfortunately this free version stop evolving a long time ago (since .Net framework 1.1) and became a commercial solution,
Olero’s  ORM.Net : Which was my favorite Open Source (GPL Licensed) ORM, although it didn’t support Generics and all the nice stuff .Net 2.0 brought us.

Lately though I’ve been experimenting with SubSonic the zero code DAL as they call it and I must say I was Impressed with its simplicity, flexibility and extensibility. At last this open source ORM supported Generics and it was designed with .Net Framework 2.0 in mind. Then only problem was that it supported only ASP .Net 2.0 applications when I needed something that would not only be useful for Windows Forms Applications but something that could be used on Windows Presentation Foundation applications as well [with little or preferably no modifications].

So after studying and re-engineering the code, I’ve created a “fork” on Subsonic ‘s releases that will not only support Windows Form Applications but also the new INotifyPropertyChanged interface and ObservableCollection class of Windows Presentation Foundation so that I can easily bind data objects to my WPF forms.

I now have to do some testing before publishing the code and Officially announcing the release (using project’s codeplex space), so stay tuned if you’re interested…