Advanced Technology

Utilizzo MZ-Tools sin da quando programmavo con VB 6, e devo dire che è un tool degno di nota. Risparmia parecchie cosine e tanto tempo utile che si può dedicare ad altro.

In alcune occasioni però, mi è capitato di imbattermi nell’errore di caricamento dell’Assebmly 80131018.

Non c’è stato verso, nella prima occasione, di ripristinare il tool, al punto che decisi di formattare.

Oggi, di nuovo lo stesso errore. Avevo il tool funzionante. Di punto in bianco sparisce, al che decido visto che c’ero di installare la nuova versione. E … errore.

Al che mi imbatto su un post dell’autore del componente … e l’ultima nota dove dice di aver disabilitato l’antivirus e la sua funzione per gli “unknown threats”, mi fa immediatamente andare a disabilitare – nonstante Carlos non abbia voluto specificare il nome dell’Antivirus - la funzione nel Panda Anhtivirus a bordo della mia macchina.

Ho quindi proceduto così:

1. Chiuso VS 2005
2. Aperto un prompt di MS-Dos nella cartella di default del programma
3. Lanciato un RegAssembly20 /u MZtools5.dll
4. Atteso che finisse
5. Spenta l’analisi comportamentale del Panda
6. Rilanciato un RegAssembly20 /r MZtools5.dll
7. Riaperto VS 2005
8. Riabilitato l’antivirus

Ora tutto funziona. Preciso che il problema sembra verificarsi solo con la versione Panda Antivirus 2007 e Panda Antivirus 2007 + Firewall. La versione Internet Security al momento sembra immune dal problema.

Good coding a tutti.

Vista ha decisamente portato dei miglioramenti e delle nuove feature, e non sto qui ad enumerarli. Però, come ogni nuovo software che si rispetti, ha portato anche dei bug.

Uno di questi (mi verrebbe quasi da dire le UAC - NDR) è il fatto che l’OS ci metta anni luce per spostare anche file di piccole dimensioni e quel che è peggio è che faccia il lock di alcuni file in maniera esclusiva e irrisolutiva.

Mi ritrovavo con dei progetti in VS 2005, che giusto dopo il primo debug (quindi compilazione prima e debug poi), non potevano essere ricompilati nuovamente a causa di un lock esclusivo da non si sà chi.

Ricevevo in pratica questo messaggio di errore:

C:\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.

targets(2314,9): error MSB3021: Unable to copy file

“obj\Debug\ConsoleApplication1.exe” to “bin\Debug\ConsoleApplication1.exe”.

The process cannot access the file ‘bin\Debug\ConsoleApplication1.exe’

because it is being used by another process.

Done building project “ConsoleApplication1.csproj” – FAILED

Chiaramente il messaggio cambiava nel path a seconda del progetto; presto mi sono reso conto anche che la situazione era estesa anche ad altri file nel pc, giusto dopo essere stati creati o eseguiti (e parlo di file scaricati da internet ed eseguiti – non altro) che si loccavano alla stessa identica maniera.

Dopo aver comunque aperto un incident MSDN per ricevere supporto, sulle prime il tecnico mi ha suggerito tecniche e consigli già provati e che comunque si riferivano tutti a VS 2003: esempio chiudere e riaprire il progetto, mettere il copy local agli assembly referenziati.
Cose che non hanno dato i risultati sperati. L’unica cosa che funzionava era il reboot.

Non ci stanno infatti tool che tengano, dal gratuito Unlocker (tool francese) all’Handle di Rossinovich – dove il primo non trova nemmeno l’handle che blocca il file, mentre il secondo lo trova ma non riesce a cancellarlo.

Fare un takeown e un icacls, non serve a niente. I file stanno li e non si schiodano.

Ma c’è sempre un però. Dopo alcuni ricerche, mi sono imbattuto in un micro post che faceva riferimento all’articolo KB 931770, che sebbene non citasse nello specifico il problema, sembrava risolutivo per la questione.

Chiamato MS 10 minuti fa, ricevuta la fix dopo 2 minuti, applicata dopo 1 (niente reboot necessario) e ora solo felice possessore dei miei file e sembra che posso cancellarli quando voglio e compilare quante volte mi pare.

Parlo ancora al condizionale, perchè non sono del tutto sicuro che l’odissea sia finita. Magari al prossimo reboot dovrò postare smentita.

Ore 15:19 : Ecco la smentita

Faccio reboot, riprovo a vedere se tutto funziona, e tristemente scopro che non funziona più un tubo. Mi viene quasi voglia di provare a reinstallare la patch. Ma sicuramente, senza nemmeno che ci riprovo, il sistema dirà che la patch è già presente o altre menate varie.

Mi rimetto al tecnico Microsoft al quale ho consigliato di rivolgersi al team di sviluppo di Vista per chiarire questa situazione.

Mi sono ritrovato in un bel pasticcio con Windows Vista (presumo la cosa possa succedere anche con Windows XP – ma onestamente non ho voglia di provare). Praticamente un software che ho installato ha preteso di installare anche le librerie .net 1.1.

Io ho pensato che non potesse succedere niente, tanto sono nomi e cartelle diverse … e invece no.

Da quel momento, ogni progetto web che aprivo, continuava a mostrarmi una finestra di messaggio con il seguente errore:

The site ‘http://localhost/porogetto’ is currently configured for use with ASP.NET 1.1.4322.573. Microsoft Visual Studio has been designed for use with ASP.NET 2.0; if not configured some features may make incorrect assumptions, and pages designed with the tool may not render correctly.

In poche parole dice che Visual Studio 2005 è fatto per lavorare con il framework 2.0 e che invece il progetto che stavo aprendo era configurato per il framework 1.1.
La finestra diceva anche, vuoi aggiornare il profilo? Io rispondevo di si, tutto si apriva e tutto funzionava bene, ma riaprendo di nuovo il progetto stesso messaggio.

Preso dall’esasperazione, mi sono messo a cercare una soluzione, ma l’unica che è trovato è stata la cosiddetta soluzione radicale, di disinstallare completamente IIS7 dal pc, disistallare il framework 1.1, e reinstallare subito dopo il riavvio IIS7; questa operazione ha, presumo, ricreato il MetaBase di IIS7 e ora tutto funziona correttamente.

Le altre prove, infatti, quali, cercare puntamenti al framework 1.1 nel web.config, creare un nuovo sito web sotto IIS7, non hanno cambiato praticamente nulla.

Internet Information Services (IIS) non è solo una piattaforma per ospitare siti web, è in alcuni casi anche un component essenziale per diversi altri prodotti Microsoft come Content Management Server, Exchange Server ecc. I processi di sviluppo che hanno investito questa piattaforma sin dalla sua versione 1.0 all’attuale 6.0 di Windows 2003 Server sono molteplici.
In particolare nell’ultima versione, considerate tutte le critiche mosse contro Microsoft circa sicurezza e stabilità del sistema, il team di sviluppo di IIS si è adoperato profondamente al fine di riscrivere completamente un nuovo server web che sopperisse le critiche mosse.

 

Un po’ di storia prima di proseguire

Fino ad IIS3 tutti i siti web hostati, compreso la stessa piattaforma giravano su di un unico processo chiamato inetinfo.exe.

Con IIS4 si è iniziato a pensare per la prima volta ad un modello che slegasse completamente la piattaforma dai servizi web. Risultato un processo di nome inetinfo.exe che gestiva il WWW e tanti siti web che potevano girare “tranquillamente” sotto la stessa macchina, con il vantaggio di poter essere avviati e fermati a piacimento senza per questo impattare le altre applicazioni. Svantaggio, nessun sito web poteva interagire con gli altri, e in fase di debug, tutto veniva spostato sotto il processo principale e quando il primo bug veniva alla luce, se questo mandava in crisi il processo, bisognava procedere nuovamente al riavvio del servizio (e tutti gli altri siti ignobilmente venivano spenti e riaccesi facendo perdere le sessioni di lavoro).

IIS5, avvento di ASP.net 1.0 e nuovo approccio alla programmazione dinamica (a memoria ricordo fosse il tardo 2000, primi del 2001). Piccole modifiche al server web e al suo modo di gestione ora denominato “pooled process” che consentiva di far girare diverse applicazioni in un processo separato chiamato dllhost.exe, realmente separatp dal core della piattaforma. Vantaggio indiscusso di poter riavviare, fermare, debuggare applicazioni in maniera totalmente indipendente, di poter assegnare all’applicazione un profilo di isolamento del processo (a scelta tra basso, medio e alto), cioè assegnare l’area di memoria condivisa dove poter lavorare. Questo il vero svantaggio, perché comunque, bene o male, tutte le applicazioni lavorano sotto un unico processo.

IIS 6.0 e ora ASP.net 2.0 / 3.0. Riscrittura totale del server web, un solo livello di isolamento del processo ora denominato “application pool”. Un processo che può essere creato ex-novo e per un numero “infinito” di applicazioni che possono ora girare in uno spazio realmente distinto o condiviso a seconda delle impostazioni date via console.

 

Perché la storia era necessaria

 

Non sono un fanatico dei libri, ma era necessario evidenziare i cambiamenti che ci sono stati nel passaggio tra IIS5 e IIS6 per affrontare il problema. Ma diamo un’occhiata alle immagini prima di proseguire oltre.

La prima immagine mostra un task manager di IIS5, 3 processi aspnet_wp.exe, uno per ogni istanza del frame work caricata.

Con IIS5 se il processo con la versione del framework richiesta non era attiva, veniva semplicemente caricata. Un piccolo stratagemma implementato da MS per permettere di far coesistere diverse versioni di framework senza troppe preoccupazioni per lo sviluppatore che per l’amministratore di sistema.

Con IIS6, invece, la storia è cambiata. Notate l’assenza di aspnet_wp.exe, e invece un prolificarsi di processi denominati w3wp.exe. Ognuno di quei w3wp.exe è un application pool distinto e separato nel quale possono giare più siti web (o anche uno solo) e una versione X del framework. In questo caso parlo al singolare. Si perché è impossibile che sotto ad un singolo application pool girino più versioni del framework.. Pena, la prima applicazione con il framework differente che inzierà a girare, ritornerà con un bell’errore di questo tipo.

 

Server Application Unavailable
The web application you are attempting to access on this web server is currently unavailable.  Please hit the "Refresh" button in your web browser to retry your request.
Administrator Note: An error message detailing the cause of this specific request failure can be found in the application event log of the web server. Please review this log entry to discover what caused this error to occur.

 

Questo avviene con un ordine non ben precisato. Mi spiego. Dato che l’application pool per default dopo 20 minuti di inutilizzo viene riciclato, è possibile che se il sito A che richiede la versione 1.1 del framework, non trovando un worker process attivo, ne carichi uno nuovo con quella versione del framework. Dopo pochi secondi arriva una nuova richiesta per il sito B. Stesso application pool, ma framework differente. Essendo l’application pool ancora attivo in memoria, il risultato è l’errore sopra mostrato.
Al successivo riciclo dell’application pool, potrebbe invece succedere l’esatto contrario. Ma l’errore non cambia e comunque nel registro degli eventi vi sarebbe sempre una traccia con la quale fare “debugging”. Infatti per problemi di questo tipo nell’event viewer viene aggiunta una entry con codice di errore 1062, come quella che si vede nell’immagine qui sotto.

 

 

Soluzione

Esistono due possibili soluzioni per questo genere di problema.

1) Soluzione non sempre praticabile, è quella di aggiornare la versione del framework per tutte le applicazioni. Non sempre possibile, perché alcuni componenti utilizzati magari non funzionano con una specifica versione, piuttosto che del managed code scritto, dato il cambio di alcune classi tra la versione 1.1 e la 2.0 del framework richiedono degli interventi sul codice.

2) Soluzione decisamente più sbrigativa, è quella di creare almeno un application pool diverso per ogni versione del framework che deve girare nel sistema e assegnare le varie applicazioni coerentemente con quanto detto.

 

Technorati Tags: IIS, Server Application Unavailable