J'utilise PowerShell contre Oracle avec beaucoup de succès. J'utilise le fournisseur managé ODP. Comme le fournisseur peut être installé dans différents emplacements, le Add-Type -Path doit pointer différemment sur différentes machines.PowerShell Add-Type OracleManagedDataAccess.dll sans chemin d'accès complet
Je voudrais pouvoir faire référence à cet assembly d'une manière qui ne dépend pas du chemin d'accès complet à la DLL.
Je pense que vous pourriez potentiellement obtenir le répertoire d'installation à partir du Registre avec PowerShell. Un emplacement possible est ici:
Get-ChildItem HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319\AssemblyFoldersEx\odp.net.managed
Bien que cela puisse varier selon la version .NET est installée. Vous pouvez essayer un joker pour que:
Get-ChildItem HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\*\AssemblyFoldersEx\odp.net.managed
Et finalement, vous pourriez avoir besoin pour obtenir la valeur de l'une des propriétés de cette clé de Registre, par exemple si elle est la valeur « (par défaut) »:
(Get-ItemProperty HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\*\AssemblyFoldersEx\odp.net.managed).'(default)'
J'ai trouvé cette solution, qui repose sur la connaissance du nom fort de l'assemblage voulu. Il semble fonctionner de manière fiable sur le test que j'ai fait
[void][reflection.assembly]::Load("Oracle.ManagedDataAccess, Version=4.121.2.0, Culture=neutral, PublicKeyToken=89b483f429c47342")
Je vois que cela fonctionne. Mais, comment cela vaut-il mieux qu'un chemin de répertoire codé en dur quand Oracle a une nouvelle version ou que le code est exécuté sur une machine avec une version différente? – lit
Seems AssemblyFoldersEx n'est pas présent dans l'infrastructure 64 bits. –