Sorry to say, but I think you're screwed. The install experience for MSDE is very bad (even if you use the merge modules and hack them to work, which means you have to release patches from then on to fix MS security holes) and it's even worse for SQL Express.

The only thing you might be able to do is tell your installer that MSDE is on the CD that the installer is installing from and that it's a relative path from there. Although it sounds like your target it to make this a download.

You might use Wise, in which case it can selectively download what's necessary....

Or choose not to use a named instance if there is already an SQL Server available and just install your database to that SQL Server and set application security.... (which is what we do)

If you're requiring a named instance, then you don't have much room to work with. "I think its rather unacceptable to have to ship a setup installer of someone elses product that is already installed just to configure it." Since you're requiring a specifically named instance, you aren't just 'configuring' MSDE - you're installing MSDE again in order to get the named instance. Each MSDE/SQL instance is a separate installation.

Thanks for the info guys.

As an update, I found a way around my problem. I wrote a small console application that recursively looks for all setup.exe on the system. When it finds one, it interogates the FileVersionInfo to determine if its the "SQL Server Setup" and that the version is the one I am expecting, or newer. If it is, then it writes the setting to a registry key which the installer can then use to call the setup program the way I expect it.

If the key doesn't exist, or the field is blank, then the installer downloads the full MSDE installer from a web source and runs the MSI to install. Ends up, this solves all my concerns.

Thanks for the feedback.

The reason for the multiple MSIs is so that the different instances of SQL Server/MSDE on your machine - you can have up to 15 named instances plus a default instance - have different product GUIDs for the installer, so that Windows Installer considers them different products. Reusing an existing setup.exe is probably OK if all the MSIs accompany it, but if it's been stripped down to just one, you may well find that the setup fails because an instance using that product GUID is already present.

I've had to deal with the coding end of MSDE installations, and they aren't pretty.

For starters, as Dana has found, you've got a 25MB CAB file, and a 1.6MB MSI file to distribute. However, this MSI file only works with a single instance of MSDE. If you want a different, instance, you need a different MSI file...

The product I was working on needed to support installing different instances of MSDE, but the company didn't want to ship all 16 MSI files. I ended up finding the differences between each MSI file (a couple of metadata GUIDs and 1 or 2 properties, from memory) and wrote a tool that would modify one MSI file to look like another. It worked well, but wasn't pretty from a technical viewpoint.

As Chad noted, each instance is a seperate install of SQL/MSDE. This means more memory usage, separate copies of binaries, etc. All up, it's easier to modify your product to use an existing SQL/MSDE instance than it is to install a new instance.

Also watch out for service pack updates for MSDE. They're particularly nasty. If you don't get the command-line options right, the update won't install.