Question
CIBC Bank
CA
Last activity: 23 Feb 2018 9:50 EST
Support for Multiple office versions in automation
Hello Team,
I have a use case where Microsoft office excel to be used in my automation. I have configured the runtime to use Office 2010. Unfortunately, not all my end users are in Office 2010. Few users are upgraded to 2013. Hence, automation fails in those machines as Office 2010 is not present. If I update the runtimeconfig to reflect 2013, automation fails in 2010 machines and vice versa.
How do I handle in this scenario where few users are in Version 2010 and few in Version 2013?
Thanks!!
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Learning
IN
Hello Ravi,
Thanks for writing your query in PSC. Kindly check the below URL for your reference:-
Hope this helps,
Thanks,
Hari
CIBC Bank
CA
Hello Hari,
Above discussions is different from my problem. I need to deploy the same solution to multiple end user's machines where few runs Office 2013 and others on 2010. As my solution is built using office 2010, it errors out in Office 2013 machines.
Thanks,
Nivas
Westpac Banking Corporation
AU
Change office version in runtime config file as per user's outlook version. So, the config file is vary based on users outlook version.
CIBC Bank
CA
My user base is approximately around 4800. Its hard to manually identify and change in every single system. Is there a way to support multiple office versions in Openspan?
Pegasystems Inc.
US
This is an issue with the way Microsoft changes the interop dlls when a version changes. There is a different interop dll for each version of Office installed. It is possible for Outlook and Excel to be on different versions. The RuntimeConfig setting causes the proper dlls to be used when Runtime starts.
When using the management console (Pega Robotics Automation Deployment Portal), you could group users by Office version and set their RuntimeConfig accordingly. When not using the management console, you may want to right an application to run at Windows login and set the RuntimeConfig setting. This is custom coding but would allow you to deal with the variation in the machines.
CIBC Bank
CA
Thanks Jeff.
This is our intention as well to write a custom code to check the installed Office version in the machine and update the RuntimeConfig accordingly. I was wondering if there is another way to do this. Apparently, there isn't.
Westpac Banking Corporation
AU
Think this way - 1. Build outlook related automation in both versions as a separate project and refer this in required projects and deploy to respective users based on office version. so, in this case you have to maintain 2 versions of package one for 2010 and one for 2013.
2. Request them to update to 2013 version.
Pegasystems Inc.
US
This will not work. There is no difference in the automation between versions of Office. The only difference is the Interop dll that is used to access Office. You must have the correct dll loaded (by Runtime) in order to automate.
Pegasystems Inc.
US
Following up and what Jeff said for the wider audience; we believe that based on Nivas' description, that the install process selected the incorrect version of Office. This in turn sets up the RuntimeConfig for that version of Office. Once a user runs Runtime with this incorrectly set, the RuntimeConfig is moved to the user's %AppData% directory and now references the incorrect version. The only way to rectify this after the install was done incorrectly is to update the RuntimeConfig. Ideally, the install would select the correct version of Office initially to avoid the issue.