Usually, Cassini saves application path, port and virtual directory in the Registry. This allows us to install applications and modify the registry and to use placeholder variables for the installation path.

So far, I can't find where UltiDev stores the settings. It should be in the Registry since that's the required way to do it, but I can't find them. I need to be able to manipulate those settings via code.

Where are the settings stored?

Thanks,
Fred

Unfortunately, that's not realistic for us. Trying to run a command line registration during Installshield installation has lots of problems. Therefore, we have to directly modify whereever you store the settings. We have to preset the server's settings during the installation process. Normally, we do it via Cassini's use of the Registry, which is what you should be using, if you are to be compliant.

If you are not storing in the Registry, then can you please direct me to those settings and help me set them via code?

Thanks,
Fred

Sorry, I misspoke a bit. What I'm referring to is the first major variant of Cassini - Cassini as a Service: Bart De Smet [MVP] - 2004: www.bartdesmet.net. He correctly uses the Registry for storing param values.

You say: "functionality of registering applications". I assume you mean, in your case, registering the app as a service. This is trivial and easily done as part of the compile process, as you know. Bert's solution provides it.

It is not correct to be using a file (in your case, the XML file) to store param values. That went out when Windows introduced the Registry (I think back in 1995), so as to avoid the kind of problems we are encountering with your product; ie.,

1. Not knowing where values are stored,
2. Not being able to change the values or add new ones.

In the old days, there were .ini files scattered all over hard drives with param values for different products. That's exactly what you are doing with your method of storing data. The idea of the Registry is to avoid that.. The Registry easily accommodates multiple keys such as is required by your product.

Also, it is not Windows-compliant to not allow users to designate the destination for installation programs.

Look at a typical installation when using your product in a customer-based environment: The installation program should be able to launch CassiniExplorerSetup.msi and CassiniServer1Setup.msi into a folder of choice, and should then be able to register a default set of params in the Registry.

It's ridiculous to expect a customer (end-user) to open Cassini and go through the process of entering all these params, particularly when your interface isn't friendly (it doesn't allow browsing to the folders). It's also ridiculous to expect an end-user to know what the default page is.

End-users want to use the application that they purchased. That application may use your Cassini server, but the customer neither needs to know that, nor should have to struggle through entering settings.

And it's not good enough to suggest some kind of command-line solution. That is often not supported by installation programs.

You need to do what Windows expects you to do: use the Registry to store the values.

Regards,
Fred

What you are citing are fundamental operating system configurations, not 3rd party products. I will grant that you may need to specify the folder for services purposes, but it's still not compliant. Many services use the Registry for param value storage.

The really interesting thing you say is this:

"We have multiple success stories with people using command line option with InstallShield, for example."

Yet I've never found one successful use of Installshield (we use Installshield 11) that can fire the necessary registration. If you can provide the method and code I will be forever grateful and will henceforth quit bitching.

Installshield uses custom actions to attempt to fire command line instructions via VBScript, but the requirements for your configuration do not fit.

Can you please give me a specific .VBS example file?

Regards,
Fred

I figured that's the one you'd come up with. It doesn't work and it's not InstallShield 11.

Come on, you say "We have mulitple succes stories".... where are they?