Isolation for an Excel AddIn ?
I'm currently working on a package for a customer which deploys an Excel AddIn to the XLSTART folder. The repackage snapshot picked up two additional OCX files being deployed to the System32 folder, namely COMCTL32.OCX and COMDLG32.OCX both of which are newer versions than those already present in the customer's base build.
Ordinarily I would look to deploy these files using merge module(s), however the customer's packaging standards dictate that merge modules should not be used and instead .local isolation should be employed instead.
My question is therefore, in the absence of an actual executable in the package, is it possible to use .local isolation to force the addin to use isolated copies of these newer OCX files, and if not, are there any other options open ?
Spartacus
-
Does anyone know How to sequence Excell Add-in using app-v 5.0 - ravi123 9 years ago
-
Why don't you open a new thread instead of hijacking an old one? - EdT 9 years ago
Answers (3)
As there are old version of these ocx files already present in the customer build, why don't you check whether your addin is working without these ocx files are not. If it is not working then you can think on isolation right...
Thanks for the reply, but the point is that the repackaged addin has newer versions than are already in the customer build.
I do take your point that testing with the existing versions of the OCX files might be worth a try, however the addin relies on back end connectivity to a customer database - something I unfortunately do not have whilst packaging offsite
Spartacus
Spartacus
Just a thought, but since these are newer versions of the OCX's anyway, would your preferred method of deploying them through a merge module not result in them being updated anyway? So why not just include them in your package directly? Not my preferred way of working either, but...
In the absense of an executable to link them to, isolation through the use of a .local file is not an option I believe, like you concluded yourself.