Edit .ism & compile msi from there? Or edit msi directly?
Hi all,
Not sure whether this question has been asked here already (a search didn't yield any results, but then again, this might be due to the searcher...).
I was having a discussion this morning with a fellow packager. He says he and his colleagues (they're from an external company our company has hired to cope with big demand) have the habit of, after a setup capture with Installshield, generating an .ism and then compiling the MSI straight away, unless additional source files need to be added. All changes (cleaning up, creating CA's etc.) are then performed on the MSI directly - so the .ism isn't touched anymore.
Me and my team, on the other hand, are in the habit of working with the .ism all the way and compiling the msi from there. Result: if we have an .ism and the source files are in the correct location, when we open the .ism and hit F7, we expect to be able to get the same MSI as used in the field.
Only exception I personally have is when wanting to change something simple (say, a property value) in a very large MSI. I then edit the MSI directly, change the value there, and simultaneously do the same in the .ism, but only saving it, thus avoiding a lengthy compilation.
What is your approach on this? Is one method preferrable over the other?
Not sure whether this question has been asked here already (a search didn't yield any results, but then again, this might be due to the searcher...).
I was having a discussion this morning with a fellow packager. He says he and his colleagues (they're from an external company our company has hired to cope with big demand) have the habit of, after a setup capture with Installshield, generating an .ism and then compiling the MSI straight away, unless additional source files need to be added. All changes (cleaning up, creating CA's etc.) are then performed on the MSI directly - so the .ism isn't touched anymore.
Me and my team, on the other hand, are in the habit of working with the .ism all the way and compiling the msi from there. Result: if we have an .ism and the source files are in the correct location, when we open the .ism and hit F7, we expect to be able to get the same MSI as used in the field.
Only exception I personally have is when wanting to change something simple (say, a property value) in a very large MSI. I then edit the MSI directly, change the value there, and simultaneously do the same in the .ism, but only saving it, thus avoiding a lengthy compilation.
What is your approach on this? Is one method preferrable over the other?
0 Comments
[ + ] Show comments
Answers (4)
Please log in to answer
Posted by:
murali.bhat
13 years ago
I prefer to work on msi file and keep the ism file untouched.
The only reason I keep the ism untouched is because it gives me all the files and registry keys that were captured. After compiling and editing the msi file (deleting unwanted components), for some reason if msi fails to work, I go back to ism and compare with msi.
Adding to this, working on the msi file saves lots of time - compiling ism and creating msi for every change is difficult.
One of my customer wanted only the base ism file and cleanedup msi file as part of deliverable.
The only reason I keep the ism untouched is because it gives me all the files and registry keys that were captured. After compiling and editing the msi file (deleting unwanted components), for some reason if msi fails to work, I go back to ism and compare with msi.
Adding to this, working on the msi file saves lots of time - compiling ism and creating msi for every change is difficult.
One of my customer wanted only the base ism file and cleanedup msi file as part of deliverable.
Posted by:
anonymous_9363
13 years ago
it gives me all the files and registry keys that were captured.So you don't use any kind of version control system, even a "manual" one e.g. folders called v1.00, v1.01, v1.02 etc.?
Does IS not have a back-up option? Wise can be set up to keep multiple versions.
Posted by:
murali.bhat
13 years ago
The complex packages requires version controlling as changes are quite frequent and initial test result may not show right result. Since most of the simple packages gets deployed in the first go itself (and most of packaging requests are not complex type), I dont use version controllers.
Posted by:
pjgeutjens
13 years ago
Does IS not have a back-up option? Wise can be set up to keep multiple versions.
Installshield has the principle of 'Releases' whereby everytime you compile an MSI from the ISM, you get the option of putting it in a seperate release folder from the previous ones.
As for the discussion, I'm one of Jonas' teammates, so his view pretty much reflects mine. I tend to view the actual capture files (irp and inc files) to be my baseline, and adapt/clean up the ISM file, then finally build an MSI. So the ISM is a reflection of the contents of the final MSI that gets delivered.
More input would be appreciated
PJ
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
