I have an Oracle.DataAccess 2.112.1.0 version referenced in my project. Whenever I run the project I get an error Could not load the assembly. I checked the entries made in the .csproj file for the referenced dll, and found that the referenced dll was Oracle.DataAccess 2.111.7.0. I am pretty sure the referenced dll is Oracle.DataAccess2.112.1.0 but not sure why the entry made in the project file is different. Any pointers to this would be helpful as this issue has been holding me up for a long time.
I found the same issue when a client use 2.112.1.0 in their references, but it kept referencing a machine local 2.112.3.0.
The reason is that when installed in the GAC, it inserts a policy file - a GAC level config entry to redirect your DLL to their newer version. Even if you have the file in the same dir, .NET 2+ will check the GAC for any policies before allowing your application to resolve the assembly itself.
Something I tried was a manual redirection in your App/Web.config file, but I found this didn't work for me, which is detailed under Redirecting Assembly Versions.
Once this is done, you may encounter this issue:
BadImageFormatException - Image is not of correct format (or something similar)
and/or
Version mismatch - The major/minor version does not match (or something similar)
These errors indicate that although your older assembly is now in use, the COM assemblies it reference are not expected. My investigation found Oracle ODP.NET assemblies stores its COM DLL versions hard-coded within.
The only solution that did for me, was to
Un-GAC the 2.112.X.0 that your app was auto-referencing.
Copy the version specific COM DLLs to a different directory (like \LIB)
Copy them into the build, as you build
If this all fails, I would recommend completely uninstalling the Oracle ODP.NET, deleting the Oracle directory manually and then after rebooting, installing the old DLL from the MSI directly. Oracle seem to have stored the whole history of drivers online at Oracle's website.
Good luck!
Related
I have a C# project using MySql.Data and EntityFramework, and have used the Data Entity Model Wizard to create code based on an existing database. I created the project on a machine running MySql Server 8.0.25 (where I cannot control the installed version), so all my references for MySql packages are also version 8.0.25.
When I moved the project onto my own machine, running MySql Server version 8.0.31, the project successfully builds but has an error message, which Visual Studio says comes from a .edmx file:
Error 4: Could not load file or assembly 'MySql.Data, Version=8.0.31.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) ... ScheduleModel.edmx 7
The file in question only contains the text "MySql.Data" in one place, and that's an un-versioned reference to "MySql.Data.MySqlClient", on line 7.
Since the project builds and appears to run correctly, I don't know if this error affects anything. Regardless, I would like to understand it and why it happens and ideally make it go away.
Here's what I've learned form searching for an answer and trying to investigate/fix the error:
There are no references to version 8.0.31 anywhere in my project, as using Visual Studio to search the entire project for "8.0.31" found no results.
Answers to others' questions tell me the version number in the error message specifies the version of a file that Visual Studio DID find. (Whereas I would have thought the given version number is the one that it is LOOKING for.)
Several places said that the found version is probably in the GAC. Originally, the error message said MySql.Data.EntityFramework (not just MySql.Data), and I did find MySql.Data.EntityFramework in the GAC. (No idea how it got there.) After removing it, the error message changed to just MySql.Data. However, MySql.Data is not in the GAC, and no MySql.Data.* are still there either.
There's a tool called fuslogvw.exe that supposedly can help with this issue, but I could not get it to work. When I run it, there is nothing in the log. When I click on options, all options are grayed out. The one person's recommended registry edit did not work either. (I tried closing and re-opening Visual Studio after said edit, then re-building.)
Process Monitor tells me that, during the build process, no processes accessed any files that include "MySql.Data" in the name except those under packages/MySql.Data.8.0.25 and the project's output directory; all files are version 8.0.25. This appears to conflict with #1, because how can Visual Studio have found version 8.0.31 if it never accessed any such file?
I tried using bindingRedirect in App.config to redirect from 8.0.31 to 8.0.25, which had no apparent effect.
Cleaning the solution and re-building ends up putting MySql.Data version 8.0.25 back into the output directory, so Visual Studio clearly is finding the correct version.
Deleting the packages folder results in everything being replaced (with the right version, again) but the error message persists. (The rebuild was strangely fast; I'd have thought everything would have to be re-downloaded, but it was too fast to have done that.)
How would I diagnose this issue? What might be causing Visual Studio to look for or to find a version that I cannot find any reference to, or any .dll file for?
I'm using Visual Studio Community 2019, Version 16.11.2.
I have a C# 4.0 application that is referencing a type library from a C++ application. This is used for some secure COM interop, a question I originally had asked here.
On my development machine this second application is installed so I can compile without any issues. If I attempt to compile on our automated build server, or any machine with Visual Studio installed but without this second program, I receive the following errors and compilation fails:
Text for google:
The type or namespace name could not be found (are you missing a using directive or an assembly reference?)
Cannot get the file path for type library "guid...." version 1.0. Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))
The referenced component 'SecurityAgentLib' could not be found
Picture for readability:
I'm not sure how to get around this other than by installing the application that registers the actual dll that implements these types, but I don't want to do that on our build server. The code that uses these types are wrapped in a class that is never instantiated unless prerequisite checks are run to verify the app is actually installed, so there is no chance of a runtime error. In fact I can run my app just fine on a machine without the second app installed - I just can't compile it there.
In visual studio the reference points to the .tlb file which is included in the solution directory, so the tlb file itself is present.
I can't imagine it should work this way, and I've searched around, but I'm apparently not searching for the right terms.
EDIT:
Running tlbimp.exe generates a dll but the type library should be sufficient for compilation, I thought at least. There is also an issue of broken references. I was reading this article Troubleshooting Broken References and it says that if the reference was to a COM component that is not installed than installing the component corrects the error, which is true.
Installing it on the build server really isn't an option. Opening visual studio and re-adding a reference if the path was broken doesn't work either.
I was able to use tlbimp to create a dll and used visual studio add a reference to that dll. That let me compile, but how would this work in an unattended build server?
EDIT
Okay I came up with two solutions that worked given my requirement of this all being unattended
Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.
In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.
I also removed the tlb and added the dll in visual studio and did a diff on the .csproj file. I don't see any downside to just having a reference to the dll instead of the tlb but if needed the build server could make modifications directly to this file to remove the tlb section and add a reference to the dll following a build of the second product.
Here are a couple options that each worked.
Ran tlbimp to create a dll from the type library. I removed the reference to the tlb from my project and added a reference to the dll itself. When the source code was copied over to a new computer it compiled without issues.
In this scenario ideally we would checkout from SVN on the build server and copy the latest DLL from the second project, then compile this project.
I also removed the tlb and added the dll and did a diff on the .csproj file. I don't see any downside to just having a reference to the dll instead of the tlb but the build server could make modifications directly to this file to remove the tlb
I would like create a MVC3 website. I have existing dlls packaged as .net MSI which are installed into the GAC. What is the best way to reference these update-able dlls in MVC3? They will always be installed into the GAC, their version number will be updated accordingly. I don't want to have to manually reference them in my MVC3 project, as every time I re install, the reference will break and I have to update my dependent dll references.
Any input would be appreciated. I have looked around for solutions already but nothing seems straight forward.
Thanks
You haven't found a solution because there isn't one. In order for an assembly to be installed into the GAC it must have a strong name. Every application that uses assemblies from the GAC are tied to the given version and strong name (and this no matter whether you statically referenced the assembly at compile time or used reflection to load it). If you modify it in the GAC clients no longer work and should be updated accordingly. So if you intend to often modify versions of the assembly the GAC is probably not the right place for you. You could still make changes to an assembly in the GAC without modifying its version but you must ensure that those changes are compatible in order to avoid breaking clients.
We recently put out an update of one of our apps with a "test" DLL from a third party. The third party does not update their assembly versions on the dll's, only the file versions, so multiple apps can reference different "versions" of it. However, the GAC still allows us to keep the newest version, because it also checks the file version which is always updated.
What happened is we were not ready to release this DLL, but it got out there on some customer machines. I would like to put our current live version back out there, but it has an older file version (and the same assembly version) as the test DLL. We have multiple apps referencing this DLL, so I can't simply delete it and drop in the new one.
Is there a way to replace the DLL in the GAC? I'm using installshield 2009. Perhaps some sort of custom action upon install?
Could you do following
Verify with respect of gacutil.exe /lr that there are no reference to the old version of the DLL
Verify that there are processorArchitecture information about the old version of the assembly in MSI package. (see http://community.flexerasoftware.com/showthread.php?t=154839&page=2)
Verify that old version of your DLL will be removed during deinstallation.
Look at http://kb.flexerasoftware.com/selfservice/viewContent.do?externalID=Q111094
I'm using VS2005 (haven't moved to 2008 because I'm still using some legacy tools) and have a question about the way project references work.
If I make a project reference to a project that has been deployed to the GAC, VS will use the assembly in the GAC. This is annoying when I have older code in the GACed assembly and I am making code changes and doing quick tests against them - I have to either GAC the new code every time, or remove the assembly from the GAC so VS can't get it from there.
Is there a way to defeat this behavior?
Can't you just change the reference, pointing to the DLL directly?
Better yet, if you changing your DLL, use the Project as reference instead of the GAC DLL?
The best way around this is a two step proces.
1.) In your GAC'ed DLL upgrade the minor version number. (1.0 to 1.1)
2.) Update the project reference to copy local, and use the new version number.
This "SHOULD" get it working, but with the GAC it isn't always 100%.
You could go the route of a policy file, to stop the GAC from loading....but that gets way more complex.
Copy the reference locally.