Just released the all new Atom Publishing Protocol server library for ASP.NET.
Here's the background story:

Windows Live Writer is a wonderful application for writing blog posts.

It provides a much nicer editing experience than web-based HTML editors, and it is especially good at handling inserted images.
I have often wondered if there was some way to use WLW to edit news articles on our various web-sites (different home grown ASP.NET based systems) and/or use it for more general CMS purposes such as editing knowledge base articles and other web-pages.
Googling for ways to use WLW with ASP.NET did provide a few hints, but I couldn't find any ready-to-use components or complete code samples for this. So this weekend I set out to figure it out.

WLW supports a number of different "blog types":

However only one of these is based on RFC standards - the "Atom Publishing Protocol" - a.k.a. "AtomPub".
I am very much in favor of open standards, so I quickly decided that this was the way to go.

Chris Sells suggested creating an AtomPub server using WCF Data Services. However I felt that I needed something more flexible and "lightweight" - not tied to a specific database etc.

Our various web-sites have very different structures, use different background database layouts, are in different stages of development, etc. (but at least most of it is ASP.NET by now).
To make a "drop-in" AtomPub component that would work with all of this, it would have be to very flexible, especially in regards to data storage.
So I decided to make a library which handles all the AtomPub communications stuff (talking to WLW), but leaves the data storage and retrieval details up to each web-site using the library. Basically each web-site will have its own .NET classes which inherit from classes in this library and override methods to store/retrieve data.

Because the AtomPub protocol uses HTTP "PUT" and "DELETE" methods (to update and delete resources) and these methods by default are not handled by standard .aspx pages or .ashx handlers, it made more sense to implement the library as a custom handler (based on IHttpHandler) registered in the site's web.config file.
The PUT/DELETE methods also turned out to conflict with WebDAV - more details about this on the library home page (see link at top).

Putting everything together took a few days, but following the RFC documents, implementing the actual protocol was pretty straight forward. I used the standard .NET XML library and some simple string manipulation to parse and format the Atom XML messages, and the standard ASP.NET libraries to handle Atom related HTTP request and response headers.

The library works great with WLW and we are certainly going to continue implementing it on our various web-sites, making publishing news and other content easier and nicer going forward.

I am releasing this library to the public as freeware (see link at top), hoping that other ASP.NET developers might find it useful as well.

Just noticed that my favorite add-in for VS2005, Smart Paster by Alex Papadimoulis, is now also available for VS2008.

With this add-in you can paste text from the Windows clipboard into the Visual Studio source code editor formatted as a comment, quoted string, or string builder code just by right-clicking and selecting "Paste As..." from the pop-up menu:

This is just a fantastic time saver.

However the VS2008 version of the add-in only came as source code and had no instructions for installing it.
So for anyone else looking for this wonderful add-in, here's the compiled version:
SmartPaster2008bin.zip (27.13 kb)

To install it, un-zip above to:
Vista/2008: C:\Users\<user-name>\Documents\Visual Studio 2008\Addins
Earlier Windows: C:\Documents and Settings\All Users\Shared Documents\Visual Studio 2008\Addins

Then restart Visual Studio 2008 and update settings for the Add-In in the Tools menu / Add-In Manager.

I am attending Microsoft's TechEd Developer conference in Barcelona this week (and having a great time).
One of the more interesting things (to me) that Microsoft is showcasing this year is a new product for ISVs called "Software Licensing and Protection Services" or "SLPS".
There has been 2 "breakout sessions" on SLPS, there are signs, flags, and posters advertising SLPS everywhere, and there are more "ask the experts" stands about SLPS than any other single topic here.

SLPS is a very interesting anti-cracking method involving a "unique virtual machine permutation" for each ISV or software title combined with a typical license activation server or service. For details see http://www.microsoft.com/slps

It seemed like a great product for a small ISV like us, and so I spent some time digging into this subject here at TechEd.
Microsoft sells SLPS through various resellers including PreEmptive - who combines this with their DotFuscator product.
PreEmptive also has a stand at the TechEd, and they offer a "challenge" where they add SLPS (and obfuscation) to an existing .NET executable to demonstrate how all this works.

