Create User defined Web Sites

[Ray_Portrait]

Is there a way through a Basic MSI project to create a website that the user defines through questions answered from custom dialogs? The IDE seems to have very limited capabilities (not that I am any sort of expert when it comes to IIS) and doesn't seem to have any good starting point.

Help!!!

[DebbieL]

In a Basic MSI project, you can use Windows Installer properties in place of any of the IIS settings in the Internet Information Services view that allow you to enter characters. Then you can also use those properties for controls that you add to your custom dialogs. At run time, the installation replaces the property names with the end users' entries when configuring the IIS settings. For more information, see the following help topic:
Using Windows Installer Properties to Dynamically Modify IIS Settings

Hopefully that'll get you started.

Debbie Landers
Acresso Software

[Ray_Portrait]

ok, that makes sense. The one place that does confuse me is that on the web site tab, there is a "Description" input where the set value goes to the String Table. What is this used for and am I correct in saying that string tables don't make use of properties?

[DebbieL]

You can actually use properties for IIS settings like the Web site's Description setting, which are included in the string tables. Those should be resolved at run time.

If you are creating a multilanguage installation, the string table lets you define the value of the Web site Description for each supported language. In other words, it lets you define an English text string for English systems, a German text string for German systems, etc.

[TheTraveler]

I created such dialogs and Install Shield Script functions to do exactly that. Check out this link. One of the many reasons why I abandon using MSI projects is because I wanted to give the user more options. Furthermore, Install Shield script projects are more flexible on the side of the developer than MSI projects.

Here is a question for you. Does your project have to be an MSI project?

If not, great. The link I have above will definately help you.

If it is due to having to use Merge Modules. Believe it or not, Install Shield script installations can use multiple merge modules as well as Install Shield installable Objects.

Upgrades? Install shield script projects gives the Install Shield developer more control then you would believe. If you want more information about this, please let me know.

Database Access? Certainly IS projects can do that in spades. You can use the IDE interface or you can use ADO COM objects.

Creating FTP virtual folders? Yes again. I have been able to create FTP virtual folders through COM objects.

Custom Dialogs. I have created many reliable custom dialogs in IS Projects.

XML files. Using Com Objects, I have been able to modify XML encode files like the web.config files.

Access DLLs. You can easily access functions exported DLL functions. Including windows API calls.

Here is another factor. You don't have to have Windows Installer installed for an Install Shield Script project.

Put Simply, anything you need to do or want to do in an MSI project, You can do it in an Install Shield Script project and with more control and flexibility to the Installation developer.

[Ray_Portrait]

Thanks for the reply. 😉

Most of my experience of InstallShield has been InstallScript / InstallScript MSI projects. I will agree that it does give you a lot of flexibility which from the projects that I have inherited gets misused and lands up making the install more complicated than what it needs to be. The installs that I have written from scratch using the Basic MSI project type have always been more reliable and even though they are tricky to create, they are easier to maintain! I also seem to have fewer / no problems with these installs where as I am constantly putting fires out with the InstallScript projects.

