contesting corporate standard
Need a little help from some smarter people than I.
We have a corporate policy that apps needs to be packaged by a central packaging team fairly standard sort of stuff.
We also have a major vendor who shall remain nameless but produced a relatively good quality complex MSI. It handled the usual complex feature structure with conditional logic etc. Conditional features / components without hard coded paths etc.
i.e. properties for dynamic items such as
[SERVERNAME] = xxxxx
There was also considerable use of CustomActionData and typical good things you would expect from a mature vendor. The vendor also often release patches in the form of MSP / MSI (major updates etc)
So this MSI went through the corporate MSI sausage factory and on the other side some interesting things happened.
1) ProductCode had changed
2) ALL component codes had changed
3) Upgrade codes had changed
4) the feature structure had changed
5) a whole raft of hard coded entries were now present.
6) a stack of cool vbs CA's showed up that did interesting stuff like delete files which were keypaths after installation had been done
7) remove folders during uninstall etc
At an initial glance one would take a wild stab in the dark and say this app had been captured. Further investigation also found a couple of smiley faces in the registry table not too mention a few Advertised entry point markers from the old MSI.
Now I haven't done any packaging in a few years so I am a little rusty but did something change while I wasn't looking that made this all acceptable? So I am looking for feedback to see if I am the only person in the world who thinks this is somewhat strange to do to what looked like quite a reasonable application.
Can anyone comment on the quality of this package from our corporate team? How would you guys have done it different?
We have a corporate policy that apps needs to be packaged by a central packaging team fairly standard sort of stuff.
We also have a major vendor who shall remain nameless but produced a relatively good quality complex MSI. It handled the usual complex feature structure with conditional logic etc. Conditional features / components without hard coded paths etc.
i.e. properties for dynamic items such as
[SERVERNAME] = xxxxx
There was also considerable use of CustomActionData and typical good things you would expect from a mature vendor. The vendor also often release patches in the form of MSP / MSI (major updates etc)
So this MSI went through the corporate MSI sausage factory and on the other side some interesting things happened.
1) ProductCode had changed
2) ALL component codes had changed
3) Upgrade codes had changed
4) the feature structure had changed
5) a whole raft of hard coded entries were now present.
6) a stack of cool vbs CA's showed up that did interesting stuff like delete files which were keypaths after installation had been done
7) remove folders during uninstall etc
At an initial glance one would take a wild stab in the dark and say this app had been captured. Further investigation also found a couple of smiley faces in the registry table not too mention a few Advertised entry point markers from the old MSI.
Now I haven't done any packaging in a few years so I am a little rusty but did something change while I wasn't looking that made this all acceptable? So I am looking for feedback to see if I am the only person in the world who thinks this is somewhat strange to do to what looked like quite a reasonable application.
Can anyone comment on the quality of this package from our corporate team? How would you guys have done it different?
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
Inabus
13 years ago
It would be strange for a packaging company to snapshot an MSI, this is way outside normal process unless their is a fundamental flaw in the other MSI that would prevent you from doing something, i.e. making an AIP, modifications to vendor MSI's would 99% of the time use a transform.
By doing this the packaging company has ensured that no vendor patches or updates will work in the future and that you would have to, I assume, go to them for those upgrades.
If I was you I would ask them for the specific details of why they decided that repackaging a vendor MSI was a good idea.
Based on that response, and your own investigation of that response, I would tell them to redo it properly i.e. no snapshotting vendor MSI's.
P
By doing this the packaging company has ensured that no vendor patches or updates will work in the future and that you would have to, I assume, go to them for those upgrades.
If I was you I would ask them for the specific details of why they decided that repackaging a vendor MSI was a good idea.
Based on that response, and your own investigation of that response, I would tell them to redo it properly i.e. no snapshotting vendor MSI's.
P
Posted by:
pjgeutjens
13 years ago
John,
in an effort to be brief:
No.
Go have a talk with the guy who made this package. If the phrase "hands off, vendor MSI" is foreign to him, you (or someone) need to either have a long hard look at your corporate policy or a long hard look for a new packager/package provider...
just my 2c ofc.
PJ
in an effort to be brief:
but did something change while I wasn't looking that made this all acceptable
No.
Go have a talk with the guy who made this package. If the phrase "hands off, vendor MSI" is foreign to him, you (or someone) need to either have a long hard look at your corporate policy or a long hard look for a new packager/package provider...
just my 2c ofc.
PJ
Posted by:
timmsie
13 years ago
This is what I would say:
We would definately not snap a vendor MSI!
Definately should never change the ProducCode of a vendor msi. It'll mess up your ability to apply updates from the vendor.
Would only change for conflict management purposes or leave alone
Same as Product code, why would you change it as it'll affect any future updates from the vendor
Would change it only to add current user feature perhaps. Or at a push to make a vendor app support advertising. But generally would be left alone!
Nothing should be hardcoded
Seems like a very strange thing to do, unless your trying to stop a repair on a citrix box perhaps????
I would clean up the uninstall to make sure it removed cleanly
Cheers
Rich
We would definately not snap a vendor MSI!
1) ProductCode had changed
Definately should never change the ProducCode of a vendor msi. It'll mess up your ability to apply updates from the vendor.
2) ALL component codes had changed
Would only change for conflict management purposes or leave alone
3) Upgrade codes had changed
Same as Product code, why would you change it as it'll affect any future updates from the vendor
4) the feature structure had changed
Would change it only to add current user feature perhaps. Or at a push to make a vendor app support advertising. But generally would be left alone!
5) a whole raft of hard coded entries were now present
Nothing should be hardcoded
6) a stack of cool vbs CA's showed up that did interesting stuff like delete files which were keypaths after installation had been done
Seems like a very strange thing to do, unless your trying to stop a repair on a citrix box perhaps????
7) remove folders during uninstall etc
I would clean up the uninstall to make sure it removed cleanly
Cheers
Rich
Posted by:
anonymous_9363
13 years ago
Yup, it's been captured and the sap who did it has tried to cover his tail with the CAs, thinking that self-healing was somehow an error.
If I were you. I'd be flagging it with whoever engaged that company's services, as a heads-up of a potential drop-off [cough] in quality.
If I were you. I'd be flagging it with whoever engaged that company's services, as a heads-up of a potential drop-off [cough] in quality.
Posted by:
jmcfadyen
13 years ago
thanks guys.. I know what needs to be done people just aren't listening hence I figured I would get some more ammo.
re the feature changes etc, this was due to captured MSI dropping the 50-60 features the original MSI had back to one. Of course this app is extremely complex targeted at wider audience unknown platform scenario. So the drop in features in my opinion is shall we say plain stupid.
when we need to add a new feature in this new MSI it will be relatively entertaining. Not a bad attempt at completely messing up a relatively good MSI from a vendor. You all know how often I praise a vendors msi's so....
cheers.
John
re the feature changes etc, this was due to captured MSI dropping the 50-60 features the original MSI had back to one. Of course this app is extremely complex targeted at wider audience unknown platform scenario. So the drop in features in my opinion is shall we say plain stupid.
when we need to add a new feature in this new MSI it will be relatively entertaining. Not a bad attempt at completely messing up a relatively good MSI from a vendor. You all know how often I praise a vendors msi's so....
cheers.
John
Posted by:
spirosl
13 years ago
Wow!
I've always been against modifying vendor released MSIs due to the fundamental reason that the vendor could (and would) offer no support due to an unsupported change in the installation of a product.
- spirosl
I've always been against modifying vendor released MSIs due to the fundamental reason that the vendor could (and would) offer no support due to an unsupported change in the installation of a product.
- spirosl
Posted by:
reds4eva
13 years ago
People do strange things. Why would you snapshot an MSI when your goal is to have an MSI ?
I have had occasion to change a vendor MSI product code. One place I worked used Major upgrades only, my vendor MSI used the same productcode for all of its versions. Vendor MSI doesnt mean it is a good msi. (mostly never)
I have had occasion to change a vendor MSI product code. One place I worked used Major upgrades only, my vendor MSI used the same productcode for all of its versions. Vendor MSI doesnt mean it is a good msi. (mostly never)
Posted by:
jmaclaurin
13 years ago
Probably all the info you need is at about the 50sec point of this video.
http://itninja.com/blog/view/appdeploy.com->-training-videos->-repackaging-best-practices
http://itninja.com/blog/view/appdeploy.com->-training-videos->-repackaging-best-practices
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.