Die kurze Antwort:
Hinweis:Ich habe versucht, das neue ODP.NET über den vorherigen Client zu installieren, und konnte mithilfe der folgenden Verbindungszeichenfolge eine Verbindung zur Datenbank herstellen...
Dies weist darauf hin, dass Ihre neue Installation keine tnsnames.ora und sqlnet.ora in /Network/Admin hat. Wenn Sie mit dem alten Client mit der neuen ODP.net-Installation einverstanden sind, können Sie sie entweder von der alten Installation kopieren oder einen globalen Speicherort für alle Instanzen mit der Umgebungsvariable TNS_ADMIN angeben, dh TNS_ADMIN=C:\MyOracleFilesDir
Die lange Antwort:
Bei der Installation des neuen Clients wurden höchstwahrscheinlich auch Herausgeberrichtliniendateien im GAC installiert, die Verweise auf die alte Oracle.DataAccess.dll während des Assemblyauflösungsprozesses auf die neue Version umleiten. Oracle.DataAccess findet dann den Client über einen Parameter (DllPath) in der Registrierung. Sie können diesen Speicherort überschreiben, indem Sie den dllPath in Ihrer .config-Datei festlegen:
<configuration>
<oracle.dataaccess.client>
<add key="DllPath" value="C:\yourotherpath"/>
</oracle.dataaccess.client>
</configuration>
Dies ist im Allgemeinen das, was ich tue, aber wenn ich das besser verstehe, wird mir klar, dass ich eine neuere DLL gegen einen älteren Client erzwinge. Wenn Sie den alten Client unberührt lassen möchten, ist es möglicherweise eine bessere Option, die Herausgeberrichtlinien aus dem GAC zu löschen (ich glaube nicht, dass sie mit der vollständigen ODAC-Installation installiert werden, nur ODP.net):
Wenn Sie sie neu installieren müssen, finden Sie sie im Allgemeinen unter oraclepath\odp.net\PublisherPolicy.
Eine andere und vielleicht langfristig bessere Option besteht darin, die alten Clients so zu konfigurieren, dass sie die Herausgeberrichtlinie ignorieren:http://msdn.microsoft.com/en-us/library/cf9025zt%28v=vs.80%29.aspx
Schließlich bin ich mir ziemlich sicher, dass die .net-Komponenten für die 2.0- vs. 4.0-Frameworks separate Installationsoptionen während der ODP.net-Installation sind. Ich denke, Sie können dieses Problem möglicherweise vermeiden, indem Sie die 2.0-Komponenten einfach nicht installieren. In diesem Sinne könnten Sie eine ähnliche Problemumgehung durchführen, indem Sie Ihr neues Projekt stattdessen gegen das 64-Bit-odp.net entwickeln. Wie v2.0 und v4.0 haben auch 32-Bit und 64-Bit keine Kenntnis voneinander.
