Could not load file or assembly 'Oracle.DataAccess' (x64) - c#

I am trying to create a WCF service to host in IIS.
My production and development servers are 64 bit.
The WCF service needs to be able to connect to a several different Oracle databases based on the client request.
I am using Entity Framework 5 with ODAC, and with the DbContext Initialiser, I have the option of providing a database connection to use.
private void ExampleSelect(string dataSource, string user, string password)
{
var connection =
string.Format("DATA SOURCE={0};PASSWORD={1};USER ID={2}",
dataSource, password, user);
using (var context = new OracleDbContext(new OracleConnection(connection)))
{
// do stuff here
}
}
The problem I have lies with new OracleConnection(connection). To use this line, I need to reference the x64 version of Oracle.DataAccess.dll
When I come to publish, I get the warning:
and the error:
The platform target for my project is currently 'Any CPU'. If I change this to target x64, I get the same error, but this time it refers to my project and not Oracle.DataAccess
Any of the above builds successfully on my development machine, I only get the errors when I come to publish.
What am I doing wrong here?
These solutions appear to be related, but they all refer to 32 bit Oracle Dlls:
Could not load file or assembly Oracle.DataAccess
Could not load file or assembly 'Oracle.DataAccess' 64 bit ODP.NET
Could not load file or assembly 'Oracle.DataAccess error
To rule it out, I have also tried installing both the 64bit and 32bit Oracle Clients on the development server, but I still don't get as far as even publishing so I'm not sure that the server is the cause of the problem.
The Enable 32 bit Application property on the Application pool in IIS does not make any difference, but I tried it anyway.

To eliminate your problem you must meet the following conditions. Since you want everything run in x64:
1.Make sure that you have installed 64-bit Oracle client software
2.Make sure that you using 64-bit Oracle.DataAccess.dll (use corflags to verify)
3.Make sure you build your application with x64 configuration
4.Disable Enable 32 bit Application on IIS pool
This is a common mistake by many people. They install 32-bit client and try to run x64 Oracle.DataAccess

Related

C# not reading registry values from Wow6432Node on Windows Server 2012 64-bit

I am moving three Windows Services (.NET 3.5) from Windows Server 2003R2, to Windows Server 2012 R2 (.NET 4.5).
The first two went well. Reading registry settings from
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MyCompany\MyApplication].
Now here´s the funny stuff - the third one only works when I store settings in
[HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany\MyApplication] (whitout Wow6432Node)?
And, if I try to run the service with settings in 32-bit registry it reads the settings ok but I get this assembly binding error instead:
System.BadImageFormatException: Could not load file or assembly 'Oracle.DataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342' or one of its dependencies. An attempt was made to load a program with an incorrect format. The other two, using the same dll, works fine.
Any ideas? What is different in the third Windows Service?
Since all applications using the same code to read the registry I don´t think that´s the problem. Her´s the code (simplyfied) anyway.
private string getRegistrySetting(string keyName)
{
string softwareSubkeyName = "SOFTWARE";
using (RegistryKey softwareSubkey = Registry.LocalMachine.OpenSubKey(softwareSubkeyName, false))
{
string lmSubkeyName = "MyCompany\\MyApplication;
using (RegistryKey lmSubkey = softwareSubkey.OpenSubKey(lmSubkeyName))
{
return lmSubkey.GetValue(keyName).ToString();
}
}
}
First, you need to make sure that all your executables have the target platform set to x86 (and not to AnyCPU) on the build tab of the project's property pages (caveat: this is a per-build-configuration setting, you need to set the target platform for both Debug and Release build).
Then you need to make sure that you also deploy the 32-bit version of any third-party components such as Oracle.DataAccess. The reason is that a 32-bit process cannot load a 64-bit dll and vice versa.
The target platform is relevant because it determines if your process will be started as a 32-bit or 64-bit process. If your executable runs as a 64-bit process Registry and file system redirection won't be in place - as a result your process will read and write directly to HKEY_LOCAL_MACHINE\SOFTWARE\ and not to the Wow6432Node subnode.

Could not load file or assembly 'Microsoft.SqlServer.DTSRuntimeWrap

