i have two exe files sent by another team member. It is built using c# kode. One oracledataaccess dll file was also sent. (since the exe connects with oracle )-
When i try to execute the 32 bit ,
Unhandled Exception: System.NullReferenceException: Object reference
not set to an instance of an object.
when i try to execute 64 bit, i get
Unhandled Exception: System.BadImageFormatException: Could not load
file or assembly 'Oracle.DataAccess, Version=2.121.2.0,
Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its
dependencies. An attempt was made to load a program with an incorrect
format.
this is driving me nuts. i have installed oracle odac and oracle client.
Any thoughts ? i have zero knowledge in dotnet. my system is windows 64 bits.
hard to trouble shoot based on this info but with ODP you'll likely need to have your tnsnames.ora file in (for e.g 12.2) C:\oracle\product\12.2.0\client_1\Network\Admin , C:\oracle\product\12.2.0\client_1\bin , C:\oracle\product\12.2.0\client_1\odp.net\bin\4 . Add it there and restart and I hope you'll have some luck.
cheers, Dave
Related
I have an old program that was made for us a looong time ago. It consists of a large MDB (Access) file with all the data (no encryption, I can manually open the file and browse all the data) and an EXE file (probably VB?) that was custom made to easily manage the data in the file.
I'm trying to move this program for another user, to run in his own laptop.
First I tried just copying all the files, but I had MSCOM, GRD, LST, and ocx missing file errors. I tracked them all down and regsvr32'd them, and the program seemed to go a little further.
Then I got an ODBC connector error. Playing with ODBC sources manager and I added an entry with the name of the program that points to the specific MBD file. This helped too.
Now program starts and shows all menus, buttons and everything. However, the default record that should be onscreen is empty and as soon as I hit any control (next record, list, etc...) it crashes with a VB error 91:
Run-time Error '91': Object variable or With block variable not set
So it looks like the program can open the database file itself but it cant really access the data inside.
What else can I try to see what I need to set it all up correctly? Is there anything that "spies" inside and VB program to see how it's trying to access the MDB file?
Any help would be appreciated!
Probable cause of your problem is some missing dll/ocx file referenced in your application. Open your exe file with notepad (or notepad++) and find all occurrences of .dll and .ocx files and check if those
files exist at user's laptop. If not, just copy them from your working machine and regsvr32 them.
I will go with #smith suggestion.
While looking at the error message on microsoft's website, below is the solution that applies to your scenerio
"The object is a valid object, but it wasn't set because the object library in which it is described hasn't been selected in the Add References dialog box."
So ensure all files are correctly copied to new system.
Trying to do some work on an old FoxPro and VB6 legacy application and I've run into a brick wall.
The VB6 part of the application creates three .qpr file which, I understand, are just SQL queries. It then calls an external .fxp file, which is compiled foxpro code. I am not sure exactly what this is - however, I am assuming it to be a compiled version of an identically-named .prg file in the same folder, which contains the following code:
COMPILE "\\Count\Database\Sql_Result.qpr"
WAIT TIMEOUT 1
COMPILE "\\Count\Database\Sql_Total.qpr"
WAIT TIMEOUT 1
COMPILE "\\Count\Database\Sql_Query.qpr"
Those are the .qpr files which the VB6 app generates.
When you run this compilation command, it seems to do something. No error is thrown. Yet I can't see it's done very much.
What is the product of the above compile commands, and how can I find it?
The .QPR programs are nothing but a simple .PRG file with renamed extension. When the main VFP app calls the .qpr program, it just runs the query, the resulting cursor result is created and then VFP does with it whatever it needs to.
If your VFP application is compiled into an EXE, and the original underlying EXE was compiled with .qpr code, then the new versions of .qpr would not be impacted... but not enough to confirm the situation of your app design / implementation.
When I try to run my Visual C++ application, a box comes up saying "The application was unable to start correctly (0xc000007b)." The only output is
Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
But all of those files exist...which makes me think that its not the cause of the application's error. With no other output, I don't know what could be wrong. If anyone knows what I could check for or how to fix it, I would be grateful.
Few blueprints:
Rebuild the application, including all dependent DLLs, and try again.
Ensure all dependent DLLs, services (like MSMQ) are available and running.
Check if one of your DLLs DllMain is returing failure, which causes the application to start. OS won't start, if any of DLL returns failure while initializing.
Ensure you have correct CRT/MFC versions for the Debug/Release DLL you are using, or have linked other DLLs/EXE with.
Use Dependency Walker to find out of any DLL is missing, not found, or of different platform.
A colleague of min told me he read once that re-building opencv should fix this. Which worked for me. Notice I'm using opencv1.1(x86) under a win7 64-bit cpu.
Best of luck.
Hasan.
My project generates a dll and when build in Debug mode the dll gets registered automatically by Visual Studio 2005. But when I try to register the same dll in command prompt using "regsvr32" I'm unable to register. I get the following error,
The module ".."
failed to load. Make sure the binary
is stored at specified path or debug
it to check problems with the binary
or dependent .DLL files.
But I have all the dependent dlls in place. What could be the reason for this issue.?
I tried registering and unregistering the dll using the following command,
regsvr32 dll_name.dll
regsvr32 /u dll_name.dll
I just had the same issue.
If you're running 64-bit Windows and you've placed the 32-bit DLL in Windows\System32\ then it'll give you this error.
Simply place the DLL into Windows\SysWOW64\ and register it from there.
Here's where I found the fix:
http://csi-windows.com/blog/all/73-windows-64-bit/378-fixing-qregsvr32-the-module-failed-to-load-the-specified-module-could-not-be-foundq
The DLL might link to another DLL which isn't in the path when running regsvr32 from the command line.
First, you have to start the Command as a administrator.
Second, you didn't specify your dll file in which directory. If your operating system is 32-bit windows operating system, the regsvr32.exe's default working directory is C:\Windows\System32\.
you may get some help for your answers from here, here
I know its too late... but I am adding my solution for others because I faced the same error after following above mentioned answers:
"I just had the same issue.
If you're running 64-bit Windows and you've placed the 32-bit DLL in Windows\System32\ then it'll give you this error.
Simply place the DLL into Windows\SysWOW64\ and register it from there."
If you are facing same error after placing DDL to SysWOW64, then you need to turn on MSMQ feature.
Go to Start
Search "Turn Windows features on or off"
Find "Microsoft Message Queue(MSMQ) Server" and Enable it.
Now, register the same DLL again and this time it will be registered
This is a variation on the old
System.DllNotFoundException: Unable to load DLL 'foo.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E).
problem (where, of course, foo.dll is the name of an actual DLL). The strange part is that I only get this error when I "Run" in VS (2008 if that's relevant). That sits in the MyApp.vhost.exe processes.
If I run the actual app in a command line (MyApp.exe) I encounter no errors. The problem extends to unit tests with MSTest.
A check on the DLL with DependencyWalker on Foo.dll doesn't show any issues.
Any ideas?
Make sure the DLL is in the folder where your EXE is.