Thanks for the response Michael. I know I can put a hard path in there like /l*v C:\Test\test.log. That works great. But what if I want to put the log file in say the INSTALLDIR or CommonFiles? None of these directories have been resolved until we get into the msi file which is too late by then. So my quandry has always been how to resolve the location of the log file using this option before sending in the command line. Am I just missing something obvious? Wounldn't be the first time. Thanks in advance for any suggestions. ... View more

I have never worked with Windows Server 2003 but the default requirement for IE7 to pass in IS 2008 is that the mshtml.dll file have a minimum version of 7.0.5730.11. I would check this file first and make sure it actually is this version or higher. Then check the rest of the conditions in the Signature table (if there are any) and make sure those are met also. A place to start anyway. Hope this helps. ... View more

In the Dialog view, select the dialog that comes before the CustomerInformation dialog in your sequence. By default this would be the LicenseAgreement dialog. Anyway, select the Behavior node of the dialog and make sure the Events tab is selected in the lower right. The Event column should say NewDialog and the Arguement column should say CustomerInformation. Change the arguement column to your custom dialog and configure the condition to your requirements. Also, remember to change the behavior of the back button in the dialog that is currently after the CustomerInformation dialog to goe back to your new custom dialog. Hope this helps. ... View more

Where in the sequence is the ca scheduled to run? You need to put custom actions you want to run during uninstall in the execute sequence because if you remove a program using add/remove programs then the uninstall completely skips the UI sequence. Also, I attached a pdf file that Robert Dickau wrote about setting conditions for installing and uninstalling that has helped me in the past. I uploaded the file because I couldn't remember the link. Anyway, hope this helps. ... View more

My experience with this is that the -y doesn't actually change the ProductVersion property in the .ism file, it only overrides the property during a specific build. So say you build your setup without the commandline, the ProductVersion in the .ism is 1.00.0001 and your setup actually puts the ProductVersion in the registry, say HKLM\Software\Product Name in a value called version. In this instance the version of the ism and the version in the registry will be the same. Now, you build the setup with the commandline and use -y "1.00.0021", the ProductVersion stays at 1.00.0001 but the version that gets put out in the registry is now 1.00.0021. The only way I know to make these two the same is to access the build number of the ism through (in whatever language you use) the msi database functions and actually grabbing the ProductVersion, increasing it and then resetting it. I'm sure others have a better way to do this though. I have never understood why there wasn't built in increment build technology already in place as it seems such a basic functionality. Maybe I am missing something also but that is my experience. Hope it helps. ... View more

What kind of project are you using? ... View more

I am having this same issue. I am testing two setups on a Vista Guest account. One requires admin the other invoker. When started both apps ask for permission but the admin level install shows the Unidentified Publisher message. The invoker level install shows our company name just fine. Our key came from VeriSign. Any suggestions as to where to look next? ... View more

Thanks Christopher. I completely agree with your conclusion and right now I am really feeling Allan's pain. For anybody else who might read this, Allan talks about the fact that it was suggested that each file have it's own component and obviously the file would be the key file for that component. This works great if you have all versioned files but it gets really tricky when you are working with non-versioned files, like is the case in most of these scenarios. I received this same suggestion from InstallShield a few years ago and unfortunately learned a very hard lesson about how non-versioned files get updated in the update process. Our app has a large number of xml and other non versioned files and the one file, one component suggestion I received seemed to be a good solution, if not a little tiresome. I felt very comfortable because the suggestion came from InstallShield so I didn't feel I needed to investigate it any further. I paid a pretty big price for that assumption. Well, we sell different localized versions of our software, as many people do. Our two different sales channels are retail stores and direct web site sales. It is not uncommon for our users to have two different localized versions installed and of coarse, many non-versioned core files were shared. The problem occured when a newer version of one of the products was bought from the website and installed and then a different localized copy was bought later through the retail channels. The retail channel is significantly slower in getting new boxes on the shelf because they want to sell the old boxes first. I know, how unreasonable! Anyway, what happened was, our developers were copying the old xml file, pasting it into a new file, changing a few things, saving the file with the old name and then checking that file in. This left the created and modified dates of the new file the same. After the first install, an older localized version was installed and because of the non-versioned file updating rules (http://msdn2.microsoft.com/en-us/library/aa370531.aspx) the new file would actually be replaced by the old file because of the fact that the new xml file's created and modified dates were the same. And as you can image, all sorts of fun things started to happen. Sorry, that was a long explanation but I was just trying to emphasize how tricky this every file as a component notion can become and to second Christopher's idea that we really need a tool to deal with this issue. Thanks again for your input Christopher. ... View more

Thanks for sharing your knowledge with us Christopher. You mentioned that vdproj deals well with a tree of unversioned files and I was hoping that you could share with us what the best way to deal with this scenario using an InstallShield basic msi project. Our doc team went to this type of technology for our all of our help files and I have just found out about it. When I first started doing installers I used dynamic file linking (on a much smaller scale than I am now faced with) but dynamically linked file had definate issues with patching. The last couple of years I have just been creating dummy exe key files for components and then adding the non versioned files to the component. This seems to have solved the issue of files not getting updated correctly. Now I am faced with literally about 70 different levels in all with hundreds of files so I can see I need to find a new way of dealing with this to make sure all files are updated when using a patch. Thanks for anything you can offer. ... View more

Thanks for the info, I will try that. ... View more

Hi David, As far as I know there is no way to remove the cached msi file after uninstall inside the msi file that is uninstalling. We have to cache the file for patching and I have always just left it on the users machine. Not the cleanest option but given our requirements it has gotten by. I would also be interested to see if someone has resolved this issue. Chris ... View more

If you are using a basic msi you can create a component with nothing else in it except a shortcut that points to your exe and put a condition on it based on your input. ... View more