none
MS Office 2010 Registry points to Program files, but DLL s are in Program Files (x86) RRS feed

  • Question

  • At our company the machines are built on images. This particular image (which is used widely throughout the company) is referencing the Microsoft Office 2010 objects (DLL, OLB, etc). in the Program Files location (C:\Program Files\Microsoft Office\Office14\msoutl.olb) of course the actual file is in C:\Program Files (x86)\Microsoft Office\Office14\msoutl.olb.

    How do I correct this for all machines in our company easily. In the past, I've copied files from the Program Files (x86) to the corresponding Program Files folder, but wondering if there was a better way.

    Thanks In Advance!!

    Dan


    Dan Barry

    Friday, September 20, 2013 2:08 PM

Answers

  • Thanks Ken,

    I'm only posting this resolution in the hopes that it might help someone else.

    OK... I solved this immediate issue. The question is programming based. I developed an app in C# & VB.NET on VS2010 and got the following error when the app was trying to use the Outlook dll objects to send email:

    (I tried to upload the 48K image, but it wouldn't seem to allow me to upload?)

    ************** Exception Text **************

    System.InvalidCastException: Unable to cast COM object of type 'Microsoft.Office.Interop.Outlook.ApplicationClass' to interface type 'Microsoft.Office.Interop.Outlook._Application'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{00063001-0000-0000-C000-000000000046}' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).

       at Microsoft.Office.Interop.Outlook.ApplicationClass.GetNamespace(String Type)

    So my intent is pure... Now that I've resolved this issue. (The machines in question that were getting the error had the 32 bit version of office.) My application assumed that everyone had the 64 bit version (as we had recently replaced all machines with 64bit machines with 64 bit office - or so I thought). A few people were using applications that were not 64 bit compliant, so they had the 32 bit version of Office 2010. So if any developers get this error, check the version of office. I traced the referenced GUID's within the registry and compared them to another machine (where the app was working correctly) and found that the referenced library wasn't there (as it was a 64 bit Office 2010 library) -

    The Solution: I copied the contents of C:\Program Files\Microsoft Office\Office14 from a machine with Office 2010 (64bit) to the machine with the error. This resolved my issue. Eventually, I will modify the code to check for the version of office and run code that is appropriate for that version, but for now, this is a quick fix (as the issue was in production).


    Dan Barry


    • Edited by Danimal1 Friday, September 20, 2013 6:50 PM
    • Marked as answer by Danimal1 Friday, September 20, 2013 6:51 PM
    Friday, September 20, 2013 4:01 PM

All replies

  • This is a programming forum. You might be better off posting in a user or administrative forum for Office.

    Ken Slovak MVP - Outlook

    Friday, September 20, 2013 2:15 PM
  • Thanks Ken,

    I'm only posting this resolution in the hopes that it might help someone else.

    OK... I solved this immediate issue. The question is programming based. I developed an app in C# & VB.NET on VS2010 and got the following error when the app was trying to use the Outlook dll objects to send email:

    (I tried to upload the 48K image, but it wouldn't seem to allow me to upload?)

    ************** Exception Text **************

    System.InvalidCastException: Unable to cast COM object of type 'Microsoft.Office.Interop.Outlook.ApplicationClass' to interface type 'Microsoft.Office.Interop.Outlook._Application'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{00063001-0000-0000-C000-000000000046}' failed due to the following error: Error loading type library/DLL. (Exception from HRESULT: 0x80029C4A (TYPE_E_CANTLOADLIBRARY)).

       at Microsoft.Office.Interop.Outlook.ApplicationClass.GetNamespace(String Type)

    So my intent is pure... Now that I've resolved this issue. (The machines in question that were getting the error had the 32 bit version of office.) My application assumed that everyone had the 64 bit version (as we had recently replaced all machines with 64bit machines with 64 bit office - or so I thought). A few people were using applications that were not 64 bit compliant, so they had the 32 bit version of Office 2010. So if any developers get this error, check the version of office. I traced the referenced GUID's within the registry and compared them to another machine (where the app was working correctly) and found that the referenced library wasn't there (as it was a 64 bit Office 2010 library) -

    The Solution: I copied the contents of C:\Program Files\Microsoft Office\Office14 from a machine with Office 2010 (64bit) to the machine with the error. This resolved my issue. Eventually, I will modify the code to check for the version of office and run code that is appropriate for that version, but for now, this is a quick fix (as the issue was in production).


    Dan Barry


    • Edited by Danimal1 Friday, September 20, 2013 6:50 PM
    • Marked as answer by Danimal1 Friday, September 20, 2013 6:51 PM
    Friday, September 20, 2013 4:01 PM
  • What was your code?

    I've installed x86 versions of Outlook on both x86 and x64 Windows versions as well as x64 versions of Outlook on x64 Windows and I've never had a problem instantiating an instance of Outlook.Application using code.

    It doesn't matter where it's actually installed as long as it's registered properly at installation. You don't use the installation path when you instantiate the Outlook.Application object.


    Ken Slovak MVP - Outlook

    Friday, September 20, 2013 6:36 PM