2014-06-12 10 views
9

Ho un assembly .NET personalizzato con alcuni cmdlet PowerShell di quelli che utilizzo per le attività relative al dominio comune. Ho appena creato un nuovo cmdlet che fa riferimento a una libreria di terze parti che ha un riferimento a Newtonsoft.Json 4.5.0.0. Tuttavia uno dei miei altri progetti utilizza l'ultima versione di json.net (6.0.0.0). Quindi al runtime in PowerShell Fusion si genera un errore che dice che non è possibile caricare newtonsoft.json 4.5.0.0.Reindirizzamento assembly config Powershell

Ho cercato di creare un powershell.exe.config e mettendo un'assemblea redirect in là:

<?xml version="1.0" encoding="utf-8"?> 
<configuration> 
    <runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <dependentAssembly> 
     <assemblyIdentity name="Newtonsoft.Json", Culture=neutral,  PublicKeyToken=30ad4fe6b2a6aeed/> 
     <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" /> 
     </dependentAssembly> 
    </assemblyBinding> 
    </runtime> 
</configuration> 

ma questo non sembra funzionare. Il log di fusione afferma che sta cercando in questo nuovo file di configurazione per PowerShell ma sembra che non stia rilevando il reindirizzamento.

Bit bloccato per le soluzioni qui. Qualche indizio su quale potrebbe essere il problema? Questo stesso reindirizzamento funziona in alcuni dei miei servizi aziendali che altrimenti avrebbero lo stesso problema (usano anche questo lib di terze parti e json.net 6).

Acclamazioni

+0

Ciao, stavo lavorando su un problema simile, e penso che questo potrebbe essere correlato. Puoi pubblicare la parte pertinente del tuo log di fusione per favore? E inoltre, l'errore di assemblaggio specifico quando provi a caricare (assembly non trovato?) – killthrush

risposta

13

Non so come ha funzionato più di anno fa, ma oggi su Windows 10 utilizzando PowerShell 5.0.10240.16384 l'unico modo sono stato in grado di fare redirect di montaggio (nel mio caso da FSharp.Core 4,3-4,4) era risolvere manualmente le dipendenze di assembly basate su Manually resolving assembly dependencies in PowerShell. Ho provato ogni altra soluzione come creare il file powershell.exe.config o provare a caricare altri *.config file, ma niente di quelli funzionava.

L'unico "gotcha" (a noleggio per me) è stato, che dal momento che faccio non avere FSharp.Core 4.3 ovunque, ho avuto bisogno di reindirizzarlo manualmente a 4.4. Ho finito per usare

$FSharpCore = [reflection.assembly]::LoadFrom($PSScriptRoot + "\bin\LIBRARY\FSharp.Core.dll") 

$OnAssemblyResolve = [System.ResolveEventHandler] { 
    param($sender, $e) 

    # from:FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a 
    # to: FSharp.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a 
    if ($e.Name -eq "FSharp.Core, Version=4.3.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a") { return $FSharpCore } 

    foreach($a in [System.AppDomain]::CurrentDomain.GetAssemblies()) 
    { 
    if ($a.FullName -eq $e.Name) 
    { 
     return $a 
    } 
    } 
    return $null 
} 

[System.AppDomain]::CurrentDomain.add_AssemblyResolve($OnAssemblyResolve) 

dove sono prima di caricare la versione corretta di FSharp.Core da qualche come la versione del GAC è vecchio (credo che questo potrebbe essere il vostro caso troppo)

È anche possibile check the real test usage in my project.

+0

Già a settembre 2017 e confermo che questa è l'unica soluzione che funziona, vale anche per Windows Server 2016. Hai salvato la mia giornata, grazie! – Armaggedon