Over the last couple of weeks I’ve been getting several questions regarding the fact that West Wind Html Help Builder is written in Visual FoxPro. This is in light of a bunch of .NET people finding this product for the first time…

The question invariably comes down to: Do you have a .NET version of Help Builder. I’ve answered this with the same response for quite some time: NO! My counter question is: Does it REALLY matter?

Parts of Html Help Builder of course already utilize .NET. The VS.NET add-in functionality is pure managed code that interops with Html Help Builder via COM. All the .NET import features use .NET Reflection also via Interop and a wrapper assembly that collects all the data and provides an easy COM interface for VFP, so the key places where it counts Html Help Builder can already take advantage of .NET features where applicable.

You might ask why I haven't re-written Help Builder, given the fact that I’ve been spending considerable time in .NET over the last year and a half. The answer really boils down to three things:

• Return on investment
• Benefit of a conversion
• Technological issues

The fact is I would LOVE to spend time to re-build Help Builder in .NET, because it would be challenging and interesting process. It would be a great project and there would be opportunity to clean up some internal designs as well as giving the product a more up to date user interface. But it would take a significant chunk of time to do this with practically no return of investment. Help Builder includes a ton of internal knowledge and interfaces with a large variety of external tools and re-writing and re-testing this codebase is not a trivial process. The time spent on re-write could be spent much more productively on feature enhancements and other priorities.

Ultimately Help Builder is a very capable product in its current state and there is no significant technical reason to move it to .NET other than to satisfy anybody who ‘wants nothing to do with Visual FoxPro’. Please. From a technical perspective there’s very little that .NET would offer this application that can’t be done in the current environment. The one minor exception is the user interface which could use an update (it’s stuck with MSCOMCTL32.OCX which has never and probably never will be updated to support XP Themes and a DataDynamics Toolbar control that also is also not themes aware).

I have considered it in the past, but there are also a number of drawbacks of why I decided not to go down that road.

What Database to use?

If you build a general purpose vertical application what database do you use?

SQL Server/MSDE? I don’t think so. The focus of .NET is obviously for the Enterprise where SQL/MSDE isn’t a problem but for single desktop applications that need a local database MSDE is just not an attractive option. Administration of a MSDE requires Admin privileges for one and while the process can be automated users can not easily access the data directly if necessary. So much for a self-contained project for example. Further MSDE is HUGE. For a downloadable product MSDE/SQL is not an option. Granted for Help Builder that may not be a huge problem as most developers likely have an installation. But how about the question to provide a connection string to the database so you can create a new database? Developers *may* know what to use for this, but what about an technical writer? Or a simple user (in a more ‘desktop oriented’ application)?

Using the Visual FoxPro OleDb provider also is not a good option given the problems with the driver in the .NET environment and the inability to efficiently administer databases through it (you can’t build or rebuild indexes through it for example).

MS Jet? Too slow, even for a relatively small set of data (a few thousand topics is probably a large help file), but the data needs to be efficiently searchable. And Jet data tends to corrupt easily as well. Jet is also no longer part of the ADO distribution and makes up a large download as well.

I think this is actually major market miss for Microsoft. Microsoft out of the box has left me no decent database choices for building a relatively small PERSONAL vertical application. I can use a third party product like Apollo for .NET or VistaDB which I haven’t time to look at. VistaDb sounds interesting…

Windows Forms Problems

.NET Windows Forms are slow in the current version of .NET. Rebuilding an application and ending up with something that is slower is not an option. Visual FoxPro has its UI quirks and is no speed demon, but .NET is much worse in this respect. More flexibility for sure, but there are many, many issues. For more info on what I’m talking about see this earlier post.

Technical Issues

Yeah some people may scoff Visual FoxPro but there are a number of things that Help Builder currently does that is very slick including the fully template driven output generation that allows you to run code dynamically. This is a fully integrated process that allows ASP like code to run in pages.  You can do this sort of thing with .NET using the ASP.NET runtime, but this process is very overhead intensive and prone to .NET version conflicts (witness the current mess with Whidbey Betas breaking many applications that use the ASP.NET runtime). Possible, but possibly problematic – a large technical risk.

The Help Builder Automation interface is externally exposed via an EXE COM server. .NET cannot easily create an EXE COM server at all. You can create COM objects even with UI with .NET but this is pretty non-standard for an Automation model and it also causes lifetime issues since you cannot truly unload a .NET COM object loaded into another process. Some of this could be made up by providing a managed interface instead so direct integration with .NET would be possible. However, COM actually offers better options here since you can create COM interop assemblies from the type libs, but not the other way around.

Help Builder is heavily meta data driven internally and this sort of thing is much more difficult to do in .NET than in Visual FoxPro. Some of the dynamic runtime evaluation features would simply not be possible in .NET at all and require a redesign or need to be left out.

Further Help Builder currently provides features to VFP developers as well as .NET developers. The VFP features could not be implemented in .NET and would require that VFP is still available to do interop the other way around from .NET into VFP. No big deal but ends up creating an external dependency.

The technical issues are not insurmountable but they would require a fair amount of tweaking and testing, R&D. Combine this with some of the complete re-design issues to duplicate existing functionality there's a large unknown factor in the process.

To sum things up, the point is this: When considering a port of any application to a new environment one has to carefully consider the pros and cons of such a move. Re-writing an application rarely yields any MAJOR benefits for the consumers of an application. First and foremost a re-write usually focuses on providing the same functionality as the old application with a few minor enhancements that would have taken a fraction of the time to implement on the old platform. It may do so more elegantly under the covers because a re-write probably allows consolidation of accumulated code-gunk that has been kludged over an original design. But overall the value proposition to the consumer of the new application is very low.

A re-written application is not necessarily a better application. An existing stable application has many advantages because it has been real-world tested and tuned to the environment. Why do you think applications like Office are not managed applications? There’s little to be gained from building a .NET version of Word. It’d be slower most likely and probably YEARS in coming. There’s probably work being done on that as we speak at Microsoft but we won’t hear about it until MS ships Longhorn .

This is not a slash against .NET. If I were starting work today on Help Builder from scratch I would definitely go with .NET even given the above issues. But the issue from a re-write perspective are completely different. At the current time there’s just no cost benefit to a Help Builder re-write. Things may change in the future, but for now this is how it stands.