Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
West Wind WebSurge - Rest Client and Http Load Testing for Windows

Why West Wind Html Help Builder is NOT a .NET Application


:P
On this page:

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.


The Voices of Reason


 

Margaret Duddy
August 19, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

Very well said. An argument applicable for commercial as well as in-house Foxpro applications. There is a huge workload for companies transitioning from Fox to .NET and the demand for a rewrite simply because it can be done can be wearing at times.
Rick's succinct and business-savvy voice of reason helps illuminate some of the most basic, but sometimes ignored, points to consider when scheduling rewrites and setting priorities for them.

Mike
August 19, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

Thanks for the pointer to VistaDB it does look potentially interesting.

Andrew Coates ::: MSFT
August 19, 2004

# Pros and Cons of re-writing, or


Sean
August 19, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

Is is me, or does the EULA appear to suck for VistaDB.. non-distribute, non-compete.. so that's $129 ($329) -PER SEAT- kinda defeats the purpose of being mentioned here...

Rick Strahl
August 19, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

Sean, where did you see this? I didn't read the Eula, but my guess is that it's for the developer tools, not for the runtime files. The product brochure mentions 'Unlimited distribution with no hidden costs'.

Greg Low
August 20, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

Hi Rick,

What're your thoughts on the express edition of sql server 2005? Do you think it will address most issues apart from shareware style deployment that needs a minute footprint?

Max Battcher
August 20, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

I'd like to mirror Greg Low's questions... Do you think SQL Server 2005 "Express" will help with the apparent lack of databases for "personal" database space?

Also, you might be interested in Minosse (http://www.minosse.com) which is a C#-native, open source, relational (SQL) database, which as a bonus provides support for both MS and Mono .NET environments. It's still very much in its infancy, but appears to be moving in the right direction.

Mike
August 20, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

Sean: my read of the Overview page pricing and licensing indicates that the pricing is:
$329 per license ($129 Special introductory offer!)
Licensing is "per developer"
Unlimited desktop and server distribution
No runtime costs.
So only the developer pays for his copy and can redistribute for free. I think thats sort of a suckless arrangement.
Just a note you need to ask for the Release Candidate version for evaluation if you want to play with the ADO.Net stuff.

Mike
August 20, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

Another thing, I'm not so sure that this fits only in the 'personal' db category. Seems like it may be very scalable.

Rick Strahl
August 21, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

Sql Server Express improves distribution of an MS data engine some, but it doesn't address the major issues: Size and administration. I haven't been able to install SQL Express (point taken, right <g>) on my system, presumably because SQL Server or some of the Whidbey components are already there. Even with local file deployment of connection strings there still is the issue of admin requirements to create a database which for an app not geared to developers maybe a big issue. Install issues are problematic too. How do you reliably install this thing? You have to check if SQL Server exists first? SQL Express? MSDE? For an integrated install this is easily a nightmare too. That's in addition of a potential additional hassle of having to install the .NET runtime if not there already.

Anthony Carrabino
September 21, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

I just saw this thread -- i've been so busy working:

>>>>>
Is is me, or does the EULA appear to suck for VistaDB.. non-distribute, non-compete.. so that's $129 ($329) -PER SEAT- kinda defeats the purpose of being mentioned here
<<<<<

That's not correct! This wording is for protection against someone that builds a database "engine" to compete with VistaDB. Basically, don't steal our code. Of course you can distribute the engine freely! Pricing is not per seat. It is per developer. I will reword the EULA to be more clear -- thanks for pointing this out. But definitely, take a look here:
http://www.vistadb.net/vistadb_pricing.asp

Guys there is a FULL eval now so you can see for yourself:
http://www.vistadb.net/EvalRequest.asp

Hope that helps
Anthony Carrabino
www.vistadb.net

Rick Strahl
September 22, 2004

# re: Why West Wind Html Help Builder is NOT a .NET Application

FWIW, I spent some time with VistaDb and integrated it into my business object framework and it was nearly painless. It certainly looks like a good alternative and is more SQL Server compatible than any of the solutions from Microsoft so if you need dual data providers (support SQL but offer a simpler file system option) VistaDb looks very promising...

Jon Galloway
July 08, 2007

# We need an Embedded Database for .NET applications - Jon Galloway


West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024