Il compilatore C # ottimizza erroneamente il codice

Question

Ho un'applicazione ASP.NET in esecuzione su un server Web remoto e ho appena iniziato a ricevere questo errore:

Method not found: 'Void System.Collections.Generic.ICollection`1..ctor()'.

Ho smontato il codice nella DLL e sembra che il compilatore stia ottimizzando il codice in modo errato. (Notare che Set è una classe che implementa un set di oggetti unici. Eredita da IEnumerable.) Questa riga:

Set<int> set = new Set<int>();

È compilato in questa riga:

Set<int> set = (Set<int>) new ICollection<CalendarModule>();

La classe CalendarModule è una classe totalmente indipendente! Qualcuno ha mai notato .NET compilare in modo errato codice come questo prima d'ora?

Aggiornamento n. 1: questo problema sembra essere stato introdotto da Strumento ILMerge . Stiamo attualmente esaminando come superarlo.

Aggiornamento n. 2: finora abbiamo trovato due modi per risolvere questo problema. Non capiamo bene quale sia il problema di fondo, ma entrambi risolvono il problema:

1. Disattiva l'ottimizzazione.

2. Unisci il gruppo con ILMerge su una macchina diversa.

Quindi ci chiediamo se la macchina di compilazione sia in qualche modo configurata in modo errato (il che è strano considerando che stiamo usando la macchina per costruire versioni da oltre un anno ormai) o se si tratta di qualche altro problema.

Answer 1

Ahh, ILMerge - quell'informazione extra nella tua domanda aiuta davvero con il tuo problema. Anche se non mi sarei mai aspettato che il compilatore .net fallisse in questo modo, mi sarei aspettato di vedere occasionalmente questo genere di cose con ILMerge (dato quello che sta facendo).

La mia ipotesi è che due dei tuoi assiemi stiano usando lo stesso "trucco" di ottimizzazione e una volta uniti ottieni il conflitto.

Hai sollevato il bug con Microsoft?

Una soluzione alternativa nel frattempo è quella di ricompilare gli assembly dall'origine come un singolo assembly, risparmiando la necessità di ILMerge. Dato che i file csproj sono solo elenchi XML, sono fondamentalmente facili da unire e potresti automatizzarlo come un ulteriore passaggio di MSBuild.

Answer 2

Sei sicuro che l'assembly che stai guardando sia stato effettivamente generato dal codice sorgente in questione? Sei in grado di riprodurre questo problema con un piccolo test case?

Modifica: se stai usando Reflector, è possibile che la conversione da MSIL a C # non sia corretta - Reflector non è sempre preciso al 100% al momento della decompilazione. Che aspetto ha MSIL?

Modifica 2: Hmm ... Mi sono appena reso conto che non può essere colpa di Reflector o che non avresti ricevuto quel messaggio di errore in fase di esecuzione.

Answer 3

È più probabile che ciò costituisca un problema con lo strumento di riflessione piuttosto che con la compilazione .Net. L'errore che ricevi: un costruttore non trovato durante il remoting è molto probabilmente un problema di serializzazione (tutte le classi serializzabili richiedono un costruttore senza parametri).

È più probabile che il codice trovato dal tuo strumento di riflessione generi un'eccezione tipecast.

Answer 4

Sono d'accordo sia con Curt che con Beds; sembra che qualcosa sia seriamente sbagliato. L'ottimizzatore ha funzionato per tutti noi e non sono stati segnalati bug di questo tipo (di cui io sia a conoscenza) - è possibile che tu stia effettivamente facendo qualcosa di sbagliato?

Sidenote: vorrei anche sottolineare System.Collections.Generic.HashSet<T> che è in .Net fx 3.5 e fa esattamente quello che dovrebbe essere una classe Set<>.

Answer 5

Il codice è stato recentemente distribuito su quel server? Qualcuno avrebbe potuto spingere una build a tua insaputa? Puoi andare al controllo del codice sorgente, estrarre l'ultimo e duplicare il problema?

A questo punto, con le informazioni fornite, dubito che sia il compilatore.

Answer 6

Ouch. Se questo è davvero ILMerge, ti preghiamo di tenere aggiornato questo argomento con i tuoi risultati - Uso ILMerge come passaggio chiave nella costruzione di un assembly di interoperabilità COM.