Could someone comment on my question above? Thanks, Kiran Hegde ... View more

Folks, Any help? Thanks, Kiran Hegde ... View more

Hello, Did you ever get a resolution to this issue? If yes, kindly let me know. Regards ... View more

I am using InstallShield 2008 Premier edition for my installer development activities. My project is basic msi with setup.exe being generated. A previous version of the product (version 1)was built using this version of InstallShield. This product targetted the 64 bit Itanium windows servers(IA 64). In version1 , i had added a component with its target directory being set to SYSTEM64 folder( \system32). I had marked the file within the component as a key file. Now for the next version of the prodcut we plan to do a minor upgrade. Hence the version was upgraded(version 2). However when i attemp to upgrade to the latest version, i get the following error: Error 2324: Could not open file C:\windows\system32\ GetLastError :2 A error code of 2 indicates that the file could not be found. However the file does exist in the system32 directory. If i were to copy the file to C:\Windows\SysWow64 directory, the install goes through. I did some research on the web and came across the following links: http://community.flexerasoftware.com...d.php?t=193508 In the above link, one of InstallShield engineers states that this problem occurs if if the 32-bit version of msiexec.exe is used to launch the MSI package, and the package had installed files to the 64-bit System32 folder.In InstallShield 2008, it seems that setup.exe launches a 32 bit msiexec process to run the installation. This seems to have been fixed in IS 2010. Questions: 1)As per Flexera software, setup.exe built using InstallShield 2008 launches a 32 bit msiexec process even on a 64 bit server. When the observe the same in task manager on an Itanium server, i see two new instances of 32 bit msiexec launched. They appear as msiexec*32. However if the same process Id as got from task manager is observed in Process explorer(Sysinternals), it is pointing to the 64 bit msiexec under C:\windows\system32. How can this be? Please explain. 2)What is the best way to get around this issue? I dont want to build my own custom wrapper. This is ruled out. Kindly help as i am running against time to fix this ... View more

Hello Johan, Firstly, thanks for responding back. I apologize for the delayed response. I thought i would also get in touch with InstallShield. I am posting below my questions and the response i got from InstallShield. Hopefully people should benefit from this. Question Hello, We are using: Install Shield Premier Edition 2008 Basic msi project All flavors of windows targeted. We use a single setup.exe for both fresh install and minor upgrades (service packs) Our project uses a large number of files. As part of our project, we use multiple components with dynamic file linking setup. These components even have subfolders linked dynamically. I have done my fair amount of research on the web and each and every single post I have read states that the Component GUIDs change between every build of your product, if you do **not** point to your previous msi package(Releases view) when the installer built. However we have released several versions of our product without referencing our previous msi package. If all these posts were true, then the component GUIDs should have changed across releases and all our upgrades should have failed. Upon doing a MSI package diff of the msi's released across several versions, I observe the following: i) None of the component GUIDs has changed. ii) What has consistently changed is the Directory_ and Keypath column. So here are my questions: 1) For dynamic file linking, under what circumstances does the Component GUID change between installer builds? 2) What is the algorithm used by Install Shield to generate component GUIDs for dynamic file links? 3) What is the effect of Directory_ and Keypath column values changing across releases on upgrades? Remember we have **never** pointed our package to the previous msi package in any of our release and still the upgrades continue to work. How is this possible as the keypaths have changed? 4) This is the most important question of all We support upgrades from the last two versions: 4.5 and 4.6. We are currently at 5.0 Should i now start pointing my current version of my package to the last released msi, which is 4.6? What is the recommended approach here? Remember, i have not pointed either of 4.5 or 4.6 to their respective previous packages when they were built. I have just 3 more days to get answers to all of this. Any help would be very much appreciated. Response from InstallShield Thank You for contacting Flexera Software Technical Support. My name is Alpesh and I will be assisting you with this support incident. I understand that you have some questions about the Dynamic File Links. Please find answers to your questions here -- 1.) The Component GUID changes when you change the dynamic file link to point to a different folder. Ideally, during subsequent builds, the file keys for the files changes. But if you use the Previous Package field, then it will keep the file keys also in sync with the previous release. 2.) This would be Intellectual Property, but IS generates a different component for every PE file and subfolders. 3.) The Directory identifiers and File Keys are changing, but they are pointing to the same directory and same file. Hence, it is not causing the upgrade to fail. 4.) Ideally each package should point to a previous package. But if you are starting now, point to the latest package that is out right now. Also the Dynamic File link functionality has been improved upon with every IS release. I hope the information helps you. This is inline with what your observations have been. Thanks, Kiran Hegde ... View more

Hello Johan, You mentioned that you could get new component GUIDs generated by renaming of the path variables. Test 1 1)Pointed my dynamic component to a particular folder. 2)Built the msi 3)Modified the msi to point to the same directory structure in an entirely **different** path. 4)Built the msi Results: 1)Compared the msi's and found out that the old component in msi 1 was deleted and a new component was created with a different GUID Test2: 1)Pointed my dynamic component to a particular folder. 2)Built the msi 3)Modified the msi to point to the same directory structure in the same path. However this time i ensured that the path variable used for the dynamic link was different than what was used in test 1, eventhough the source files were in the same location as used in step 1 4)Built the msi Results: 1)Compared the msi's and found out that the only thing which changed was the Directory_ and Keypath columns. Question: How did you manage to get the component GUID's changed by just changing the path variable? I am pretty stuck on this. Any help would be very much appreciated. Thanks, Kiran Hegde ... View more

Thanks for sharing this piece of information. Let me search for compressed GUID and see where it leads to. Regards, Kiran Hegde ... View more

Thanks for the response. However this is happening on only 2 Japanese OS, not everywhere. What could be wrong? How do i generate a verbose log? How do i debug problems with InstallAnywhere? What are the next debugging steps i could use? Any help would be very much appreciated. Also if someone is aware as to what windows API is called during launching an executable operation, could you please let me know? I want to use the same API using a test program and see if it is working. Regards, Kiran Hegde ... View more

Hello, Is there a reason why you are using REINSTALLMODE="va" for your upgrade? To recache the new msi you need to use REINSTALLMODE="vomus". Regards, Kiran Hegde ... View more