Risoluzione/utilizzo di più versioni di assembly da dipendenze di terze parti

Question

Nel mio progetto, ho un problema con la sua gerarchia di dipendenze. Uso una libreria (WriteableBitmapExtensions) nel mio codice e ho un'altra libreria di terze parti che utilizza anche WriteableBitmapExtensions. Solo l'altra libreria è fortemente legata a una specifica versione precedente e il mio codice ha bisogno della funzionalità nella sua versione più recente.

Ecco una rappresentazione delle dipendenze:

Non ci sono domande simili & soluzioni, ma si risolvono con associazione di assembly in fase di esecuzione tramite un file di configurazione, ma non credo che ciò sia compatibile per un'applicazione Silverlight.

Referencing 2 different versions of log4net in the same solution

Using different versions of the same assembly in the same folder

3rd party libraries refer to different versions of log4net.dll

How to deal with multiple versions of dependencies?

Così, c'è un modo per risolvere queste diverse versioni di dipendenze di montaggio in un contesto di Silverlight? Se non c'è, immagino le mie opzioni sono:

1) Molto probabilmente posso convincere il fornitore della libreria di terze parti ad aggiornare l'uso dell'ultima versione di WriteableBitmapExtensions, ma preferirei non dipendere da li tengono aggiornati. Soprattutto perché il progetto WriteableBitmapExtensions è ancora in fase di aggiornamento e spesso sfruttiamo le loro nuove funzionalità.

2) Dal momento che WriteableBitmapExtensions è open-source, suppongo posso ricompilare la sua fonte di una nuova assemblea "MyWriteableBitmapExtensions" e l'uso che nel mio codice sorgente. Ricontrerò di nuovo questo problema se due librerie di terze parti fanno riferimento a versioni diverse di WriteableBitmapExtensions.

Sospetto che andrò con l'opzione 2, ma mi piacerebbe sapere se c'è un modo migliore per farlo (come il binding dell'assembly di runtime nelle altre domande) prima di commettere/refactoring. Grazie!

Answer 1

Come ho detto nel mio commento, l'opzione 1 dovrebbe essere prontamente disponibile perché "v1" è in realtà una versione "pre beta".

Se c'è un ritardo nel venditore di terze parti che rilascia una build utilizzando una versione non beta, l'opzione 2 è la tua prossima opzione. Assicurati di utilizzare un'identità completamente nuova per la build di MyWriteableBitmapExtensions: in particolare, utilizza un nome Assembly diverso, NomeFile, firma del nome sicuro e qualsiasi GUID utilizzato per l'identità, incluso per COM.

Se non hai bisogno della nuova funzionalità o se la v2 è compatibile con v1, assemblaggio vincolante sarebbe ancora l'opzione da preferire - non hanno confermato se questo è disponibile con Silverlight, ma mi piacerebbe essere sorpreso se non fosse anche se ora sono d'accordo che il vero assembly assembly è probabilmente non disponibile in Silverlight perché l'intero spazio dei nomi System.Configuration manca a Silverlight (tranne che per due enumerazioni in System.Configuration.Assemblies).

Tuttavia, un'altra opzione è quella di regolare il codice sorgente più recente in modo che fa produrre qualcosa che è compatibile a v1, forse rompendo le caratteristiche v2 se si deve - in tal modo le caratteristiche V2 può ancora essere utilizzato, solo con una ricompilazione, ora con l'identità originale (Nome Assembly, NomeFile, Firma nome sicuro, ecc.).Quindi dovresti essere in grado di usare di nuovo l'assemblaggio per entrambi gli scenari.