Isolation Repair Support
I am using Wise Package Studio 5.6 to isolate all applications. When running through the isolation wizard you get 3 options for adding repair support: No repair support, Install in original location or Install in app directory only.
Although it appears that the second option ('Install in original location') should create a shared copy and an isolated copy of the DLL, both of which should have repair support, it seems that only the shared copy will initiate a self-repair if it is deleted. If the isolated copy of the DLL is deleted the app will not repair.
Selecting the third option ('Install in app directory only') creates 'repair support' for the isolated copy of the DLL and it will then initiate a self-repair if deleted, but with this option a shared copy of the DLL is not created. This then raises the whole question of where the DLL registration information in the registry should point to as discussed in the previous 'app isolation' post.
Is this a bug in Wise (the isolated DLL not initiating a self-repair) or is this the way it is meant to work???
Any help much appreciated.
Gordo
Although it appears that the second option ('Install in original location') should create a shared copy and an isolated copy of the DLL, both of which should have repair support, it seems that only the shared copy will initiate a self-repair if it is deleted. If the isolated copy of the DLL is deleted the app will not repair.
Selecting the third option ('Install in app directory only') creates 'repair support' for the isolated copy of the DLL and it will then initiate a self-repair if deleted, but with this option a shared copy of the DLL is not created. This then raises the whole question of where the DLL registration information in the registry should point to as discussed in the previous 'app isolation' post.
Is this a bug in Wise (the isolated DLL not initiating a self-repair) or is this the way it is meant to work???
Any help much appreciated.
Gordo
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
WiseUser
18 years ago
Wise do not make it clear how they are (or aren't) creating repair support for isolated files. And I agree with you for questionning what exactly they are doing to your packages.
Although it may appear at first glance that no repair support is included using this option, further investigation may lead you to discover two custom actions called "WiseIsoCompInfo" and "WiseIsoCompEditReg", as well as a table called "WiseIsolateComponent". You may also notice that an empty component is created within the feature.
It seems that one of these custom actions registers the isolated library for which repair support is required as a keypath of the empty component (although the file is obviously not part of the empty component). But if the library is not part of the "broken" component, how will it be able to repair you may ask yourself... I think Wise are relying on the fact that the entry level feature should receive a feature-level repair (thus restoring the missing isolated file).
Although this option also appears to create the 2 extra CAs (the purpose of which is unclear), I haven't been able to find any "cleverness" hidden within this option. It would seem to me that Wise do indeed in this case register the component within the application directory (and unregister it on uninstall). If this is true, then installing the MSI may cause other applications to start using newly installed “private†(and possibly incompatible) copies of components, and uninstalling the MSI may prevent these applications from finding ANY copy of the component.
Assuming the above is true, I would certainly not use this feature myself.
Is self-repair of isolated components really that important to you?
Although it appears that the second option ('Install in original location') should create a shared copy and an isolated copy of the DLL, both of which should have repair support, it seems that only the shared copy will initiate a self-repair if it is deleted. If the isolated copy of the DLL is deleted the app will not repair.
Although it may appear at first glance that no repair support is included using this option, further investigation may lead you to discover two custom actions called "WiseIsoCompInfo" and "WiseIsoCompEditReg", as well as a table called "WiseIsolateComponent". You may also notice that an empty component is created within the feature.
It seems that one of these custom actions registers the isolated library for which repair support is required as a keypath of the empty component (although the file is obviously not part of the empty component). But if the library is not part of the "broken" component, how will it be able to repair you may ask yourself... I think Wise are relying on the fact that the entry level feature should receive a feature-level repair (thus restoring the missing isolated file).
Selecting the third option ('Install in app directory only') creates 'repair support' for the isolated copy of the DLL and it will then initiate a self-repair if deleted, but with this option a shared copy of the DLL is not created. This then raises the whole question of where the DLL registration information in the registry should point to as discussed in the previous 'app isolation' post.
Although this option also appears to create the 2 extra CAs (the purpose of which is unclear), I haven't been able to find any "cleverness" hidden within this option. It would seem to me that Wise do indeed in this case register the component within the application directory (and unregister it on uninstall). If this is true, then installing the MSI may cause other applications to start using newly installed “private†(and possibly incompatible) copies of components, and uninstalling the MSI may prevent these applications from finding ANY copy of the component.
Assuming the above is true, I would certainly not use this feature myself.
Is self-repair of isolated components really that important to you?
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.