I made a SSIS package that would export data to msaccess. If i try to run the package on its solution project it will execute without error. But when I call the package inside my program, I will get an error
Could not load file or assembly 'Microsoft.SqlServer.DTSRuntimeWrap, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'. This assembly was compiled for a different processor.
Here is my code:
public void RunPackage()
{
textstring("Locating Package...");
m_worker2.ReportProgress(20);
string PkgLocation;
Package pkg;
Microsoft.SqlServer.Dts.Runtime.Application _app = new Microsoft.SqlServer.Dts.Runtime.Application(); --> I got an exception here.
DTSExecResult pkgResult;
PkgLocation = Properties.Settings.Default.PackageLoc + "\"Package1.dtsx";
textstring("Loading Package...");
m_worker2.ReportProgress(30);
pkg = _app.LoadPackage(PkgLocation, null);
textstring("Executing Package...");
m_worker2.ReportProgress(30);
pkgResult = pkg.Execute();
textstring("Finished...");
m_worker2.ReportProgress(30);
textstring(pkgResult.ToString());
m_worker2.ReportProgress(30);
}
Can anyone point me out the right way. I don't know what is meant by that error. Please enlighten me?
That means, that you mixed x86 and x64 architectures. If your application is x86 (=32 Bit) architecture, you can not use x64 (=64 Bit) compiled assemblies. Try to compile your application with Any CPU or x64.
From MSDN:
To set the Platform target property (C#)
With a project selected in Solution Explorer, on the Project menu,
click Properties.
Click the Build tab.
Choose a CPU type from the Platform target list. The options are Any
CPU (the default), x86, x64, and Itanium.
Here is the complete Link: How to: Optimize an Application for a Specific CPU Type
Important: if you compile for x64 and use x64 assemblies, your application will not run under 32-Bit versions of Windows.
I recently upgraded to SQL 2016 and my VB app stopped running my package. I saved the package no problem to SQL 2016. VB wouldn't run it via the LoadFromSqlServer method. Just reported Could not load file or assembly 'Microsoft.SqlServer.DTSRuntimeWrap' What fixed it for me was to delete the old 12.0 manageddts reference and adding the new 13.0 reference (see image)
Depending on your version of SQL Server Data Tools that is installed on your system, you must add a specific version of Microsoft.SqlServer.DTSRuntimeWrap in your C# Application.
For example if you have SQL Server Data Tools 2010 installed you must add Microsoft.SqlServer.DTSRuntimeWrap 11.0.0.0, and for SQL Server Data Tools 2012
you must add Microsoft.SqlServer.DTSRuntimeWrap 12.0.0.0

Class not registered error from PHP

We've created a C# class library assembly and made it COM visible to be able to call its methods from PHP. This used to work fine, but now we wanted to install it on a Windows Server 2008 server and we keep walking into the error "Class not registered".
To rule out any dependency problems I made a tiny little test class library in C#. The class library is built for Any CPU and it is COM visible (also set COMVisible to true in AssemblyInfo.cs). The test class library only contains one class with one method. The class is called TestLib and the namespace is also called TestLib. The method is called Test and only returns a string.
What we have done is the following:
- built the TestLib.dll
- copied it to the Windows Server 2008 machine
- registered the dll with: regasm /codebase TestLib.dll
- the regasm tool returns a success message
- in PHP we simply try to create a new COM instance:
try
{
$test = new COM("TestLib.TestLib");
}
catch (Exception $e)
{
die($e->getMessage());
}
when we call this test script from either the browser or the commandline (php -f test.php) we get the error "Class not registered" in both cases
I also tried adding TestLib to the GAC by using gacutil -i, but to no avail; still the class not registered error.
Then I tried compiling the testlibrary with .NET 2.0 instead of 4.0 as the target framework, same result. The .NET framework 4.0 is installed on the server by the way.
Any ideas?
Okay, so after some more research I figured it out. The php.exe process is 32 bit. The COM visible assembly is compiled for Any CPU so it should be accessible to both 32 and 64 bit applications.
The problem is that on a 64 bit OS php.exe, and any 32 bit process for that matter, searches in HKEY_CLASSES_ROOT\Wow6432Node\CLSID instead of HKEY_CLASSES_ROOT\CLSID and in HKEY_LOCAL_MACHINE\Software\Classes\Wow6432Node\CLSID instead of HKEY_LOCAL_MACHINE\Software\Classes\CLSID. The registry entries in the Wow6432 keys aren't created by regasm that is shipped with .NET framework v4 on Windows Server 2008. On Windows 7 they are created, don't ask me why.
It also turned out that if I create a little test assembly for .NET v2.0 and register it with regasm that ships with .NET framework v2.0 that it does create the Wow6432Node entries on Windows 2008. Strange.
So my solution is to create a basic registry file on the server using:
regasm /regfile MyClassLib.dll
This creates a file MyClassLib.reg with only the 'normal' 64 bit entries. Then I exported the Wow6432Node keys from a Windows 7 machine and added it to that .reg file. Now when I import that reg file into the registry on Windows 2008 everything works fine.
For more info on the Wow6432Node entries check out: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724072%28v=vs.85%29.aspx
Hope this saves someone else some time and headaches.
If you are trying to call a 32-bit COM DLL on 64-bit Windows, you will need to register it.
Copy your 32-bit DLL to C:\Windows\sysWOW64
Run C:\Windows\sysWOW64\regsvr32.exe your_com_32.dll
A bit more info with screenshots.

c# OPC Automation gives 80040154

I am a .Net developer. New to OPC. When I tried some samples of OPC Client all of them give this error. It seems the DLL is not registered it seems. But I don't know how and where to register this.
error: retrieving the COM class factory for component with CLSID failed due to the following error: 80040154
Even I tried this
regsvr32 Interop.OPCAutomation.dll",
but it also throws error like
The module "Interop.OPCAutomation.dll" was loaded but the entry-point DllRegisterServeer was not found.
Make sure that "Interop.OPCAutomation.dll" is a valid DLL or OCX file and then try again.
I have gone through so many existing forums. So many of them said to change the Platform Target to x86 and still I am having the same issue. FYI, I can see only see 'Active (Any CPU)' in the Platform option from the top of the Build tab of Project Properties.
Here are my environment details:
.Net 2005
OPCAutomation Weapper
Windows 7 64-bit OS
Dell Inspiron 1525 (I hope this is not a 64bit machine, but my engineer installed 64bit OS somehow).
Please help me.
Thanks in advance!
Just in case somebody is dealing with this problem (as I've recently been...) I get through it! After some time, I found out that it's something about the .NET framework running on 64-bit machines. As long as the.NET application works only with 32-bit CLR, we must set .NET framework to load CLR in WOW mode. To do so, type:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe SetWow
After this you should be able to run the applications.
You can go back and revert .NET Framework as it was before by typing:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe Set64
If the OPC Client Toolkit SDK (C++) is used, a problem with the remote registry service may cause this error as well.
On Windows 7, by default the Remote Registry service is set to manual and not started. Ensure that the Remote Registry service is started on all of the machines you want to deploy to. This can be done manually or using Group Policy.
The function GetCLSIDFromRemoteRegistry() uses the RemoteRegistryService in order to get the CLSID of an OPC Server. If this service is not started on the client machine, the OPC program may return the error 80040154.
The error you're getting is more than likely due to the OPC server not being properly registered. Make sure it is registered (usually by running it at the command line with a "/regserver" or "/service" parameter). There may also be security issues in which case you'd have to run 'dcomcnfg' (DCOM Config) to make sure the client has access to the server.
This question is a bit dated so I hope you figured it out by now, but I had the same exact issue and wanted to share my solution. In my case, I am using a Kepware server. If you compile and try to run a client application for this server using Interop.OPCAutomation on a machine that does not have the server installed, you will get a dll not registered error and "entry point not found" if you try to register the dll manually.
Solution: Make sure you've got the server installed and running.
Although this is an old post, I would like to share my solution.
My problem was that when I tried to install an application with the OPCAutomation.dll, it gave me 80040154 error because the class was not registered.
This is my solution, always with Administrator privileges:
Copy OPCDAAuto.dll into the "C:\Windows\System32" folder
On the cmd prompt type "C:\Windows\System32\regsvr32 opcdaauto.dll"
You should watch a message like this one:
image
Hope this helps!
The OPC dll only works in 32 Bits, my solution was to change the "Enable 32-Bit Applications" to True in the advanced settings of the relative app pool in IIS.

Process.Start("telnet.exe") throws exception

I have two applications running on W2k8 R2 x64, one is compiled as 64bit and the other one as 32bit as it has COM dependencies.
In both I'm trying to call:
Process p = Process.Start("telnet.exe", string.Format("{0} {1}", address, port));
In the x64 it works perfectly fine, however in the 32bit one I get a System.ComponentModel.Win32Exception ("The system cannot find the file specified")?
Any idea what's going on here? Even if I call
Process.Start(#"C:\Windows\System32\telnet.exe")
I get the same exception?
Thanks,
Tom
To launch a system32 located 64bit app from a 32bit app (at least on Vista,2k8,7, doesn't work on x64 XP or 2k3) run it from the sysnative directory, i.e. "C:\windows\sysnative\telnet.exe" (alternatively disable Wow64 but that is generally a bad idea).
This drove me crazy... had one project that would find "telnet.exe" without the full path and one that refused to find it (even with the path, or never figured it out). My dev machine is 64-bit.
The problem was the target platform in build.
If it's set to x86 it will not find telnet.
set it to Any CPU it will find telnet.
sometimes you need to set it to x86, this allows your applications to see 32-bit drivers (such as odbc drivers) on 64-bit platforms
Windows Server 2008 does not have a 32 bit telnet.exe client. It only installs a 64bit version in the windows\system32 folder.
\live.sysinternals.com\tools\procmon.exe and/or procexp always has the answer.
Have you looked at the path environment variable in the context of your process? Can you prefix it with the System\SysWow64 path to make it work?
copy telnet.exe to SysWow64 folder

Categories