I've been looking for a basic .net data access layer for some time. I didn't want all the overhead of a full blown ORM framework like NHibernate, or Entity framework, but I wanted to get rid of all the messy boilerplate needed to use a database. Allso, It needed to support Mysql 4.0 (!). MySql 4.0 is fairly ancient tehnology, making my search rather difficult.
I ended up writing my own simple layer to suit my needs for the project I was working on.
It worked, but it was not elegant, and just slightly less painful to work with than plain ADO. Also, it required another kind of boilerplate code, as it was based on pre-defined data classes.
After spending too many hours on reinventing the wheel and several subsequent technologies, I stumbled over the Simple.Data library by Mark Rendle (@markrendle - http://blog.markrendle.net/)

-Basic COM interop

I spent a lot of time with my first interop project going through all the resources I could find on the subject. I found that many of the articles I managed to dig up did not cover the basics needed to get a simple ineterop project up and running.
Another lack in the existing library of interop articles is the bias towards writing articles describing the consumtion of COM libraries from .Net. My need has allways been the other way around: consuming .Net assemblies from VB6.
The best guide I found where a 15 seconds article by Patrick Steele: COM Interop Exposed. This article adressed most, if not all, of the issues i ran into with my first interop project. It also goes through the background needed for someone not previously exposed to the COM way of thinking to understand enough of what's going on behind the scenes.
My goal for this article is to make a basic step by step guide on getting the very simplest interop project up and running in your development enviroment.

Today I ran two rounds of deployment of to our production servers. This led me to start pondering a blog post on the strategy we've chosen to make this as painless as possible.

Our operational requirements demands that deployment of new versions is done continuously, without downtime, while our users are actively using the software.
As long as the deployment environment is controlled, .net applications can be xcopied directly, with no extra steps. But our application is a mix of .net and legacy VB6 components. This mix would lead many to believe that registration in the registry is unavoidable, which could lead to DLL hell.

But there is a solution: