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?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

1
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.
Answered 01/04/2011 by: murali.bhat
Purple Belt

Please log in to comment
1
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.
Answered 01/04/2011 by: VBScab
Red Belt

Please log in to comment
1
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.
Answered 01/04/2011 by: murali.bhat
Purple Belt

Please log in to comment
1
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
Answered 01/04/2011 by: pjgeutjens
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity