Quando ci sono 32 bit di troppo ...
L'altro giorno ho pagato le spese di un problema legato all'istanziazione di componenti COM, via COM-Interop, da assembly .NET su piattaforma a 64bit.
Questo è in sintesi il problema. A me si è verificato nella chiamata ad un SOAP Service ASP.NET (un ASMX) che girava su piattaforma 64bit, in IIS a 64bit, con .NET 2.0 sempre a 64bit. Il servizio si limita a chiamare le library dell'API di SharePoint 2003, per creare una cartella e/o un site da codice, via API appunto.
Il guaio è che ho tentato in tutti i modi di aggirare il problema, sia come descritto nel post (forzando la compilazione a 32bit per piattaforme x86) sia forzando IIS a girare per intero (penalizza le performance ma a mali estremi ....) a 32bit, come indicato
qui.
Il problema però non è stato superato. La cosa "antipatica" è che invece in applicazioni classiche compilate per la piattaforma x86, ho fatto un test con un'applicazione console, il problema non sussiste, come indicato dal workaround del blog. Pare quindi che nel caso di IIS e ASP.NET 2.0 ci sia anche qualcos'altro da fare. Indagherò meglio, sperando di trovare una soluzione, sia per il mio caso specifico, che per altri che potrebbero avere le stesse esigenze.
Nel frattempo penso che aggirerò il "side effect" dei 64bit con un servizio WCF, anziché ASP.NET, compilato per x86, così da avere io il pieno controllo del processo host.
Ovviamente se qualcuno ci è già passato e ha dei suggerimenti ...