Connection to Oracle using Oracle.ManagedDataAccess exception - c#

I'm using the Oracle.ManagedDataAccess Nuget Package Version 12.2.1100 in my C# (>.NET 4.0) project. Everything works ok in my localhost but on the dev server I'm hit with this exception:
Exception Message: ORA-12154: TNS:could not resolve the connect identifier specified
Exception Source: Oracle Data Provider for .NET, Managed Driver
Now I thought the ManagedDataAcess contained everything I needed. Am I missing something else? Is something else interfering with the package? Do I need to add something else?
Note: there is no <oracle.manageddataaccess.client> tag in my Web.config
Code:
<connectionStrings>
<add name="XXX" connectionString="Data Source=XXX;User ID=XXX;Password=XXX" />
</connectionStrings>
EDIT:
I've confirmed that the TNS_ADMIN variable is set within Control Panel but that didn't seem to do the trick.
I then added the tnsnames.ora file to the bin folder and I've got it working but it isn't a long term solution.

Your program does not find the tnsnames.ora (resp. sqlnet.ora) file. There are several possibilities to specify the location.
Define it in .NET config file (web.config, machine.config, application.config)
Set environment variable TNS_ADMIN
Copy tnsnames.ora, sqlnet.ora files to directory where your application .exe is located.
Example for .NET config file:
<oracle.manageddataaccess.client>
<version number="4.122.*">
<settings>
<setting name="TNS_ADMIN" value="C:\oracle\network\admin"/>
</settings>
</version>
</oracle.manageddataaccess.client>
Note, unlike other drivers/providers the ODP.NET Managed driver does not read the TNS_ADMIN setting from Registry.

You probably don't have TNS configured, which is why that form of connection string isn't working. You don't need TNS configured if you use a different form of connection string, ex:
Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=MyIpOrServerName)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=MySID)));User Id=MyUsername;Password=MyPassword;
Replace all the My* placeholders with your values.

We were seeing similar issues in one of our environments and the following solved our problem;
When Oracle Data Provider for .NET is installed on a web server and depending on what you select during install, it writes entries into the machine.config file (located at C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\ depending on the framework version). It seems different versions of the ODP.NET installer do different things to the machine.config (some of our servers have no version number specified in the machine.config and others have a specific version number specified for the oracle managed client)
Depending on the version installed, it adds a couple of lines like this:
...
<section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
...
<oracle.manageddataaccess.client>
<version number="4.121.2.0">
<settings>
<setting name="TNS_ADMIN" value="C:\oracle\client\product\12.1.0\client_1\network\admin" />
</settings>
</version>
</oracle.manageddataaccess.client>
...
The entries contain a specific version number referring to the ODP.NET oracle client version.
We are building our applications with version 4.122.1.0 of the managed client library (Version 12.2.1100 nuget package) which doesn't match 4.121.2.0
We changed the above entries by removing the oracle managed client library version from this tag:
<section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess" />
And specifying a '*' for the version number for this tag:
<oracle.manageddataaccess.client>
<version number="*">
<settings>
<setting name="TNS_ADMIN" value="C:\oracle\client\product\12.1.0\client_1\network\admin" />
</settings>
</version>
</oracle.manageddataaccess.client>
If you need specific version numbers specified then ensure your code is compliled with the same version numbers.
You can also remove all these entries from machine.config if they are there and specify them in the applications web.config depending on your configuration.