PreEmptive gave me a very nice walk-through using one of the .NET based .EXE modules from our upcoming Simple DNS Plus v. 5.0.
The protected / license wrapped version worked very nicely during the demo on PreEmptive's computer, and following the demo they e-mailed me a copy of this to try on my own computer.
Unfortunately it did not work as well when I downloaded the file to my laptop later that evening - basically it just crashed.

This morning I attended another session about SLPS by Aidan T. Hughes (Development Manager for SLPS at Microsoft), and later in the day got a chance to talk to him personally about this - and show him the application crashing on my laptop.
It turns out that SLPS only works with 32 bit processes!
Since my laptop runs 64 bit Vista, and the .NET application was originally compiled for "Any CPU", it runs as a 64 bit process.
This worked just fine before SLPS was added. But with SLPS it crashes because it cannot load the 32-bit-only SLPS DLLs into the 64 bit process.
Quoting Aidan: "We haven't gotten many requests for 64 bit support, so this is not something we have tested a lot..."
Unfortunately he didn't give me much hope that this would be fixed in the near future - "we will look into this for future versions...".
His only suggestion was to re-compile the application for 32 bit (x86 CPUs).

Unfortunately that is a showstopper for us.
Many of our users have been asking about 64 bit for some time now.
All new CPUs from Intel and AMD are 64 bit capable (both companies have stands at TechEd and I checked with them both) and Microsoft's own flagship product Window Vista comes with both 32 and 64 bit versions in the same box.
So I am surprised that Microsoft would launch this new product without 64 bit support.

That said, I would like to thank the staff at PreEmptive and Microsoft's SLPS group here at TechEd for their great help and personal attention to this.

We are just about ready to release the very first beta version of Simple DNS Plus v. 5.0.

That means that a lot of compiling, installer building, and testing is going on at the moment.
All in all, getting from source code to a complete "setup.exe" file involves 30+ steps of doing different things in different programs (compiling, obfuscating, packaging, signing, virus scanning, etc.) - all of which has to be repeated over and over as we correct bugs and fine tune everything.
Until yesterday this was a manual and painfully slow process.

Today I discovered "Visual Build Professional" from http://www.kinook.com

After playing with the trial version for only a few hours, I had our whole build process completely automated.
I just placed an order for the full version - this software program will save us so much time in the next critical beta testing period that it will pay for itself ($300) many many times over!

