Definizioni di tipo .NET negli assembly uniti (ILMerge)

Question

Sto unendo diversi assembly .NET utilizzando ILMerge che include alcuni assembly di terze parti. Da quando ho riscontrato diversi errori, tutto si riduce al fatto che le definizioni dei tipi sono legate all'assieme in cui sono definite.

Un semplice esempio è la definizione della sezione di configurazione log4net nel mio App.config. Utilizza type = "log4net.Config.Log4NetConfigurationSectionHandler, log4net" che non funzionerà poiché l'assembly log4net non esiste una volta che è stato unito al mio assieme unito. Non è un grosso problema, cambio il nome dell'assembly nel mio assieme unito e funziona perfettamente.

Un esempio un po 'più complicato è di tipo serializzato binario. Il mio sistema utilizza la serializzazione binaria per inviare determinati oggetti tra i processi. Tutti gli oggetti serializzabili sono definiti in un assembly comune a cui fanno riferimento tutti gli altri progetti. Stavo usando la serializzazione binaria predefinita, ma ha iniziato a fallire quando deserializzava gli oggetti con l'errore affermando che non riusciva a trovare l'assembly unito che serializzava l'oggetto. Ancora una volta, non un grosso problema, ho implementato un SerializationBinder personalizzato che cerca il tipo in qualsiasi assembly caricato, non solo quello fornito.

L'esempio precedente si è complicato quando il tipo serializzato fa riferimento ad altri tipi serializzabili. Ho continuato a imbattersi in sempre più problemi che stanno diventando sempre più difficili da gestire.

Il punto che sto cercando di ottenere qui è che il sistema di tipo .NET e ILMerge non sembrano giocare bene insieme. Qualcuno ha qualche esperienza con come hanno risolto questo problema? È possibile dire al runtime .NET che non mi interessa quale assembly il tipo dice che dovrebbe essere in, basta cercarlo ovunque?

NOTA: Si prega di non rispondere chiedendo perché sto unendo gli assiemi, non è questo il punto di questa domanda.

Answer 1

Benvenuti a pericoli di stringhe e (fisico-locazione) stringhe in codice ..

Tutti gli strumenti di questo genere hanno problemi simili e loro meglio essere intelligenti, il maggior numero di sviluppatori e progettisti di caratteristiche di runtime, come vincolanti e la serializzazione in realtà non lo prevedeva, ma sicuramente hanno spinto ILMerge come uno strumento "intelligente". È così intelligente da non poter nemmeno potare i tipi.

Nota che anche il controllo delle versioni entra in gioco qui, e la configurazione,. * E le stelle nei loro occhi, e l'indipendenza della versione da Redmond non sono d'aiuto.

Continuerai a cogliere i problemi con i bit di terze parti. E credimi, so che hai bisogno di unirmi, poichè un po 'di patetico piccolo numero di tipi può richiedere anni affinchè MS JIT possa dare il via alle app di grandi dimensioni (e no, non voglio NGEN o il caricamento ottimizzato di 3.5SP1 è ancora più lento di prima a causa di System.Core o Heaven-forbid WPF bloat).

La migliore opzione, almeno su vasta scala, è quella di ottenere uno strumento commerciale decente che analizza e gestisce questo (cioè dall'esperienza di dolore e di offuscamento esistente là fuori). A lungo termine, si potrebbe finire per strumentare il codice IL esistente se non si hanno i sorgenti.

[Poi un INotifyPropertyChanged invenzione stringa che così risolto il problema del riscaldamento globale - creati da Casio-Calc inventori]

Answer 2

Sì, c'è una soluzione a questo problema: costruire moduli anziché assiemi!

I compilatori per .net hanno un'opzione (/ target: modulo per C# e VB) che crea un modulo invece di un assembly.Più moduli possono quindi essere passati al compilatore e utilizzati per costruire l'assemblaggio finale.

Naturalmente, tutto questo presuppone che tu abbia la fonte di questi gruppi di terze parti. Se non riesci a ottenerlo, forse una versione .netmodule dell'assemblaggio di terze parti può essere acquistata dalla terza parte?

Se non funziona, hai ancora un'opzione. Ovviamente stai già smontando un assemblaggio di terze parti in IL. Rimuovi le informazioni sull'assembly da quel file IL e usa "ilasm/dll" per creare un .netmodule che dovresti essere in grado di utilizzare proprio come qualsiasi altro .netmodule!

Utilizzando i moduli anziché gli assembly non si dovrebbero avere altri problemi basati sull'assemblaggio.

È vero, abbiamo risolto il problema con ILMerge non utilizzando più ILMerge, ma non è proprio la soluzione migliore?

auguro che funziona per voi, ecco qualche collegamento a portata di mano:
.netmodule instead of assembly
ILASM with .netmodules

(E io che pensavo che la mia esperienza con .netmodules non sarebbe mai stato utile a nessuno!)

Answer 3

Diversi anni dopo la domanda, mi sono imbattuto nello stesso problema e ho trovato una soluzione. È possibile aggiungere [assembly: log4net.Config.XmlConfigurator(ConfigFile = "logging.config", Watch = true)] nel file AssemblyInfo.cs e questo funzionerà quando si unirà l'assembly log4net.