I have a few add-ins for Excel and Word 2007-2016. And I don't understand a few things. My project use some dlls, like Microsoft.Office.Tools.Common, Office.dll, some excel, word and common interop's. And these files can be found in a few places at the same time, different versions of them (like program files, windows/assembly, windows/Microsoft.Net/assembly). So I don't know which version to use. And also, if user has VSTO installed, I suppose he has these files. So why do I need to provide them? What do we install exactly when we install VSTO? Which part is for what and which installation place is from which component? I think I don't do it right, because I found out that Excel loads two different versions of the same file at the same time.
Those are a lot of questions, and many of them depend very much on exactly what you provide with your solution...
The case of the PIAs ("Office dlls") is relatively clear cut:
You do NOT need to (and should not) distribute the Office PIAs with a VSTO solution, with the possible exceptions of 2007 and 2010. In these versions, installing .NET support was optional and not default. That's why there are redistributables for these versions, and not for others. Your installer needs to check whether they're present (same as with the VSTO runtime and the version of the .NET Framework) and install only when necessary.
Office always installs the PIAs into the GAC and your solution will find them there. It makes no difference where you referenced them on your developer machine.
The PIAs in the GAC are only available via the COM tab in the Visual Studio dialog box for inserting references. Many .NET developers didn't find them there, so Microsoft delivers a (ONE) single set of PIAs with VSTO and copies them to a Visual Studio folder so that they'll show up in the .NET tab of the dialog box. The only problem with this is that you get only the set of PIAs for the version of Office that was "current" when that version of Visual Studio was released, meaning you may get the impression you can't develop against any other version because you don't find the PIAs in the .NET tab (but they will be in the COM tab).
Rule of thumb: Always, always develop your code using the earliest version of Office you plan to support. There are two reasons for this: 1) You can only use functionality that will be available to all versions of the Office application (Office is generally backwards compatible); 2) Office is designed to migrate references to older sets of PIAs to newer sets, but not the other way around.
There's a good article on deployment pinned at the top of the VSTO forum on MSDN that "sorts" a lot of requirements for various versions of VSTO and Office: https://social.msdn.microsoft.com/Forums/vstudio/en-US/1666d2b0-a4d0-41e8-ad86-5eab3542de1e/deploying-office-solutions-to-end-user-computers?forum=vsto for add-ins targeting 2007-2010. For later versions, see the MSDN documentation: https://msdn.microsoft.com/en-us/library/bb386179.aspx
I have a VSTO-Add-In for Outlook and need the information when i have to provide the VSTO-Runtime with the installation of the Add-In.
I have already found this article describing the prerequisites but I could construct cases which do not fit this description:
The article says "If Office 2010 Service Pack 1 (version 14, build 6029) or any newer Office version is installed, Office will take care of configuring the VSTO runtime."
=> This is telling me I do not need to provide the VSTO-Runtime in this case.
In the case that I have installed Office 2010 and manually install the ServicePack 2 I have the buildversion 7015 in my Outlook which is a greater version than 6029.
My installer recognizes this and does not provide the VSTO-Runtime.
But on starting Outlook after the installation I get an error saying, the .vsto-file could not be read.
This error only disappears after installing the VSTO-Runtime. Then the AddIn works fine.
What are the real cases in which i need to provide the VSTO-Runtime?
if you're using windows installer, just add it as prerequisite, which will create a Setup.exe, and add it as Launch Condition in your installer to show an error message, that Setup.exe should be run, or just make the Setup.exe run always, it will launch your .msi
have a look here - I guess this is also valid for Office 2013 .. just use the right components IDs !
Solution
I have added a Treeview Active X Control to one of our spreadsheet, using Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e. MSCOMCTL.OCX which lives in C:\Windows\SysWOW64\
KB2881029 (Security Update for Microsoft Office 2010 32-Bit Edition) (MS16-004), pushed out from Microsoft on 2016-01-15 (or thereabouts), installs a new version of MSCOMCTL.OCX (v6.1.98.46) which was "Created" on 2015-12-09, but "Accessed" (i.e. installed on the computer) at the time of the update.
This made the workbook "lose" reference to MSCOMCTL.OCX (quote marks on "lose", because the reference is still ticked but no longer works; the workbook doesn't compile because of "Compile error: Object library feature not supported" or "Automation error").
It seems that the update modifies the following registry key by adding a SubKey 2.0, but leaves it empty, and doesn't register the new MSCOMCTL.OCX:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\
Fixing the problem requires three steps:
MSCOMCTL.OCX needs to be unregistered and re-registered from an elevated command prompt, as follows:
C:\Windows\system32>Regsvr32 /u C:\\Windows\SysWOW64\MSCOMCTL.OCX
C:\Windows\system32>Regsvr32 C:\\Windows\SysWOW64\MSCOMCTL.OCX
When registering the new MSCOMCTL.OCX (Version 6.1.98.46) via REGSVR32, a new key is added to the Registry:
KEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\2.2
If there was a SubKey named 2.1 already existing, it enters a reference that 2.2 is now the Key for use. But it doesn't do anything to the empty 2.0 SubKey !
If there is a 2.0 (or 2.1 for that matter) SubKey with nothing in it, any object using that OCX should fail to create because it will use the 2.0 (resp 2.1) Version, it can't and didn't check for 2.2 Version.
Clean up the registry by deleting the wrong or superseded keys 2.0 and 2.1, leaving only the latest and working key 2.2. This can be done from the Registry Editor by selecting HKEY_CLASSES_ROOT, Edit/Find/MSCOMCTRL.OCX.
(Note: this step seems optional as I have checked that doing only step 1 and 3 made the workbook work again. But it feels like the right thing to do)
In the in the Excel workbook VBA project, Microsoft Windows Common Controls 6.0 (Service Pack 6) needs to be unreferenced and re-referenced. Re-referencing is not just a matter of re-ticking the box, you need to use "Browse", and select MSCOMCTL.OCX in C:\Windows\SysWOW64\
(Note, in the browser window, you need to change the file type from "dll" to "OCX" (or "all"))
Daniel Alexander Karr (refer post further below) has kindly shared a script he wrote to do steps 1 and 2 automatically (note that needs to be run as an Administrator).
Thanks Daniel and wmelonman for your help in understanding the problem and finding a solution.
Original Post
Similarly to what is described in this 3 year old post
(VBA Automation Errors due to Office Service Pack 3.0 caused by Forms), a perfectly working workbook of mine stopped working from one day to the next...
In the list of updates carried out last night the following ones are Office Updates:
KB3114563 (Definition Update for Microsoft Office 2010 32-Bit Edition)
KB2881029 (Security Update for Microsoft Office 2010 32-Bit Edition)
KB3114555 (Update for Microsoft Office 2010 32-Bit Edition)
KB3114553 (Security Update for Microsoft Office 2010 32-Bit Edition)
KB3114564 (Security Update for Microsoft Excel 2010 32-Bit Edition)
There were other updates, but general Microsoft Windows updates, not specific to Office, and they hopefully are not relevant here.
My understanding is that the "Automation error" is due to the project not compiling because of the presence of 2 "additional" ActiveX controls on one of my forms that I have referenced from Microsoft Windows Common Controls 6.0 (Service Pack 6), i.e., MSCOMCTL.OCX which lives in C:\Windows\SysWOW64\
Unfortunately un-registering and re-registering MSCOMCTL.OCX as explained in the aforementioned post didn't solve the problem.
I also tried deleting all *.exd, but there weren't any on my C: drive.
Additional info that may be relevant:
The MSCOMCTL.OCX file version is 6.1.98.46, created & last modified 2015-12-09 but accessed at 3.33am yesterday (2016-01-15), i.e. about the same time the updates occurred (3:14am for the latest one).
Once passed the initial "automation error" message, I would get an additional message, "Compile error: Object library feature not supported", highlighting lines of codes associated with the additional controls.
I've verified these were "causing" the problem by creating a blank form an trying to add one on. I got the error message "Could not complete the operation due to error 800a0011".
These additional controls are Microsoft TreeView Control 6.0 (SP6) and Microsoft ImageList Control 6 (SP6).
I could add the Microsoft TreeView Control, Version 5.0 (SP2) and Microsoft ImageList Control, Version 5.0 (SP2) without raising the error (I didn't try making them work though).
Does anyone know of similar mishap with MSCOMCTL.OCX following yesterday's Microsoft updates? That may confirm it could be the source of my problem.
Does anyone know of a fix?
Does anyone know how to report this to Microsoft (if indeed it is the source of the problem)?
And finally, for those interested, there is a way to avoid Microsoft Updates messing up ActiveX controls...not using them! This is what JPK has done for his TreeView.
our Business-ERP-Software Faktura-XP got the same problem since yesterday, we investigated the Problem and created a Patch for it, maybe it will help someone:
http://www.faktura-xp.de/faktura-xp-download/update-und-patch-oeffentlich.html#toggle-id-4
In our Case, the TreeViewControl stopped working, but it will be the same Problem with Automatition. Microsoft updated the MSCOMCTL.OCX to Version 2.2, if the Key
{831FDD16-0C5C-11D2-A9FC-000F8754DA1} has an empty 2.1 or 2.0 Entry the Common Control will stop working.
Solution:
Delete Key 2.0 and 2.1, leave 2.2, unregister the mscomctl.ocx and reregister it.
Our Patch will do exactly this, nothing more, nothing less, but as simple as possible for our customers, just click Next and Close.
Edited for more information:
HKEY_CLASSES_ROOT\TypeLib\{831FDD16-0C5C-11D2-A9FC-000F8754DA1}\2.2
is freshly created when register the new MSCOMCTL.OCX (Version 6.1.98.46) via REGSVR32
When there is a SubKey named 2.1 it enters a reference that 2.2 is now the Key for use.
If there is a 2.1 SubKey with nothing in it, your Object will fail to create because it will use the 2.1 Version, can't and didn't check for 2.2 Version.
Delete this Key if neccessary and youre good to go.
Further Testings shows that 2.0 SubKey is obsolete and could cause Problems.
Mostly Systems with Microsoft Windows 7 had this Problem. For our Software, no-one with Windows 8.1 or Windows 10 called a Problem after the current Update.
Similiar problem here: Ancient Access 97 app on ancient XP (not for long anymore, sigh of relief) quits saying "Error 91: Object variable or With block variable not set". Examination showed it happens when the progress bar control which resides in Mscomctl.ocx is adressed.
I found that KB2881029 (MS16-004) is the culprit. It installs the new version of MSCOMCTL.OCX. On machines w/o this update the Access app works fine. But it is not suited for removal, at least this is what our WSUS told me when I was going for it. Anyway we wouldn't want to live w/o a security update.
Having read the answer concerning HKCR\TypeLib{831FDD16... I tried deleting the at that time still populated \2.0 subkey prior to installing the update only to find out that even with a non existing \2.0 subkey the update does create the empty one on installation. Well done, Microsoft...!
Thanks all for your contributions,
I have found that de-referencing and re-referencing the Microsoft Windows Common Controls 6.0 (Service Pack 6) in the Excel VBA project would finally make it work.
!!!...BUT...!!!
Simply un-ticking / re-ticking the tick box would be too simple ! For re-referencing it, you need to use "browse", and select MSCOMCTL.OCX in c:\Windows\SysWOW64\
(note, in the browser window, you need to change the file type from "dll" to "OCX" (or "all"))
I have tried simply doing this on a machine where I hadn't run Daniel Alexander's Patch (to un-register and re-register MSCOMCTL.OCX, and remove the old empty 2.0 key from the register), and it didn't work, so I expect the above steps are required. I will try to thoroughly test which steps are necessary and edit this answer to spell out the whole procedure, step by step, but for the time being running Daniel Alexander's patch (AS ADMINISTRATOR !) and re-referencing Microsoft Windows Common Controls 6.0 (Service Pack 6) in the Excel VBA project seem to work.
The problem has been described in detail here:
"Error messages or Access crashes after you install security update MS16-004"
MS: Article ID: 3139567
(Last Review: 02/16/2016 19:15:00 - Revision: 3.0)
https://support.microsoft.com/en-us/kb/3139567
we have a mixed environment. Some workstations have Microsoft Office 2010 installed while others have Microsoft Office 2007 installed. A lot of our in-house developed applications are referring to the Outlook 12.0 object library and the Excel 12.0 object library. In Office 2010 these are referring to the 14.0 object libraries. Is there a way when users launch an Access application that it checks which version of Office they have installed and when it detects either Office 2007 or Office 2010 so that it can programatically set the correct references to the Object Libraries?? Many thanks for any help and/or suggestions.
Set the references to use the earliest version of the reference and Ms Access will automatically upgrade the reference for later versions of Access if needed.
For example, if none of your workstations use anything less than Access 2007, you should set the reference to Excel 12.0. Any workstation using Access 2010 or 2013 will update the reference automatically for their local copy
I've had similar conflict issues between office 2010,2013 and 2016.
I think the whole point of initiating this thread is that "should" <> "does"...
Meaning that programing to the earlier version does not "always" work when the user PC is not running the exact same version of MS Office that was used during development.
I think maybe need to somehow add both object references to the compiled version and then the app can pick.
In other words, I think the development PC needs to be running both versions of Outlook.
You could also alternatively develop the app on a PC running the earlier version and then save off a copy to be compiled in a newer version of office on a different PC. You'd be basically generating versions specifically for each version of Office.
I am writing an application in VB.NET that will send emails using outlook. My problem is that I need the Office 2010 PIA to do this. The following are the steps I have already tried (I am using Visual Studio Express 2012):
Restarted the machine
Downloaded Office 2010 PIARedist and installed it
Restarted Visual Studio
Restarted the machine again
Uninstalled Office and the PIA and re-installed Office, making sure that the PIA was selected in the installation options (it was already selected by default, so presumably I installed it the first time I installed Office as well).
Restarted the machine again
Downloaded Office 2010 PIARedist and installed it again
Restarted VS
After each of these steps, the PIA is still not available in "Add Reference" in VS, nor do the files exist on my computer at all (a search for "Microsoft.Office.Interop.Outlook.dll" confirms this). I am running Windows 7 on my MacBook Pro. Does anyone know what my problem is here? This seems like a ridiculous amount of headache for such a simple feature.
PS The only reason I need the PIA is to be able to add CC recipients on the email. That's it. If anyone knows how to do that without the PIA, please let me know because I'd much rather just do that and be done with it.
PSS Both times when I installed the PIA itself, the installation ended silently (no indication of success or failure).
In case anyone stumbles on this question, I finally figured out how to add the interop. For some reason, it won't show up in the "Add References" window (maybe it's because I have VS2012 (11.0) and I'm using Office 2010...?) Anyway, I had to manually browse to it to add it. It was located in C:\Windows\assembly (all of the Office 2010 interops were in there). Also interesting was that a search of the entire C drive for 'Microsoft.Office.Interop.Outlook' or shortened versions of that string turned up absolutely no results, even though they are on the drive. One last note: although 'Microsoft Office 14.0 Object Library' shows up in the "Add References" window, adding that reference did not allow access to the interop.