The main problem that I have with InstallScript projects is that legacy code is bulky (I know there's been improvement to this over the years) and the fact that you can either do everything in script or in the rest of the IDE makes it difficult to find the problem area / a single place to fix a problem. This becomes more apparent in larger projects or projects that you haven't written.

I am not a fan of InstallScript projects and believe that MSI is the way forward. A lot of the functionality that you would have pages of script for is handled for free with the Windows Installer. This means that a Microsoft company has written and tested the logic as apposed to a single InstallShield Developer's scripts that do the same or similar functionality.

It may seem like I am on the defensive, but I am grateful for your input.

Oh, BTW... You may not need MSI installed for InstallScript projects, which through windows updates and installed programs will almost guarantee that this is already on the user's machine, you need ISScript installed for your project to work. This install being smaller than the WI install does not make it the lesser evil!

Another thing that I have seen too much of in Installscript projects is the call to external applications. This puts unnecessary risk to the install failing - relying that the application is either on the machine, deployed by the install or being put correctly into temp folders. Which means that you have to script checks to make sure that you can actually run this application. Have enough of these application calls can quickly make your installscript bulky.

The biggest gripe of using external apps is that more often than not they make changes to the system; this makes rollbacks of failed installs unpredictable and unclean.

I liked your point on InstallScript being able to give you more control through upgrades. It really does do that! The problem is that your script is constantly testing to see if it is an upgrade. This annoys me intensly as this is how our current install projects behave. Finding the correct place to put your code is near to impossible. I must admit this is probably hugely to the fact that the install has outgrown its initial scope, but I dont see it getting any better if we had to rewrite this ourselves.

Good luck with your InstallScript projects. I am sure it will be a success if correctly managed. My view on InstallScript projects is that when you want to fix or make a basic change it is like finding a needle in a haystack. :rolleyes:

[TheTraveler]

First, I didn't want to put you on the defensive. I just wanted to state my opinion.

It looks like I have more luck with Install Shield projects than you have. The reason why my taste with MSI projects went so sour was when I tried to create patches for my product. The way that MSI did it was unacceptable. It didn't have the flexibility that needed. Hopefully, Microsoft has fixed this problem.

As for the other issues you mentioned, I will admit that if you don't have a good structure in place, it can be a nightmare to find any problem. This can be said about any project. I have been doing this for so long that I have created a structure that allows me to track down any problem with ease. Furthermore, I have a library of perfected source code that I wrote that just plain works that give me lots of options that are currently not available in MSI projects. Just like the IIS issue you are are currently having which I have been using for the last four years without any problems.

I apologize for this. I didn't mean to make this post a debate between MSI and Install Shield Script projects. As they say, to each their own. I will also admit that MSI Projects are great for small and/or simple installations. Unfortunately, all of my installations are never small and/or simple.

To everyone else who read this post, find what is easy and works for you. I think we can all agree on that.

Sincerely,
The Traveler

[Ray_Portrait]

Thanks for the reply. It's good to see active people on these forums! Both projects types have their strength and weaknesses. And InstallScript does have alot of power if properly structured code (which sounds like you have, lucky bastard :D)

just out of interest, what short comings did you have on patches? I think that is one of MSI's strengths. I have had minimal problems with this.

Thanks again for positive feedback!

[TheTraveler]

Hey luck didn't have anything to do with it... I just good... 😄 But, it does help from time to time...

Keep in mind that I have been using install shield for the past 10 years. Here is the list of problems I had and I was on the phone with Install Shield support with this for hours.

To begin, let me set the stage. I created a project that used the combination of Install Shield script and MSI. When it came to adding files to the I used the dynamic linking function. This was great for me since we were developing a web pages and the other developers were adding pages every day. This also means that the testing staff needed to test the new changes daily. So building the project was simple since I didn't have to add the new files by hand. Now here is the problem.

1) Since I was using dynamic file linking, every time the project was rebuilt, the compiler assigned new GUIDs to everything. This was done in either IS7 or IS9 I can't remember which. This might be fixed now. So the patch would turn up to be the same size as a full install.

2) Then there was the problem of getting it to replace ASCII test files. There wasn't a Always Replace option.

3) I also needed to run Database scripts to upgrade the database that we created. The patch mechanism didn't allow me to run the scripts the way I needed them to be done. You see, there is one file that contains all the scripts. I have put into the files break points. These break points are like road signs in the file. I usually get the version of the product and I use the break points to get my starting position in the file.

So in conclusion, the patch mechanism wasn't working correctly with dynamic linked files, it didn't always replace the files that needed upgraded, and it wouldn't allow the flexibility I needed to upgrade the database.

This is when I learned about creating differential releases in install shield script projects. The way it creates them is very slick. It actually looks at a previous installation and then looks at the new set of files you have linked in the project. It builds the release based on the differences between the two releases. To me, that makes the most sense.

Now keep in mind that I was using an older version of IS. Back then, it really didn't have database connection to SQL Server like it does now. So a lot of these problems have probably been addressed. At least one would hope they have been addressed. With that experience, I have lost my interest in MSI projects to doing major customized installation projects similar to the one mentioned above. But if I need to do a quick installation of a couple of files, then I would probably us MSI for that.