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
Related
My end users cannot install .NET framework on their systems due to restrictions they face, so I was looking for another solution to where they could use my software.
I ended up bumping the target Framework down to 2.0 from 4.5.1 and it worked with no issues on their computers.
HOWEVER, I get a bunch of "warnings" in Visual Studio about
Warning 12 The primary reference "Microsoft.ReportViewer.WinForms, could not be resolved because it has an indirect dependency on the framework assembly
though it doesn't stop the program from compiling or running.
I distribute the program by placing the output of my debug folder in a share folder on a server so they can run it without installing.
Will there be any consequences to using an older target framework? What's the highest framework I can use in order to avoid installing it, in other words, what's the highest framework that comes stock with Windows 7?
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'm working with some application handed over by another person in which I must document the requirements, build and deploy processes.
The problem here is that Visual Studio (2005) is throwing a lot of errors since it can't find the references for the dlls.
This obviously won't let VS build the project.
Everything works fine on the persons computer but not on mine, even though the project references the same folder where the dlls are, the bin folder.
How can I circumvent these problems and get VS to properly reference the dlls?
The following printscreen shows the references screen for the project.
My guess is that your DLL uses a more recent .NET framework than your application does.
Check the properties for your DLL source (right-click on the DLL code in the solution explorer and choose Properties). Go to Application - Target .NET framework and compare the version to the one the application itself uses (right-click on the project code). Note: under your application properties check both the settings under Application - Target .NET framework AND under Publish - Prerequisites.
For what it's worth, even after changing the .vbproj file and removing many lines about hard coded values,
I eventually checked out the project again removed all references to the given DLL and then added it using the GUI.
Lesson learned, don't try to change out one DLL for a newer version without using VB2005 GUI.
The easiest solution will probably be to transfer everything to another project. It will be incredibly time consuming to find where visual studio has left the hard coded path at.
WOOT!!!! Compile the DLL file to a lower version of the .NET framework, and it will fix the problem!!!!
The paths in the project file cannot be the same or the assemblies referenced have a different version.
It might be worth unloading your project and the editing it to inspect where it's looking and for what version.
I had the same problem with an older Visual Studio Project that I opened in Visual Studio 2008. I tried to add new references to the project and got permanent errors that the dll's cannot be found. After the migration of the Project to Visual Studio 2010 I got the following error message when I tried to add a new reference:
'mySample.dll' or one of its dependencies, requires a later version of the .NET Framework than the one specified in the project. You can change ...
After changing the projects .NET Framework to a newer version everything works fine.
Good suggestions in other answers. In my case, it was because the libraries weren't copied (downloaded) successfully: the files existed, but were 0 kB.
Did a clean, which removed all the DLL's and then VS2008 complained it couldn't find the references (Duh!!!) and wouldn't rebuild....luckily I had and old version of the dll's and replaced them in the directory AND THEN did a rebuild to replace them...all references are now OK and we're back to normal....good old VS 2008
I am having a strange problem since installing the latest version of ODAC, 11.2.0.2.1. I installed both the 32-bit and 64-bit versions because I develop applications for both architectures. My computer is Win 7 64-bit.
Since installing ODAC and referencing the new 64-bit version of ODP.NET, one of my web application projects in Visual Studio 2010 gives the following warning for all aspx pages and masterpages when I view them in Markup View.
ASP.NET runtime error: Could not load file or assembly 'Oracle.DataAccess' or one of its dependencies. An attempt was made to load a program with an incorrect format.
The warning is limited to Markup View. The web application builds and runs fine. I tried cleaning the VS Temporary ASP.NET Files, but that did not fix the issue. I removed all references to Oracle.DataAccess throughout my application, and then readded them to be sure that all the references were correct. The web app is compiled to 'Any CPU' but it uses the 64-bit Oracle.DataAccess. I created a new project, and referenced the same projects and dlls, and I do not get the warning, so it appears to be specific to this project file.
Any ideas why I would get the warning when in Markup View?
Expressly set the "Platform target" to "x86" or "x64" in the project properties --> Build tab.
Do NOT set it to "Any CPU." This is one of many common conditions which causes this driver of typical Oracle software quality to have a nervous breakdown.
Turns out the ODAC 11.2.0.2 xcopy installer doesn't correctly register all of the dlls (See bottom answer). As a result, Oracle.DataAccess.dll (64bit) was being copied into the BIN directory, and VS was trying to load it when in Markup View causing the warning. After manually registering the missing DLLs and rebooting, I am no longer having the problem.
Ideas you can check:
Check the Oracle.DataAccess reference in your Visual Studio project has the 'Specific Version' property set to 'False' (this is not the default).
Use the Fuslogvw.exe to determine what are the locations the .NET Framework is trying
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)