I had a C# program that did some Word & Excel automation and it used Office 2003 Primary Interop Assemblies. The way I deployed it was by including the Interops in the bin and I had my program reference it from there as opposed to referencing it from the GAC (not very professional, but it worked fpr years). Recently on 3 machines the office 2007 compatibility pack was installed and now when ever my software trys to invoke Word or excell I get an error that:
Unable to cast COM object of type Microsoft.Office.Interop.Word.ApplicationClass to interface type Microsoft.Office.Interop.Word.Application, This operation failed because the QueryInterface call on the COM component for the the interface with IID {00020970-0000-0000-C000-000000000046} failed due to the following error: Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
After some searching I noticed that installing the compatibity pack Word11 and Word12 were both installed in the GAC and the same with Excel.
I attempted to have my program reference the Word11 interop in the GAC and still no help.
I unstalled the Word12 interop and still no help.
It seems that installing this seemed to have changed some registry setting or something that my software is confused cannot find the correct library.
Anybody have some ideas?
I recently had this issue with word too and I tracked down this registry key as the culprit
HKEY_Classes_Root\TypeLib\{00020905-0000-c000-000000000046}\8.4
Apparently this tells the word to use word 2007 introp assemblies instead of Word 2003 (8.3). At least I think I am not too familiar with office introp assemblies. I delete the registry key and everything worked as normal. I do not know of any adverse effects from deleting this key, but definitely back it up.
I've worked around this by copying the earlier versions from the GAC to our Third Party libraries folder, and reference them there -- also means you can build against 2003 with only 2007 installed. (and yes, I know this is a really dirty hack)
Related
Visual Studio 2012
VB.Net
.NET 4.0
Build Machine x64
Build Config AnyCPU
msado27.tlb
This project is not new and has been built 100s of times over the past 2 years. With in the past 3 weeks something has changed and a COM reference to the Microsoft ActiveX Data Objects 2.7 library is no longer able to registered. When I try to reselect it from the available COM entries it is visible and selectable.
Com reference list
After selecting you can see the yellow triangle
reference tree node with yellow triangle
Then viewing it thru the its properties you can then see there is no path being shown.
reference properties
When viewing thru the project properties -> references it display
project properties references
If I select a newer version such as 2.8, 6.0, or 6.1 they will register. However if I select an older 2.5 it acts the same way.
Any suggestions or theories on what may have happen or how to verify if the .dll in the GAC or Primary Interop Assembly actually has definitions and or implementation for version 2.7?
And by the way I do realize that this is an extremely old version, but this current .Net project has additional COM references/dependencies which rely on this particular version and I am unable to switch to a newer version at this time.
Well after a painful day and a lot of wasted time I decided to go the route of re-registering the types again using regasm which I didn't think really had a chance of fixing the problem. Low and behold that was the problem.
The fix for me...
Open the developer console for VS2012 as Administrator
Navigate to the GAC area for your adodb.dll #
%windir%/assembly/gac/adodb/7.0.3300.0__b03f5f7f11d50a3a
Then run the command "regasm adodb.dll" and you should receive the
"Types registered successfully" message
Return to VS2012 and all current references to
Note: Early on when reviewing the registry values for the type libraries found in the adodb.dll file I noticed that the version that would not register in VS (2.7, 2.6, and 2.5) did NOT have Primary Interop Assembly value for there keys as the newer versions did. After running regasm those value were added in for the older versions.
Shows primary interop assembly info for v2.7 after running regasm
I have an EXE in VB6 that calls a recently upgraded to VB.Net DLL. This part is working fine, but the issue that I am running into is related to locating the interop of another COM DLL the VB.Net DLL references.
An overview: EXE (VB6) calls method A of DLL (VB.Net), no issues. Method A of DLL calls method B of third party DLL (COM), it gets an error of not being able to find the interop file of the COM DLL.
I have tested directly in VB.Net using a test UI to call the same method A in the VB.Net DLL, and everything works fine. I am currently at a loss as to what is causing the issue.
Thanks,
Chris
I have finally found the answer to the issue. All said and done, the issue was that the interop assemblies were framework version 4.0 instead of framework version 2.0. Visual Studio created them this way for some reason, so I had to change them by using Visual Studio 2008 to create new versions of them.
The process to find this out (which most of is already stated above, but repeated here for helpfulness) was to place all my VB.NET dlls and the interop assembly dlls in the directory of the VB6 exe. (I created sub folders for each one for easier cleanup later.) This still resulted in the same error, but the assembly builder log showed a different reason for the error. This time it was able to load the assembly without issue, but was not able to complete the setup of the assembly.
Researching this led me to the idea of checking the framework versions of the interop assemblies using ILSpy to find out they are version 4.0 while my dlls are version 2.0.
Initially I tried recreating them in Visual Studio 2017, since my project uses framework 2.0, but it still created them as framework 4.0 for some reason. I then tried in Visual Studio 2008, and it was able to create the correct framework 2.0 versions of the interop assemblies, and now everything works as expected.
I'm following the excellent tutorial by Malte Ahrens on how to create a OneNote add-in.
Initially I followed it step by step, making a few changes (just renaming the class, and using my own name and GUID in the assembly) info. As I'm using VS2012 and am not yet ready to hand-roll a WiX installer I manually copied over the built dll to the correct place and also created a registry file to make the requisite entries. I confirmed that they were all there, loaded up OneNote but no add-in, going to "mange COM addins" section I saw the following error:
Load Behavior: Not loaded. A runtime error occurred during the loading of the COM Add-in.
I spent some time debugging this but didn't get very far. So this afternoon I decided to start again but copy his code verbatim. I simply downloaded the example project, used the trial of Vdproj to Wix to create the installer and built everything.
I get the exact same error.
Why is this please? What does this mean and most importantly how do I debug the problem?
A few specifics about my environment and where it may differ from the original tutorial.
I am running Office 2013 AND it's 64bit. His tutorial is for 2010. This means when I loaded up the demo solution I had to remove the non-existent reference to the Onenote 14 Interop and add the v15 version.
In terms of registry entries they go to the right place, not the WOW6432 registry nodes. I doubly know this as if I load up OneNote and then refresh the HKCR registry node for the add-in, the LoadBehavior switches to 0x00000002, (disabled).
Other things that may be worth noting.
I have enabled OneNote logging and it's quiet on my issue.
There are 2 other posts on here with a seemingly similar problem (but Office 2010) here and here, neither got a response. The first guy had it loading once, but then had to manualy start it each time, mine never loads (and I've not signed my assembly) the second guy never got a response.
As I say, even knowing how to debug this further would be a great step forwards.
Edit:
I've gone back to debugging my own version, which is almost identical anyway as I'm not sure what the installer is actually doing and I think because it's a demo of the wix converter it's only allowing me to build for x86.
If I add OneNote.exe under "start external program" and run debug on my add-in, I see the following lines appear when I try and tick the add-in under "manage COM add-ins" within OneNote. I'm afraid I'm still pretty green at all this so I'm not sure what it means.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
First-chance exception at 0x00007ffe4f86ab78 in ONENOTE.EXE: 0x800401FD: Object is not connected to server.
Also, since reading up more I think me simply copying my dll into the install folder program files\[manufacturer]\[application] (as I don't have an installer) was not enough. I've now executed this against my dll
PS C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319> .\RegAsm.exe
and it came back with
Microsoft .NET Framework Assembly Registration Utility version 4.0.30319.33440
for Microsoft .NET Framework version 4.0.30319.33440
Copyright (C) Microsoft Corporation. All rights reserved.
Types registered successfully
Is there anything else I should be doing to register the dll correctly?
Enable logging for OneNote 2013:
Create a file "EnableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000001
"EnableTextFileLogging"=dword:0000001
"ttidLogObjectModel"=dword:00000001
"ttidLogObjectModelAddins"=dword:00000001
Create a file "DisableOneNote2013APILogging.reg"
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\OneNote\Options\Logging]
"EnableLogging"=dword:00000000
"EnableTextFileLogging"=dword:0000000
"ttidLogObjectModel"=dword:00000000
"ttidLogObjectModelAddins"=dword:00000000
This is based on http://blogs.msdn.com/b/descapa/archive/2006/12/08/debugging-the-onenote-api-enable-logging.aspx but you need to add EnableTextFileLogging ;-).
The logfile is created in %temp%\OneNote.log
For OneNote 2010 change the path in the .reg files to \14.0\ instead of \15.0\
I am currently trying to build on TeamCity, which uses Microsoft.Office.Interop dll. This will build and work fine locally as I have Office installed, however when trying to build it on TeamCity it fails as it has no reference.
I can't install the PIA distributable as I get an error message saying the Office 2003 is required to be installed. I don't want to install Office on the server.
Is there any way to get around this?
If all the teamcity server is doing is a build, then add the Microsoft.Office.Interop DLL to a References folder for your project, and then configure your project to look in that references folder.
However, if the TeamCity server is also running tests that use Office Interop, then you will run into problems unless you have Office installed on the machine running the tests.
Not really - the Interop dll is only a thunk layer between your .NET code and the actual (COM) Office code. If you have the Interop dll without the underlying Office dll, then any calls into the Interop will fail because the Interop will want to call the COM objects it's making interoperable.
Those COM objects are Office objects, so you will need some part of Office installed.
I have a third party COM dll that I'm trying to add to a vb.net (2008 express) project. I put the dll in C:\WINDOWS\system32\ and registered it with "regsvr32 vxncom.dll". When I go to projects > add reference and go to the COM tab it shows up in the list of available components/libraries. But, when I select the library and hit ok, visual studio complains: "A reference to 'vxncom 4.0 Library' could not be added. Could not register the ActiveX type library 'C:\WINDOWS\system32\vxncom.dll'."
The project I am doing this in is an example provided by the folks who distribute the dll. The component also fails to be added when I start a new (blank) vb.net project.
UPDATE 1:
I ran dependency walker on the dll in question and here's what I got in the error log:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
The module in question seems to be libeay32.dll, but it already exists in C:\WINDOWS\system32.
UPDATE 2:
I went to the openssl site and downloaded and used their installer to update the libeay32.dll. I ran dependency walker again on vxncom.dll, and there were no errors. Went back to visual studio and it still didn't want to add the reference. Exact same error as before.
Maybe the DLL VB is trying to register depends on another DLL that is not present. You can confirm this (or rule it out) by using the free Dependency Walker tool from http://www.dependencywalker.com/
RESPONSE TO UPDATE 1:
Sounds like there's a mismatch between the version of libeay32.dll that's installed on your system and the one that your component is expecting -- depends is saying that your component is looking for a function that isn't there. I would check the version number of libeay32 and then contact the vendor and ask them what versions they support.
Just a thought - you may get a more detailed error message if you create your own PIA using tlbimp.exe, rather than relying on the IDE to do it for you.
Assuming you haven't fixed it or have moved on to alternatives; and following on from jeffm's answer is libeay32.dll properly registered with the operating system? Re-installing / repairing usually fixes that type of problem (I see it a lot with MS Office and MapPoint where the COM objects occasionally unregister themselves for one reason or another.)