Software Deployment

ACE02 is only an issue if the file is self registering. So long as there is no self registration we have no issue since Windows Installer tolerates components wandering into different locations. Each component key path is noted and uninstalled independently of the other.

I'd be very interested to know where viv_bhatt got that particular information. It's a totally new one on me.

I cannot think of a reason why you would ever want a components' installation state to be determined by the existence of a resource from another component!? But I'm an open minded guy - so please feel free to explain a scenario if I've missed something.

The keypath is the resource (registry or file) that the installer service uses to determine whether that component is installed or not. It is therefore a requirement that this resource be part of the component for which it is the keypath.

I can thinkof three possible ways to fix this error:

1) Choose a different keypath for the component (th is the easiest option).

2) Move the file to the component for which it is the keypath. You can only select this option if the component doesn't already contain files which are destined for a different folder than the file you wish to move.

3) If the component does not contain any resources, you may wish to simply delete it.

I'm with Wise on that one. I fix the 02's for the same reasons he listed.

Hi Wise User ,
ACE02 gives following error statement :
The destination [PATH1] for the component [COMPONENT1] in the package [PACKAGE1] conflicts with the destination for the component [COMPONENT1] in the package [PACKAGE2]. The correct destination should be [PATH2].

According to my understanding ACE02 warns where ComponentIds match but location's differ, and suggests that the component be relocated to match the database. If we move a non self registering component from a public location (System Folder) to a private folder then at least one application using this file will fail to locate it. So this approach only works when moving non self registering files to a more public location. However for reasons of multiple version compatibility we may not want to put all versions of a file into the public system folder, this leads to ‘DLL Hell’.

If it is self registering file then it should be re-located to the location of the most trustworthy source .

Please feel free to correct me if I have understood something incorrect .

Cheers ,
V

Hello v.

Sorry for the confusion - I read ICE instead of ACE. Therefore my previous post was a bit irrelevant to say the least. That explains why I had no clue what you were talking about![:D]

I guess it was an easy mistake to make, since VikingLoki was close behind me in making the same one! That's my excuse anyway.

Anyway, my view on the ACE02 issue is simple. Components should be uniforms across all packages. If you change the destination folder of a component, you should also change the component code.

Rules for components are quite clearly defined in the SDK here:

http://msdn.microsoft.com/library/en-us/msi/setup/changing_the_product_code.asp

Here's a quote of the most relevant section in my opinion:

A change in the name or target location of any file, registry key, shortcut, or other resource in the component. In this case, you must also change the name or target location of every resource in the component.

The consequences of not following these rules are here:

http://msdn.microsoft.com/library/en-us/msi/setup/what_happens_if_the_component_rules_are_broken.asp

Unless Novice_123 has a very clear understanding of why he is breaking the rules, I would suggest that stick to them.

Thanks WiseUSer for confirming my understanding I agree with your opinion.

Cheers ,
V

Hi all,
Thanks for helping me in getting the concepts clear about ACE02

And ICE02... don't forget that![:D]

Hey
Thankyou all for helping in clearing my doubts..[:)]