Compilare le applicazioni a 64Bit

Ultimamente mi è capitato uno strano errore che mi ha fatto “scervellare” (passatemi il termine) per individuarne la causa, poi la soluzione si è presentata davanti agli occhi ed era più semplice di quel che pensavo (anche se devo ammettere che il messaggio di errore non era di aiuto); ma partiamo dall’inizio.

Un paio di settimane fa ho sviluppato un plugin per Dexter che non fa altro che mostrare informazioni provenienti da vari feeds rss; nel mio caso specifico sono feeds RSS dei principali social network a cui partecipo, ed il mio scopo era di creare una pagina che li aggregasse tutti insieme in modo da riassumere le mie ultime attività (per chi fosse interessato al funzionamento può vedere il risultato finale qui).

I plugin in Dexter non sono altro che delle semplici librerie caricate automaticamente a runtime ed aggiunte all’application domain principale (ancora per poco ); al contrario degli altri plugin, come il like di facebook, questo non ne voleva sapere di partire, restituendo sempre il seguente errore:

Server Error in '/' Application.
Could not load file or assembly 'Dexter.Plugins.LifeStream' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: Could not load file or assembly 'Dexter.Plugins.LifeStream' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Assembly Load Trace: The following information can be helpful to determine why the assembly 'Dexter.Plugins.LifeStream' could not be loaded.

Ora io ero certo che l’applicazione si trovasse nel path corretto e che tutto funzionasse a norma; di fatto in locale il plugin sembrava perfetto, eppure doveva esserci un fattore che ne impediva il funzionamento nel server di produzione.
Indagando un po’ a fondo e cercando errori simili in rete sono risalito al problema, scoprendo che il tutto era dovuto alla compilazione della libreria in questione che non era a 64bit come richiesto dal server di produzione.

Purtroppo non so per quale motivo, ma il nuovo progetto del plugin aggiunto a Visual Studio aveva la compilazione abilitata solo per i 32bit e non “Any CPU” come mi aspettavo, e l’application pool in produzione era configurato per eseguire soltanto codice compilato per i 64bit e quindi si rifiutava (giustamente) di caricare l’assembly, bloccando il flusso corretto di funzionamento dell’applicativo.
Al contrario nella mia macchina di sviluppo era tutto funzionante perché nella configurazione di IIS era stata impostata l’opzione “Enable 32-bit Application” negli “Advanced Settings” dell’application pool, come mostrato dallo screenshot seguente.

SNAGHTML20b8c76f

Come potete vedere il problema è piuttosto banale e facilmente risolvibile se non per il “non bel” messaggio di notifica.
64-bit Rulez!


Comments