A simple way in my case.
Set ORACLE_HOME environment variable in Program.cs(Entrypoint class)
without any changes or settings in app.config
[STAThread]
static int Main()
{
var oracleHome = GetOracleHome(); // Find registry...
Environment.SetEnvironmentVariable("ORACLE_HOME", oracleHome);
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
...

Related

Oracle .Net ManagedDataAccess Error: Could not load type 'OracleInternal.Common.ConfigBaseClass' from assembly

I have a project that works locally, on our dev server, and on our production server.
When I try to run it on the test server, I get the error below, and I don't know what to do about it beyond stare at my screen blankly. Hints? Process to trace the issue to its source?
I've installed the NuGet package for Oracle 12.2, etc.
Could not load type 'OracleInternal.Common.ConfigBaseClass' from
assembly 'Oracle.ManagedDataAccess, Version=4.121.2.0,
Culture=neutral, PublicKeyToken=89b483f429c47342'. Description: An
unhandled exception occurred during the execution of the current web
request. Please review the stack trace for more information about the
error and where it originated in the code.
Exception Details: System.TypeLoadException: Could not load type
'OracleInternal.Common.ConfigBaseClass' from assembly
'Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral,
PublicKeyToken=89b483f429c47342'.
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of
the exception can be identified using the exception stack trace below.
Stack Trace:
[TypeLoadException: Could not load type
'OracleInternal.Common.ConfigBaseClass' from assembly
'Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral,
PublicKeyToken=89b483f429c47342'.]
Oracle.ManagedDataAccess.EntityFramework.EntityFrameworkProviderSettings.Oracle.ManagedDataAccess.EntityFramework.EFProviderSettings.IEFProviderSettings.get_TracingEnabled()
+0 Oracle.ManagedDataAccess.EntityFramework.EFProviderSettings.InitializeProviderSettings()
+111 Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices..ctor()
+629 Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices..cctor()
+28
[TypeInitializationException: The type initializer for
'Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices'
threw an exception.]
Oracle.ManagedDataAccess.EntityFramework.EFOracleProviderServices.get_Instance()
+24
The Web.Config has the following blocks in it:
<configSections>
<!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
<section name="oracle.manageddataaccess.client" type="OracleInternal.Common.ODPMSectionHandler, Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342" />
</configSections>
AND
<oracle.manageddataaccess.client>
<version number="*">
<dataSources>
<dataSource alias="PVMDataSource" descriptor="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=pdxcludds108.pacificorp.us)(PORT=11086))(CONNECT_DATA=(SERVICE_NAME=DDS1086.PACIFICORP.US))) " />
</dataSources>
</version>
</oracle.manageddataaccess.client>
<connectionStrings>
<add name="OracleDbContext" providerName="Oracle.ManagedDataAccess.Client" connectionString="User Id=USERID;Password=WORKINGPASSWORD;Data Source=PVMDataSource" />
<add name="PVMEntities" connectionString="metadata=res://*/Models.PVMModel.csdl|res://*/Models.PVMModel.ssdl|res://*/Models.PVMModel.msl;provider=Oracle.ManagedDataAccess.Client;provider connection string="DATA SOURCE=pdxcludds108.pacificorp.us:11086/DDS1086.PACIFICORP.US;PASSWORD=XXXXXXX;PERSIST SECURITY INFO=True;USER ID=XXX"" providerName="System.Data.EntityClient" />
</connectionStrings>
NOTE: There are other projects working on this server, they're just using a different version of the Oracle client for .Net. None of the others is using only the Managed driver. I am looking for a way to dig into this error, some hint as to where that type is sourced and loaded from.
There is a conflict between Oracle.ManagedDataAccess from NuGet and the one that is installed (by Oracle client installation) on a server and that is registered in GAC.
Unregister Oracle.ManagedDataAccess from GAC and you will get rid of the error: Run command line and navigate to the directory:
{Oracle home}\product\{version}\client_64\ODP.NET\managed\x64
There you should find OraProvCfg.exe file. Run the following command to unregister Oracle.ManagedDataAccess from GAC:
OraProvCfg /action:ungac /providerPath:Oracle.ManagedDataAccess
You have to remove the Oracle.ManagedDataAccess assembly in your GAC (C:\Windows\Microsoft.NET\assembly...)
Use the command tool gacutil to remove the assembly:
C:\Program Files (x86)\Microsoft SDKs\Windows\YOUR_VERSION\bin\NETFX
4.6.1 Tools> gacutil /u Oracle.ManagedDataAccess
Was able to fix it by replacing references in the project to Oracle.ManagedDataAccess and Oracle.ManagedDataAccess.EntityFramework from those installed by the package manager to those installed by the oracle client installer. The versions are the same but the build number is different on those DLLs
As others said you need to remove Oracle.ManagedDataAccess from GAC.
I run {Oracle home}\product\12.1.0\dbhome_1\ODP.NET\managed\x64\unconfigure.bat and {Oracle home}\product\12.1.0\dbhome_1\ODP.NET\managed\x836\unconfigure.bat and it worked
We had the exact same problem as Dylan above. The issue appears to be with that specific Oracle version (4.121.2.0).
The solution was simple: Just go into Nuget and move up to the next version of your Nuget package for the Oracle.ManagedDataAccess.Client, 4.122.1.0.
Once we did that we could have mixed Oracle client or no-client environments or servers with or without the GAC Oracle installed, keep older apps that still use the GAC, and add new projects that use the Nuget packages. Its always a bad idea in these blogs to ask people to uninstall legacy stuff - like remove the Oracle dll in the GAC on a server - when you have environments with many legacy dependancies that still might reference it.
If removing the DLL from the GAC is not an option, consider getting the next version of oracle.managedData.access 12.2.1 and just put them on the server in the bin directory.
Afterwards you need to add an assemblyBinding to your web.config file.
This way you get arround pulling the 12.1.2 version from the GAC during runtime that will case the error.
You do not need to recompile your app against the new version.
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-12.1.2.0" newVersion="12.2.1.0" />
</dependentAssembly>
There is definitely something weird with this issue. I was developing an app on my local server which ran fine but got this error when I uploaded the app to our server. The server has oracle client installed. After looking at this thread I copied the two DLLs (Oracle.ManagedDataAccess.dll & Oracle.ManagedDataAccess.EntityFramework.dll) from within oracle client and replaced the versions in my app bin directory. That fixed the issue.
In my scenario, i have a console application consuming a class library database utility.
I had to reference the Oracle.ManagedDataAccess also on the console application so it can find the dll on runtime.
I don't know if this is the best approach, but worked for me.
good afternoon
I want to share how I solved this same error:
I started by starting visual studio 2019 cmd as administrator.
I ran the following command line in cmd: gacutil -u Oracle.ManagedDataAccess
Basically this command line will remove the Oracle reference from the GAC (Global Assembly Cache), this way it will only get the reference from the package that is in the project (which nuget installs) and not from the oracle client.
You need to install the Oracle Client drivers. The .NET packages don't contain them; they provide a translation from the managed world to the unmanaged. The drivers are in the unmanaged world and need to be installed properly.

Oracle InstantClient ODBC connection fails in DbProviderFactory when the ODBC Test Connect succeeds

Installed the InstantCLient 11.2.0.4 Basic Lite and ODBC packages
Set up the ORACLE_HOME and TNS_ADMIN environment variables and added the path for the installation to the Path environment variable
Created my tnsnames.ora file in that location
Set up my DSN using the TNS in the file and did a test connection - succeeded.
Used C# code I had developed before which uses the DbProviderFactoies generic method of connecting to Data Providers (already works with Teradata, SQL Server)
Created my Data Source configuration with the following connectionString:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="DataSource" connectionString="DRIVER={Oracle in instantclient_11_2};Data Source=Test Oracle;Persist Security Info=True;Password=password;User=user" providerName="System.Data.OracleClient"/>
</connectionStrings>
</configuration>
Results in "ORA-12560: TNS:protocol adapter error".
I tried many variants on the connection string and they all lead to an error of some sort. Any help will be much appreciated.
System Information
Windows Server 2003 64 Bit
C# .NET 3.5
Oracle 11g 11.2.0.3.0 remote database
I am not sure what was wrong, but I discovered that the very simple connection string below worked! It is using the generic System.Data.Odbc too.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<connectionStrings>
<add name="DataSource" connectionString="DSN=MyDSN;Uid=user;Pwd=password" providerName="System.Data.Odbc"/>
</connectionStrings>
</configuration>
It depends on which protocol you are using to connect: TCP or TCPS.
If TCPS, then the .NET Framework version should be above 4.5.
You get "ORA-12560: TNS:protocol adapter error" if the .NET Framework version is below 3.5.

CloudConfigurationManager.GetSetting returning null

Following instructions here I have:
var connectionString = CloudConfigurationManager.GetSetting("StorageConnectionString");
But connectionString is null, here is my app.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<connectionStrings>
<add name="StorageConnectionString"
connectionString="DefaultEndpointsProtocol=https;AccountName=storage;AccountKey=key" />
</connectionStrings>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.2.0.0" newVersion="5.2.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Had the same problem. Instead of using a connection string, use the configuration->appSettings->add key like this...
<configuration>
<appSettings>
<add key="StorageConnectionString" value="[ConnectionStringHere]" />
</appSettings>
</configuration>
As per documentation in MSDN http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.windowsazure.cloudconfigurationmanager.aspx
Only configuration settings within the appSettings tag can be read by CloudConfigurationManager. If your configuration settings are within a different tag, calling GetSetting will return Null.
Well this works, even if the comment doesn't fit, because I do have a ref to CloudConfigManager:
If you are creating an application with no reference to Microsoft.WindowsAzure.CloudConfigurationManager, and your connection string is located in the web.config or app.config as show above, then you can use ConfigurationManager to retrieve the connection string. You will need to add a reference to System.Configuration.dll to your project and add another namespace declaration for it:
using System.Configuration;
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
ConfigurationManager.ConnectionStrings["StorageConnectionString"].ConnectionString);
I had the same problem. I had updated the project to use Azure SDK 2.0. I updated NuGet packages for my web and worker roles, but the Azure project in Visual Studio was still on the old version.
To fix this, Right-Click on your Azure project and select Properties. Under the Application tab, you'll see a button to Update your Azure SDK.
Make sure all your references are in synch. There's the 2012-06 library and 2012-10 Set them to Copy Local = true and verify SDK version. I dealt with the exact same thing, drove me nuts.
This happened to me when I upgraded the Azure SDK to version 2.2.
To fix it I changed the packages.config to use a newer version of the Azure ConfigurationManager.
<package id="Microsoft.WindowsAzure.ConfigurationManager" version="2.0.1.0" targetFramework="net45" />
Based on my understanding, I'd like to point out that CloudConfigurationManager.GetSetting will look into web.config if you're running out of a cloud service. It will look into cscfg if you're inside a cloud service.
Please refer this
link.
Following this tutorial:
You can get configuration settings like this:
RoleEnvironment.GetConfigurationSettingValue("StorageConnectionString")
I got this after upgrading Azure SDK from 2.0 to 2.2. I was able to fix by:
Right-Clicking Azure project and selecting Properties. Update Azure SDK as per the Application tab. (Thanks to rattrick's answer).
Right click to Manage NuGet Packages. On the left click Updates and update WindowsAzure.ConfigurationManager.
I had the same problem (two times).
Even after restarting Visual Studio and after restarting the Azure emulator the CloudConfigurationManager.GetSetting("SettingName") returns null.
I was sure that it has worked before and I had the latest SDK.
So the solutions was restarting my PC and after that CloudConfigurationManager.GetSetting("SettingName") returns the right value.
I got the same issue this am after revisiting my Azure solution (Web + Worker role) to update it for Azure 2.5. Reviewing the help for CloudConfigurationManager.GetSetting, if its running under a cloud platform (Azure) it reads from the ServiceConfiguration.csfg, if running as a .net web app, reads from app or web.config.
So my fix was to simply change the start up project back to the Azure cloud project, not the Web project.
I was getting null because it was hosted in the wrong platform and reading from the .config files with no settings.
(Doh!)
It is an old thread but I wanted to share my solution if issue is not resolved by above mentioned methods then make sure that Azure Storage Emulator is running when you run the application; at least for me this happened. For me I had to create a class to handle emulator issue as mentioned here...
http://blog.simontimms.com/2013/08/28/configuration-settings-in-an-azure-worker-role/
class ConfigurationProvider
{
private static string GetStorageConnectionString(string name)
{
try
{
return RoleEnvironment.GetConfigurationSettingValue(name);
}
catch (SEHException)
{
return System.Configuration.ConfigurationManager.ConnectionStrings[name].ConnectionString;
}
}
public static string StorageConnectionString()
{
return GetStorageConnectionString("StorageConnectionString");
}
public static string DefaultConnection()
{
return GetStorageConnectionString("DefaultConnection");
}
}
I had quite similar problems. I updated from Azure SDK 2.0 to 2.2 - during this process I used the NuGet Manager to update the Microsoft.WindowsAzure.Storage to the latest. The PackageManager automatically took Microsoft.WindowsAzure.Configuration to 1.8.0.0. I was not able to get this running (it was for .Net 2.0!?). After I manually set all References to
Microsoft.WindowsAzure.Storage 2.1.0.0
Microsoft.WindowsAzure.Configuration 2.0.0.0
everything worked.
I think this is because of the way CloudConfigurationManager.GetSetting loads the assembly and calls the funktions (via reflection).
Same here after upgrading Azure SDK from 2.2 to 2.3.:
Right-Click the Azure project select Properties. In the Application tab click "Upgrade..." (Thanks to rattrick's answer).
Then there was one more error to resolve:
Trying to run the Azure Project in the Compute Emulator threw an exception:
System.Configuration.ConfigurationErrorsException was unhandled
Message: An unhandled exception of type 'System.Configuration.ConfigurationErrorsException' occurred in Microsoft.WindowsAzure.ServiceRuntime.dll
Additional information: konnte nicht erstellt werden.
In the "Error List" Window of VS2013 there was the following Warning:
Found conflicts between different versions of the same dependent assembly. In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; otherwise, add the following binding redirects to the "runtime" node in the application configuration file: C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets 1635
I let VS resolve this warning and everything worked fine.
This worked for me...
using System.Configuration;
...
var connectionString = ConfigurationManager.ConnectionStrings["StorageConnectionString"].ConnectionString;
I had the same problem. None of the advices worked for me, but the "issue" was straightforward. One simple has to understand how this class works.
It does not go into your app.config / web.config or wherever you store your application settings. CloudConfigurationManager works with ServiceConfiguration.*.cscfg and ServiceConfiguration.csdef. The .csdef must contain a definition of the setting, but not its value under the ConfigurationSettings section. The settings themselves sit in .cscfg files (under the same section but including the value; I suppose the reason for the double definition is to make sure both the cloud and the local configurations have the same settings).
You can set these either by right-clicking your role in Visual Studio and selecting Properties -> Settings (in case of StorageConnectionString, simply pick "Your subscription", if your storage account is connected to the cloud service), or by editing them manually. If you mess up the settings, you'll get an exclamation mark icon.
Simple as that.
Was getting a null value with when passing a literal string as well after installing Azure SDK 2.6 (was working before).
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings["AzureStorage"].ConnectionString);
Replaced the literal string and it worked fine.
string connectionStr = "AzureStorage";
var connectionstring = ConfigurationManager.ConnectionStrings[connectionStr].ConnectionString;
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(connectionstring);

Failed obtaining configuration for Common.Logging from configuration section 'common/logging'

I'm trying to configure a console application with the following logging assemblies:
Common.Logging.dll (2.1.0.0)
Common.Logging.Log4Net1211.dll (2.1.0.0)
log4net.dll (1.2.11.0)
If the logger gets configured programmatically then everything works fine:
NameValueCollection properties = new NameValueCollection(); properties["showDateTime"] = "true";
Common.Logging.LogManager.Adapter = new Common.Logging.Simple.ConsoleOutLoggerFactoryAdapter(properties);
But if I try to launch it using the following configuration file, it blows up:
<?xml version="1.0"?>
<configuration>
<configSections>
<sectionGroup name="common">
<section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
</sectionGroup>
</configSections>
<common>
<logging>
<factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4Net">
<arg key="configType" value="FILE-WATCH"/>
<arg key="configFile" value="~/Log4NET.xml"/>
</factoryAdapter>
</logging>
</common>
</configuration>
These are the relevant error messages:
{"Unable to cast object of type 'System.Configuration.DefaultSection' to type 'System.Configuration.AppSettingsSection'."}
{"Failed obtaining configuration for Common.Logging from configuration section 'common/logging'."}
It seems to being unable to parse my configuration file, does anyone know what the correct format should be or is it something else that's wrong? I created my configuration file using the official documentation.
I was having this (or related) issue as well and after half a day of error hunting and debugging I narrowed it down to a configuration problem.
The exception was the same as the OP and the inner exception a few level inside of it was failing to find Common.Logging.Log4Net (FileNotFoundException).
It seems that for the Common.Logging.Log4Net1211 NuGet package, they have renamed the assemblyname to be Common.Logging.Log4Net1211 instead of simply Common.Logging.Log4Net. This means in your app.config you need to refer to this new assembly name:
<factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4net1211">
Here's my entire common/logging section of app.config for reference:
<common>
<logging>
<!-- Notice that it's Log4net1211 -->
<factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4net1211">
<arg key="configType" value="FILE-WATCH" />
<arg key="configFile" value="~/Log4Net-MAIN.config" />
</factoryAdapter>
</logging>
</common>
There are two problems with your application (the one I downloaded):
Your configSections in app.config looks like this:
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
<sectionGroup name="common">
<section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
</sectionGroup>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler,log4net" />
</configSections>
Notice that the log4net-section is declared twice? Remove the first one.
After removing the first log4net-section, I get the following:
Could not load file or assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I downloaded log4net 1.2.11.0 from the log4net website, unzipped it, unblocked the dll and replaced the log4net in your example and it seems to work.
I'm using
Common.Logging v3.3.1.0
with
Common.Logging.Log4Net1213 v3.3.1.0
in ASP.NET Web API v5, which throws exception
"parent configuration sections are not allowed"
Exception is thrown from Common.Logging.ConfigurationSectionHandler.Create method
In order to make this work, I had to grammatically configure the adapter
var properties = new Common.Logging.Configuration.NameValueCollection();
properties["configType"] = "INLINE";
Common.Logging.LogManager.Adapter = new Log4NetLoggerFactoryAdapter(properties);
I still have to figure out why IIS/Express calls the Create method twice, which is causing the exception to be thrown inside the if condition, but at least the pressure is off for now.
I got it working by installing a missing package
Install-Package Common.Logging.Log4Net1211
Although this is an old question, I had this issue a few weeks and none of the current answers seemed to remedy it. It seemed my configuration was correct as I had many other applications using near identical configuration with no issue. After quite a bit of debugging and running through stacktraces, I finally found the issue.
Notice that in IIS, I have the API application hosted under another application. In this case both the CAMP application and the API application under it are both using Common.Logging. Because of this, both web.config files get loaded, Common.Logging reads CAMP's configuration, then it sees that API has configuration and tries to read that as well, sees the Common.Logging section and throws up because it already read that from the CAMP application.
In the end the solution was to move the API out from under the CAMP application in IIS. A bit of an obsucre edge case, but perhaps someone else might face this issue some day.
Can you try with Common.Logging.dll version 2.1.1.0 instead.
You can download and compare the source of the two versions yourself, but as far as I can see the only difference between 2.1.0.0 and 2.1.1.0 is a change relating to reading the configuration settings in order to workaround a Framework 4.0 bug. The description of the bug (see http://support.microsoft.com/kb/2580188) refers to running from a network share which I am not running from a network, yet a test app using 2.1.0.0 generates the same error as you are getting whereas 2.1.1.0 doesn't.
If you are using another library that expects version 2.1.0.0 of common.logging.dll, then you should be able to using an assembly redirect to use 2.1.1.0 instead.
PS
Not sure whether it is relevant, but I left the name of the dll as Common.Logging.Log4Net121.dll and modified the app.config instead
I found that it was due to the Common.Logging.Log4Net1211 NuGet package retrieveing an older version of Common.Logging. Check for NuGet updates to Common.Logging and if you find one download it and try again.
If your log4net is 2.0.6 or above, it may be convenient to use Common.Logging.Log4Net.Universal package.

How can I deploy a .NET application that uses ODAC without installing the whole component to the user?

I have written a C# application that connects to an Oracle 10g database. Using Oracle Data Access Component 11.2 "ODAC", it works perfectly on my machine.
And now I want to deploy the application and install it in another "clean machine" that has the .NET Framework only! And I don't want to install the whole ODAC component to the user!
How could I do that? I have tried to include all the necessary DLL files to my bin folder, like:
oci.dll
ociw32.dll
Oracle.DataAccess.dll
orannzsbb11.dll
oraocci11.dll
oraociicus11.dll
OraOps11w.dll
msvcr71.dll
But still it didn't work. What should I do to solve this problem?
You don't need to install any Oracle client separately.
I installed the following in the same directory as the .exe:
Oracle.DataAccess.dll
oci.dll
OraOps11w.dll
oraociei11.dll
msvcr71.dll
Make sure your project references the same Oracle.DataAccess.dll that you are delivering.
This worked on a fresh pc which had never had oracle clients installed.
I avoided using TNSNAMES.ora by specifiying a connection string like this
connectionstring =
Data Source="(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=))" +
"(CONNECT_DATA=(SERVER = DEDICATED)(SERVICE_NAME = )))"
If you are using TNSNAMES.ora just cut and paste the connection details into a single line string.
see
What is the minimum client footprint required to connect C# to an Oracle database?
for more information.
ejm
For information on how to obtain the above dlls, see this tutorial: http://begeeben.wordpress.com/2012/08/01/accessing-oracle-database-without-installing-oracle-client/
Since this question was posted, the Oracle Managed Client is now available (provided by Oracle). I have been using it with no problems. Does not require hunting for DLL's or special configuration. Just add the package, modify configuration file, and you're set. NuGet Link and an article by Oracle about it..
Since this client is written entirely in .NET Managed code, it's architecture independent and there is no need for external DLL's, installing an Oracle Client, or anything like that.
You can install it in VS using Package Manager.
Install-Package Oracle.ManagedDataAccess
I've taken to putting this in the machine.config file (though it'll also work in web.config or app.config). I've found that this helps avoid conflicts with other drivers that may be installed:
<configuration>
<system.data>
<DbProviderFactories>
<remove invariant="Oracle.DataAccess.Client" />
<remove invariant="Oracle.ManagedDataAccess.Client" />
<add name="ODP.NET, Managed Driver"
invariant="Oracle.ManagedDataAccess.Client"
description="Oracle Data Provider for .NET, Managed Driver"
type="Oracle.ManagedDataAccess.Client.OracleClientFactory, Oracle.ManagedDataAccess, Version=4.121.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342"/>
</DbProviderFactories>
</system.data>
<configuration>
Then for your connection string:
<add name="MyConnectionString" connectionString="Data Source=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=IPORNAMEOFHOST)(PORT=PORTNUM)))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=ORACLESID)));User Id=ORACLEUSER;Password=ORACLEPASSWORD;" providerName="Oracle.ManagedDataAccess.Client"/>
IPORNAMEOFHOST= This is the IP address or DNS name of your server.
PORTNUM= This is the port number that Oracle is listening at. Typically 1521.
ORACLESID= The SID of the database you're trying to connect to.
ORACLEUSER= The username to use for the connection.
ORACLEPASSWORD= The password to use for the connection.
I'm not sure whether your concern is about having to install the Oracle client in addition to the ~50 MB ODAC install or just the standalone ODAC.
If the concern is about having to install the Oracle client and the ODAC, you can use the Oracle Instant Client? That's the smallest footprint method for installing the Oracle client. You'll also need the ODAC xcopy supplement.
If your concern is just the ODAC install, I don't think there is a smaller footprint available.
For NET Framework net462, net463, net47, net471, net472, net48
use the nuget package: Oracle.ManagedDataAccess
In c# project, add the next line:
<PackageReference Include="Oracle.ManagedDataAccess" Version="21.5.0" />
For netcore .NET net5.0/net6.0,netcoreapp3.0, netcoreapp3.1,netstandard2.1
use the package: Oracle.ManagedDataAccess.Core
<PackageReference Include="Oracle.ManagedDataAccess.Core" Version="3.21.50" />
If you are using TNS names (e.g ORCL in tnsnames.ora), the connection string is:
string oradb = $"Data Source=ORCL;User Id=hr;Password=hr;";
Also, you can use Easy Connect Naming Method;
string oradb = $"Data Source=192.168.1.70/{SERVICE_NAME};User Id=hr;Password=hr;";

Categories

Resources