2013-02-06 24 views
10

Come risolvere?Come risolvere .NET Dll Hell?

Ho 2 gruppi di terze parti, che utilizza NewtonSoftJson.dll. Il problema è che uno di loro usa il vecchio 3.x.xe un altro usando 4.5.x. Quindi in fase di esecuzione almeno 1 dei 2 gruppi si lamenta dell'altro.

Come posso risolvere questo? Potrei creare servizi, ma i codici e gli ambienti non sono attualmente impostati in questo modo. È anche troppo refactoring di quanto possa essere fatto in sicurezza nel tempo richiesto.

+0

Entrambi gli assembly si trovano nella stessa directory? –

+0

Questo può aiutare: http://blogs.msdn.com/b/abhinaba/archive/2005/11/30/498278.aspx – Oded

+1

http://stackoverflow.com/questions/3158928/referencing-2-differents-versions -of-log4net-nella-stessa-soluzione – Oded

risposta

4

Mi è capitato di avere il problema esatto con Newtonsoft e un'altra libreria di terze parti. Il problema con Newtonsoft v3.xe v4.x è che la nuova libreria ora include un token di chiave pubblica. Ciò ha reso inutile la soluzione di reindirizzamento dell'assieme; ma è una soluzione perfettamente valida per la maggior parte degli altri casi.

Ho finito per reimplementare la libreria di terze parti. Se si ha accesso al codice sorgente della libreria di terze parti, è sempre possibile ricostruire la libreria utilizzando la nuova DLL Newtonsoft. Potrebbe essere necessario apportare piccole modifiche se una delle firme del metodo cambia.

+0

Corri nello stesso problema, scarica una piccola app (solo un paio di Kbs) e hai bisogno di una versione di framework che non possiedo. Per installarlo, devi cercarlo da solo che può portare a frustrazione (versione hell). È una piccola app ma ha bisogno di un sacco di cazzate intorno. Dopo aver installato il framework ha bisogno di aggiornamenti (sembrano aggiornamenti senza fine). Questo non è un modo molto intuitivo e folle per distribuire un'applicazione.Ora capisco perché Windows è così grande e ora so perché ci sono così tanti uomini senza peli in grassetto nel mondo. Pensaci due volte per utilizzare .NET per i tuoi prodotti. – Codebeat

3

L'articolo Microsoft "Redirecting Assembly Versions" ha questo da dire:

L'esempio seguente mostra come reindirizzare una versione di myAssembly ad un altro, e spegnere la politica dell'editore per mySecondAssembly.

<configuration> 
    <runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <dependentAssembly> 
     <assemblyIdentity name="myAssembly" 
      publicKeyToken="32ab4ba45e0a69a1" 
      culture="en-us" /> 
     <!-- Assembly versions can be redirected in application, 
      publisher policy, or machine configuration files. --> 
     <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0" /> 
     </dependentAssembly> 
     <dependentAssembly> 
     <assemblyIdentity name="mySecondAssembly" 
     publicKeyToken="32ab4ba45e0a69a1" 
     culture="en-us" /> 
     <!-- Publisher policy can be set only in the application 
      configuration file. --> 
     <publisherPolicy apply="no" /> 
     </dependentAssembly> 
    </assemblyBinding> 
    </runtime> 
</configuration> 
+2

Puoi mostrare come fare in modo che ciascuno l'assembly che ha una dipendenza da una versione diversa di 'NewtonSoftJson' ottiene la versione corretta? – Oded

+0

@Oded: non posso. Non ho il tempo adesso per esplorare questo. Forse questo fine settimana –

2

In genere, è possibile risolvere questo attraverso la configurazione della tua app/config web. È possibile utilizzare l'elemento di sondaggio per specificare un percorso privato e mettere le due versioni in cartelle separate:

<configuration> 
    <runtime> 
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="bin;bin2\subbin;bin3"/> 
     </assemblyBinding> 
    </runtime> 
</configuration> 

L'altro modo è quello di utilizzare il reindirizzamento di associazione di assembly. Ma funzionerà solo se saprai che le versioni sono compatibili. Dal momento che non li stai utilizzando direttamente, non sono sicuro che tu lo sappia e il publisher ha indicato alcune incompatibilità modificando la versione dell'assembly.

1

Terminato l'utilizzo del decompilatore, aggiungere un progetto alla soluzione, fare riferimento alle nuove DLL, correggere errori e ricompilare, puntare al progetto aggiunto di recente.

Non è stato possibile utilizzare il reindirizzamento dell'assembly poiché il token della chiave pubblica è stato modificato. Apparentemente è stata utilizzata una chiave diversa per compilare 1 degli assembly referenziati. Dovevo ricorrere alle misure più drastiche.