I know there are other automated build tools out there, but what really sold me on this one is that it has direct support for exactly the tools we use to build Simple DNS Plus v. 5.0:
- Visual Studio 2008 Beta 2 (http://www.microsoft.com/vstudio)
- Dotfuscator Professional Edition (http://www.preemptive.com)
- Advanced Installer (http://www.caphyon.com)
- Help & Manual (http://www.helpandmanual.com)

I was even able to include an automated a virus scan of each compiled .exe file and the final setup.exe via the command line tool that comes with Kaspersky Anti-Virus (http://www.kaspersky.com).

So now when we make a small change to the source code, we can then compile and package a new setup.exe file, and upload it to the web-server in just one step!!

The build process is of course only the final step - a number of other tools also play significant roles in creating Simple DNS Plus:

- SandDock (http://www.divelements.co.uk) - dockable/tabbed windows.
- dotTrace Profiler (http://www.jetbrains.com) - for profiling/optimizing.
- FogBugz (http://www.fogcreek.com) - for tracking bugs/ideas/suggestions.
- Axialis IconWorkshop (http://www.axialis.com) - for converting/creating Vista ready icons.
- Hexago / go6 client (http://www.go6.net) - for testing IPv6 features.
- SyncBackSE (http://www.2brightsparks.com) - for synchronizing folders and uploading websites.
- Mozy (http://www.mozy.com) - continuous remote backup of irreplaceable source files.
- Paint Shop Pro (http://www.corel.com) - my favorite imaging program.
- VMware Workstation (http://www.vmware.com) - for testing on different platforms.
- Reflector (http://www.aisto.com/roeder/dotnet) - for fine tuning .NET code.

We have tried many different tools in all these categories over the years, and I can highly recommend all of the above over any competitors that I know of.

For more on Simple DNS Plus v. 5.0 see http://www.simpledns.com/v50beta.aspx

Several new features in Simple DNS Plus v. 5 require a new way to store the DNS zone list on disk.

Previous versions use a standard DNS "boot" file – a plain text file listing each zone line by line.
This format is very simple for anyone to read and update, which is why we have stuck with it this long.
Version 5 however needs to store additional information for each zone and update this much more frequently, making a different storage form necessary.

All the data from the "boot" file is actually cached in memory while Simple DNS Plus is running, so theoretically we could just read in all the data at startup, update the data in memory while running, and then save it all back to a file at shutdown. Only problem is if the computer shuts down unexpectedly (looses power), then the latest changes would not be recorded, leaving a mess.
So we need an efficient way to keep a continuously synchronized copy of the data on disk.

Using a full scale database system such as MySQL or Microsoft SQL Server would be overkill for this.

I spent a few days evaluating lightweight embedded database systems (see previous blog entry), but ultimately decided that this was too slow and added too much overhead and complexity as well.

The solution I eventually came up with was a simple proprietary file structure specifically shaped around the unique data of the DNS zone list with a few design ideas borrowed from xBase.
We’ll call it the "Simple DNS Plus Zone Database" file format – or ".sdpzdb" files.
Simple DNS Plus will store the file position of each record (zone item) in memory eliminating the need for database indexes, and making updates/deletes extremely efficient.

While this provides a lot of benefits, there is one major downside; since the new file format is binary, it can’t just be opened and edited with notepad like the old "boot" file.
We believe that was an important "feature", and so we will do what we can to make it easy to work with the new format as well.

For starters we have put together a small "Zone Database Viewer" application to quickly browse the data.
This can also export the data to the old "boot" file format or a CSV file.

And we plan on providing a .NET library to access the file as a standard "system.data.DataTable" object.

One remaining issue we have to deal with is concurrent updates to the database from different processes. Both the GUI record editor module (editrecs.exe) and the main server module (sdnsmain.exe) can update the zone list – potentially at the same time.
We can solve this either by using file locks, or possibly having all updates go through the main server module. The later would turn Simple DNS Plus into a simple database server, which may open up some other interesting possibilities…
We haven’t decided which way to go just yet. 

I spent the past few days evaluating different embedded database system for possible use in the upcoming Simple DNS Plus v. 5.

Simple DNS Plus v. 5 will be .NET based, so my first requirement was that the database system had a .NET API or data provider.
Ideally it should run on both 32 and 64 bit Windows versions and under MONO on non-Windows systems (Linux, MacOS, Solaris, etc.).
And of course it should be fast and small as possible.

I looked at the following options:

1) Microsoft SQL Server Compact Edition (MS SQL CE).
(http://www.microsoft.com/sql/editions/compact/default.mspx)

At first this looked like the obvious choice since it is practically part of the Visual Studio toolbox (or will be in Visual Studio "Orcas").
However, at this time there is no 64 bit version, which would also prevent Simple DNS Plus from getting certified for Windows Vista (see http://channel9.msdn.com/ShowPost.aspx?PostID=312747).
And from what little information I can find, Microsoft has not committed to a 64 bit version in the "Orcas" timeframe either
(see http://blogs.msdn.com/stevelasker/archive/2007/01/16/sql-server-compact-edition-3-1-released.aspx#1753365)

Of course being win32 code it probably doesn’t run on non-Windows systems.
2) VistaDB
(http://www.vistadb.net)

This database system is a 100% .NET managed code DLL which can be linked directly into another .NET assembly. So this is truly an "embedded" database system.
The same code runs on both 32 and 64 bit – and even on non-Windows systems (under MONO).
The downside is that this is rather slow compared to the other database systems (according to my own simple speed tests), and the documentation is not great.

3) SQLite
(http://www.sqlite.org and http://sqlite.phxsoftware.com)

This was significantly faster than both MS SQL CE and VistaDB.

For .NET development, this is available as a hybrid DLL containing both the native code SQLite engine and the .NET provider.
Because of the included native code, there are separate DLLs for win32, x64, Itanium, and .NET compact which makes the total distribution size significantly larger than the other database engines.

A potential issue is that it has no type safety. Anything can be stored in any column.

I imagine the hybrid DLLs cannot be used on non-Windows systems, but the SQLite engine itself is available for many operating systems and as C source code, so there is probably some way around that…

4) Codebase
(http://www.codebase.com)

About 10 years ago I used this database engine to build a larger invoicing system with VB3 16 bit.
It was VERY fast back then and still is today.
It uses xBase data files which explains the speed (very simple and efficient file layout), but also why the data file becomes very large (data fields are padded to maximum length).
It has a .NET API but is itself native code. I am not sure if it works under MONO.

5) Firebird
(http://www.firebirdsql.org)

I didn’t actually get around to testing this, but wanted to mention it because it looks like another good option.
It has a .NET data provider but is itself native code. I am not sure if it works under MONO.

And the winner is… none!

Basically they were all just overkill for what I needed.
Had I chosen one, it would have been either VistaDB because it best fit my requirements or SQLite because it was very fast.

Instead of a database I ended up using a "homemade" highly optimized proprietary file structure.

A quick comparison of inserting 150.000 random records (representing 150.000 DNS zones):

VistaDB:
2 minutes

MS SQL CE:
1 minute

SQLite:
25 seconds

"Homemade":  
1/3 second (yes, one third of one second)

And the resulting "homemade" file was significantly smaller than any of the database files.

Read more about the "homemade" file structure here...

We will be releasing a new Simple DNS Plus API for .NET and COM this coming week - watch our company blog/RSS for the announcement.

We were actually pretty close to releasing something very similar for COM about a year ago, but that project was eventually scrapped for several reasons.
Primarily we were stuck with the API documentation because this could not be automated, but around the same time we were also shifting our focus to the .NET platform and therefore knew that we would not maintain this project going forward anyway.

So this time around we wanted automated documentation from the beginning.
The solution turned out to be Microsoft's "Sandcastle" project (see http://www.sandcastledocs.com and https://blogs.msdn.com/sandcastle) along with SandcastleGUI (see http://www.inchl.nl/SandcastleGUI).
This combination makes it real simple to convert XML comments from .NET source code into a real .chm help file and matching web version.
Check out the (preliminary) API documentation at http://www.simpledns.com/apihelp
Sandcastle is still in beta but works pretty good already.

Then it came time to package the first alpha version of the new API.
We have been using InstallShield to build installers in the past, but were not real happy with it and therefore haven't upgraded it for a while.
I thought we were going to be using the deployment functions in Visual Studio 2005 which is much improved compared to earlier Microsoft offerings, but we still ran into some issues.
When distributing software over the Internet, I believe that this should be done with a single self-extracting, self-installing, and signed .exe file.
Unfortunately there is still no way to create such an installer in VS2005.
Luckily the Windows operating system conveniently ships with "IExpress" which can package the install files from VS2005 just like I wanted, and the resulting .exe file can then be signed manually with the SDK tools.
BUT - it turns out that packages created with IExpress on Windows Vista do not work on Windows 2000, and packages created with IExpress on Window XP act weird on Windows Vista...

So it was time to look for alternatives - and I found a great one in "Advanced Installer Professional" (see http://www.advancedinstaller.com).
With this tool it is much simpler to configure the installer project, it can package everything into one .exe, and it can automatically sign it.
And I really like the way it automates downloading of prerequisites such as the .NET Framework.
I highly recommend it!