5 replies to this topic

[dxue]

Hi Stefan and other friends,

I was creating a InstallShield QuickPatch project. I got warning 6493 when compiling the project. It shows that the update file in the patch has an earlier version than the file in the original setup package. Is there anyway I can get around with this warning without changing my new file's version.

Another related question is that in my previous setup project InstallShield ignored the version of the added assemblies, say 2.30.0165, but used some arbitrary one, say 3.3.2009, in the MSI's File table. But after deployment, files are shown the correct version on the target machine, in this case - 2.30.0165. Why is this the case? Can anyone of you tell me why?

Your help is appreciated.

Thanks,

Dong

[Stefan Krueger]

You can force an update/patch to overwrite ALL files, regardsless of version. This is a global setting and therefore it's dangerous and not recommended. Alternatvively you could either add that file to the RemoveFile table (so that the old version will be deleted first) or enter a higher version number in the File table than the new file actually has ("version lying"). The clean and highly recommended solution however is to accurately increment the version number of the file - that's what this number is for.

Regarding your second question make sure you don't mix up file version and assembly version. And for the file version, only the numerical version information field counts. Version resources also include text fileds (for Company Name, Copyright etc) which can also include a file version "string" which is "ususally" the same as the numerical version, but it doesn't have to. If these two are different this may be confusing.

[dxue]

Thanks Stefan. InstallShield QuickPatch project checks 'File version' for the updated files and gives warnings if the update file has earlier version than the original setup file. I found that I can ignore the warnings because InstallShield does update the file because it actually compares the real numerical version of the assembly at runtime. In one word, I am fine :-)

Here is another question. Our installation has problem in rolling up when doing major upgrade to the installed product. The installer uses dynamic linking for adding deployed files. Each component in the setup project contains folders, which may contain subfolders recursively. I read one of your replies to another post, in which you suggested adding each subfolder as a new component and then dynamically linking files under it. If I follow your suggestion, would my problem be solved?

Thanks again for your kind reply and help.

Dong

[dxue]

Sorry, I meant our installer has problem of rolling back to the installed version when failling a major upgrade to a new version.

[Stefan Krueger]

The dynamic link problem shouldn't affect Major Upgrades, only Small and Minor. Generate a verbose log file to see what's going on in case of rollback. There may be a problem with dynamic links if you perform an in-place update. That problem should be corrected by the workaround you mentioned.

[dxue]

Thanks Stefan. I will try it out next.