Support for Multiple office versions in automation
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?
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.
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.
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.
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.
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.
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.