I've come across a strange problem that may be a bug with windows installer but I was wondering if anyone else had come across it.

we have a suite of 3 apps produced by the same vendor (they wont always all be installed together) and they have some components that are installed in a common location C:\Program Files\Common Files\APPNAme\

We have alligned the GUIDs of all the shared components across these apps so one shouldn't break the others if uninstalled.

But in one of the apps one of these shared components also contains an entry in the environment table.

So here's the interesting bit:

APP1 (v1) and APP2 (v1) installed so the shared file and environment variable exists.

I uninstall APP2 and the shared file is left behind but the environment variable is removed.

I install APP2 (v2) and the shared component is not installed and neither is the environment variable. So APP2 (v2) doesn't work properly.


What d'you reckon? I'd expect if the component is marked to be left installed then everything in that component should remain. But in my case it's removing a bit of it i.e the environmental variable. But then on install it's behaving as I'd expect and not installing any part of the component!

cheers
Rich
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

0
What are the attributes for Environment Variable ?
Answered 05/07/2010 by: mekaywe
Brown Belt

Please log in to comment
0
Environment Name Value Component
[hr]envvar *=-Path [~];[DSS] ComponentSelection.dll
Answered 05/07/2010 by: timmsie
Fourth Degree Brown Belt

Please log in to comment
0
Richard,

I have 2 questions for you:

1) Installing APP2(v2) on its own, without the upgrade scenario, does install/remove the env variable as expected?
2) Do all your MSIs contain the WriteEnvironmentStrings and RemoveEnvironmentStrings standard actions?

PJ
Answered 05/07/2010 by: pjgeutjens
Red Belt

Please log in to comment
0
yes and yes
Answered 05/07/2010 by: timmsie
Fourth Degree Brown Belt

Please log in to comment
0
yes and yes

it's never easy, is it? [:D]

Anyway, doing a bit more reading about shared components, I came across the quote below on this page


Specifically, components with the same GUID should always have the same composition; and conversely, components that install the same set of resources should have the same GUID.

Could it be that the addition of the env variable goes against this rule and therefore breaks clean shared component functionality?
I know it's not a solution, but maybe a starting point?

EDIT: as an afterthought, I remember awhile back working in an environment where we did component matching, bad things would happen when you matched 2 components in the conflict monitor that turned out not to be identical. This was on a file level though, can't remember ever running into it with Environment Variables

PJ
Answered 05/07/2010 by: pjgeutjens
Red Belt

Please log in to comment
0
Specifically, components with the same GUID should always have the same composition; and conversely, components that install the same set of resources should have the same GUID.

Looks like that's my problem, My solution is to move the environment variable into one of the app specific components.

Trouble is I'm halfway through a rollout now! thank fully it's only a handfull of machines that have both these apps on 12 out of the last 500 we did, so not too much pain.

My own fault for not picking it up in deployment testing [:@]
Answered 05/07/2010 by: timmsie
Fourth Degree Brown Belt

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