Asp.net: Ajax e ObjectDataSource

Published 31/05/2007 by Admin in ASP e ASP.Net
Tags:

Uno degli errori più comuni che si incontrano utilizzando Asp.net Ajax è l'errore javascript "Sys is undefined", che si incontra quando non viene caricato correttamente lo ScriptManager.
In generale questo errore è comune quando per chi passa dalla versione RC o precedente alla RTM, ed è risolvibile configurando correttamente il Web.config (trovate le indicazioni sul blog di ScottGu http://weblogs.asp.net/scottgu/archive/2006/12/15/asp-net-ajax-1-0-release-candidate-now-available.aspx.

Tuttavia oggi mi sono imbattuto nello stesso errore, circostanziato ad un'unica pagina (mentre nelle altre pagine tutto funzionava correttamente).
Dopo alcuni tentativi e qualche ricerca ho scoperto che il problema era nell'utilizzo di un ObjectDataSource che utilizzava un riferimento alla pagina (per invocare un metodo sull'oggetto Page stesso).
Creato un oggetto ad hoc, tutto funziona correttamente, anche se quando il tempo me lo consentirà (o meglio, se il tempo me lo consentirà) indagherò più a fondo su questo bizzarro comportamento

 

 

Technorati Tags:

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Il titolo può quanto meno sembrare criptico, tuttavia, meglio di così non sono riuscito a condensarlo.

Avevo un "problema" apparentemente semplice, quello di dover per l'appunto accedere ad una specifica colonna elaborata dal datasource, ma all'interno del codebehind.

Normalmente, grazie alla grande flessibilità dei nuovi oggetti ASP.Net 2.0, con poche righe di codice si riesce a modellare la pagina e mostrare i dati recuperati dal database.

Un esempio:

< asp:formview runat=""Server"" id=""CategoryView" DataSourceID="CategoryData"">
  < itemtemplate>
        <%# Eval("Title") %><%# Eval("Description") %>
  < /itemtemplate>

< /asp:formview>

Avevo però la necessità di dover "catturare" uno di questi valori e assegnarlo ad un controllo che era da tutt'altra parte nella pagina, e che non doveva stare nel FormView.

Mi aspettavo quindi che agendo sull'evento OnDataBinding, il sender sarebbe stato capace di darmi accesso al DataRowView. Sulle prime non sapevo che l'oggetto che dovevo andare a cercare era quello, e forse questa ignoranza è stata frutto del tempo speso a cercare di capire.

Per accedere quindi alla collection di dati bisogna aggiungere un handler per l'evento OnDataBound come riportato nel codice sottostante.

< asp:formview datasourceid="CategoryData" id="CategoryView" " runat="Server">
   < itemtemplate>
     <%# Eval("Title") %>
     <%# Eval("Description") %>
   < /itemtemplate>
< /asp:formview>

Nel codebehind, invece, bisognerà scrivere quanto segue:

protected void FormView1_DataBound(object sender, EventArgs)
{
   DataRowView r = (DataRowView) FormView1.DataItem;
   String xyz = r.Row[0].ToString();
}

Ovviamente questo discorso vale se l'oggetto bindato è di tipo AccessDataSource, SqlDataSource, ecc. Se già fosse stato un ObjectDataSource, la cosa sarebbe stata decisamente differente, perchè a tornare indietro sarebbe stato un oggetto di tipo "object".

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

This is a topic for which I've asked help also on dedicated ng, and for what I remember also the MVPes wasn't able to help me. After some research and a bit of luck, I've finally found the solution.

Windows Vista has a powerful document indexer integrated into it, that is in charge to catalog all newly docs generated or saved into the PC, included e-mail and contacts inside Outlook.

Outlook 2007, installed on Windows Vista, use exclusively this indexer to scan through all the e-mails and contact when user queries for a specific topic, replacing the internal search engine function that is embedded within the product.

I had a little problem twice along these few months in which I've been using Vista. I reformatted the PC and moved - obviously - all my data, .pst files included.
As I did in the past, a simple copy to remote PC should be the only thing needed; but unfortunately starting from that moment, all my past e-mail and contacts seemed to not exist anymore when queried from the search toolbar. This was happening only for older elements, not the more recent ones.

At a certain point I compared Outlook 2007 installed on Vista, and the same version installed on Windows XP. On the second there was a menu item missing (the one represented in the figure).

So I realized that the search query use the indexing option built-in into the OS and that all the e-mail wasn't correctly indexed. However, a button to start to reindex the e-mail inside Outlook wasn't available. I was misled because of the previously mentioned menu item. In fact the "instant search" and "indexing status" button was suggesting me that, also by pressing the "indexing status" item, it always told me that no documents needed to be indexed.

Finally I realized that, just because the pst file wasn't a new file - but a simple copy - the OS indexer didn't correctly index it (or didn't index at all).

I then  entered into the control panel, "System and Maintenance", then "Indexing Option". The pop-up window appeared and I pressed the "Rebuild" button, into the "Troubleshooting" group.

At that point a full reindex of all my hard disk has started again, and at the same time a reindex of the pst too.

Going back to the Outlook interface, I noticed that querying for an e-mail (rather than a contact) a tag line advised me that not all possible message could return due to the re-indexing in progress (See picture below).

I left the text into the search box, and meanwhile the indexing process was going ahead, all the past e-mail start to appear. I finally pulled a sigh of relief, because it could not seek more in the old e-mail was indeed a problem.

 

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Ecco un topic per il quale anche postando su ng dedicati a vista, anche gli MVP di turno non hanno saputo darmi una mano. Dopo un pò di ricerche, è un pizzico di fortuna, ho finalmente trovato la soluzione.

Windows Vista integra un potente motore di ricerca interno che indicizza praticamente tutto il contenuto dell'hard, per consentire alla funzione di search disponibile nel menù start di trovare documenti, e-mail ecc. disseminati nel pc.

Outlook 2007, installato su Windows Vista, si appoggia esclusivamente su questa funzione (ma questo l'ho scoperto solo adesso), tant'è che il motore di ricerca interno al client di posta elettronica, viene praticamente rimpiazzato dalla funzione di indexing di Vista.

Mi è successo per tre riformattazioni consecutive, che "semplicemente" spostando il file .pst con la mia posta e i miei contatti, tutte le vecchie e-mail e i contatti presenti nel file (non quindi i nuovi elementi), erano praticamente introvabili. Questo succedeva anche per i contatti, sempre quelli già presenti.


 

Per capire questa cosa, ho confrontato le versioni di Outlook 2007 installate su un Windows Vista e su un XP. Sul secondo OS, il menù rappresnetato in figura non c'era. Quindi avevo "capito" che la funziona di ricerca era stata demandata al sistema operativo, e che potenzilamente le e-mail non erano indicizzate. Tuttavia, cercando un modo per far partire questa indicizzazione da dentro Outlook, dove del resto mi aspettavo dovesse partire, non c'era un pulsante apposito. 

Infatti, cliccando sul pulsante "indexing status" dentro Outlook 2007 mi diceva sempre che i documenti da indicizzare erano 0.

Mi è venuto allora in mente che, proprio perchè Outlook si appoggia su questa funzione di indicizzazione, dato che il file era stato "copiato", ma non generato di sana pianta, l'indicizzazione sul file in realtà non era stata fatta.

Allora, sono entrato nel pannello di controllo, "System and Maintenace", quindi "Indexing Option".

Dentro alla finestra che appare ho cliccato su Advanced, e a quel punto nel riquadro "Troubleshooting" ho premuto sul tasto "Rebuild".

A quel punto è praticamente ripartita l'indicizzazione di tutto il contenuto del mio hard disk, ma contemporaneamente anche quella del file pst della mia posta.

Infatti, tornando in Outlook, ho potuto notare - immettendo un testo nel casella di ricerca - che una voce mi avvertiva che non tutti i risultati sarebbero comparsi per via del fatto che una indicizzazione era in corso.

 Lasciando il testo ricercato nella casella, mano a mano che l'indicizzazione veniva portata avanti, sono inziati a comparire i documenti corrispondenti al criterio di ricerca immesso. Ho finalmente tirato un sospiro di sollievo, perchè non sapevo più come andare a ripescare documenti vecchi.

Technorati tags: ,

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Sapere "utilizzare" un database da un punto di vista di amministratore, significa anche saperlo mantenere. L'utilizzo eccessivo del db, provoca a lungo andare una frammentazione dei dati nelle pagine, e si rileva quindi necessario riorganizzare o reindicizzare una o più tabelle al fine di ripristinare una buona performance sia in lettura che in scrittura.

Normalmente la percentuale di frammentazione dovrebbe attestarsi non oltre il 35% (Microsoft dice anche il 25%), limite oltre il quale le performance della tabella o del db iniziano a scemare.

Per verificare la percentuale di frammentazione si può ricorrere a questa istruzione:

DECLARE @object_name VARCHAR(20);
SET @object_name = 'TableName'

DBCC SHOWCONTIG (@object_name) WITH TABLERESULTS, ALL_INDEXES

valida per SQL 2000 e SQL 2005 oppure una più elegante

DECLARE @db_id SMALLINT;
DECLARE @object_id INT;

SET @db_id = DB_ID(N'DBName');
SET @object_id = OBJECT_ID(N'TableName');

SELECT * FROM sys.dm_db_index_physical_stats(@db_id, @object_id, NULL, NULL , 'SAMPLED');

valida per il solo SQL 2005.

Nel primo caso la colonna di riferimento sarà la "LogicalFragmentation" nel secondo "avg_fragmentation_in_percent".

Quando questo valore è al di sopra della soglia, si rende necessaria la reindicizzazione. Come?

Un sistema veloce e rapido per reindicizzare tutte le tabelle presenti in SQL Server 2005 grazie all'usilio della SP "nascosta" MSForEachTable può essere questo mostrato qui sotto.

EXECUTE sp_MSForEachTable @command1 =’ALTER INDEX ALL ON ? REBUILD WITH (FILLFACTOR = 90, SORT_IN_TEMPDB = ON, STATISTICS_NORECOMPUTE = OFF, ONLINE = OFF);’

Questo comando cicla tutte le tabelle e reindicizza tutti gli indici ricostruendoli.

Se invece si vuole essere più specifici e reindicizzare la singola tabella allora si può utilizzare quest'altro comando:

DBCC DBREINDEX ('NomeTabella', '', ValoreDiFrammentazione)

valido per SQL 2000 e SQL 2005.

Si tenga tuttavia presente che la ricostruzione degli indici porta via tempo macchina prezioso durante il quale le performance si fanno sentire. Quindi se non è proprio necessaria la ricostruzione, è meglio ipotizzare una semplice riorganizzazione.

A tal proposito all'interno del BOL, sotto la voce sys.dm_db_index_physical_stats c'è un bellissimo esempio che in base la percentuale di frammentazione sceglie se riscotruire o riorganizzare.

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Non riuscirò mai a comprendere perchè Microsoft anche con quest'ultima sfornata di prodotti (Vista, Office 2007 ecc) non abbia incluso in Outlook un bel tastino "Esporta account" come esiste per il fratello minore Outolook Express.

Fortunatamente la struttura del registro sulla quale queste informazioni vengono scritte non è cambiata, quindi che siate su XP o su Vista, che stiate utilizzando Outlook 2003 o Outlook 2007 l'unica cosa che c'è bisogno è il regdit procedendo così:

  1. Aprire il regedit
  2. Trovare la chiave HU\S-1-5-21-.... Ne troverete 2, una che termina con _Classes e una senza. A noi occorre quest'ultima.
  3. Scendere in profondità fino a Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem
  4. Fare tasto destro, esporta in un file di registro avendo cura di selezionare l'opzione esporta tutte le sottocartelle
  5. Copiare il file sul nuovo pc
  6. Aprire su quest'ultimo il regedit e posizionarsi sulla chiave del punto 2. Ovviamente la chiave sarà diversa.
  7. Copiare quella chiave, editare il file di registro e fare un bel replace di tutte le occorrenze vecchie con la nuova chiave.
  8. Chiudere salvando le modifiche, quindi procedere ad un bell'importazione.

Il gioco è fatto. Al successivo riavvio di Outlook i vostri account utente saranno li. La cosa peggiore che potrebbe capitare è che i file pst siano in una posizione differente rispetto a dove erano sul vecchio pc (e questo sicuramente accadrà nel passaggio XP -> Vista, perchè se scegliete di mettere i file pst nella cartella standard di Vista, sul nuovo OS il path è diverso. Ma tutto si risolve semplicemente selezionando con la finestra di sfoglia file proposta la nuova ubicazione del file.

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

La funzione sleep di Vista è molto utile quando ci si allontana dal computer  e non lo si vuole lasciare acceso inutilmente, ma al tempo stesso si vorrebbe evitare al ritorno di riavviare tutte le applicazioni in uso. Essa unisce i vantaggi delle vecchie funzioni di Stand-by e Hibernate.

Tuttavia un "bel" giorno la funziona ha smesso di funzionare sul mio pc, apparentemente senza motivo. Premendo il tasto sleep, il computer dava l'impressione di entrare nello stato di sleep, in realtà tutte le ventole restavano accese ed entrava nello stato di "locked".

Dopo alcune ricerche (sembravo non essere l'unico con questo problema) ho finalmente individuato il problema (e, quindi, la soluzione): quando si attiva il media sharing (quando si configura il Media Center o si collega un Xbox360 come nel mio caso) il computer non entra più nella modalità di sleep, bensì entra nell'Away mode.

La soluzione: andare in power options / advanced settings / multimedia settings ed impostare il valore dell'opzione su "Allow the computer to sleep"

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

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.

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

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.

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

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.

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

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.

IIS 3

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).

IIS 3

IIS 4

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.

Event viewer error

 

 

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: , Server Application Unavailable

Vota questo post per primo

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Il motore FTP di IIS6 è stato notevolmente migliorato rispetto alle versioni precedenti. Che io ricordi configurarlo per un vero ambiente di hosting era un bagno di sudore e comunque le prospettive per una facile gestione erano estremamente lontane.

Non che oggi le cose siano cambiate poi molto. Sicuramente Microsoft potrebbe adoperarsi per implementare un servizio migliore che permetta una vera isolazione degli utenti, con possibilità di assegnare permessi a gruppi di utenti, e con l’aggiunta del quota management.

Di queste ultime tre caratteristiche, con l’introduzione di IIS 6, solo la prima è stata introdotta: addirittura prima di IIS 6, avere un FTP con il servizio Microsoft significava che un utente A dalla sua root poteva salire di un livello, vedere tutte le altre cartelle che erano presenti nella root generale del servizio (e magari se qualche permesso era sbagliato, entrare pure dentro ad una di queste cartelle e far danni).
Certo si potevano creare tanti FTP root quanti erano gli utenti, ma chi è ha tutti questi indirizzi IP da dare gratuitamente? Facile quindi immaginare perché in quasi tutti i servizi di hosting non si trovava – e ancora non si trova – quasi nessuno che utilizza il server FTP di Microsoft.

In merito al quota management (assegnazione dello spazio disco), anche qua il servizio è carente, anzi direi totalmente estraneo. Si può ovviare con un escamotage, utilizzando il servizio a livello “windows”. Passatemi quest’ultima affermazione. In quanto a gruppi di utenti, beh lasciamo stare. Qui forse bisogna aspettare l’arrivo di Longhorn. In realtà potrei vedere come funziona sotto Windows Vista. Presuppongo che il servizio sia lo stesso, ma d’altronde, questo mio articolo verte a voler mettere in piedi un servizio FTP con quanto MS mette a disposizione sul server e null’altro. E dato che l’attuale installazione di Windows 2003 mette a disposizione IIS6, limitiamoci solo ad IIS6 e null’altro.

 

Microsoft finalmente partorì la User Isolation.

Il funzionamento del server FTP di Microsoft è un peletto strano. Parte dal presupposto che:

  1. Non esiste un utente FTP scisso dall’utente Windows, quindi per fornire accesso ad un sito FTP bisogna creare un account sul server o nel dominio, con appositi permessi ridotti (per il vostro bene);
  2. Ad ogni utente FTP deve necessariamente corrispondere una cartella che abbia lo stesso nome dell’account;
  3. La cartella (o home directory utente) deve avere lo stesso nome dell’account Windows che farà login;

Sembra che alla Microsoft hanno pensato che tutti gli utenti necessitassero di una cartella diversa e che ognuno dovesse custodire gelosamente i propri dati. Alla faccia quindi dei principi di collaborazione, di Team Foundation Server e di tutto il lavoro di gruppo in genere.

Commenti a parte, i punti 2 e 3 sono indispensabili, pena tutti gli account che fanno login si ritrovano confinati nella ROOT impostata per il servizio FTP, e se avrete sbagliato con la pianificazione della creazione delle cartelle, tutti potranno vedere tutto. Più avanti farò quindi un esempio di corretta configurazione del servizio FTP per un ambiente multiutente.

Quanto sopra, comunque, non è proprio quello che si chiama uno scenario da hosting. Ammessa e non concessa anche una corretta configurazione poi, fino ad IIS 5.0, non esisteva una vera isolazione utente, e quindi per quanto l’amministratore del server avesse creati all’account specifica per l’utente, ci si ritrova nello scenario poc’anzi descritto, ovvero l’utente semplicemente premendo il tasto “Folder up” del client FTP si ritrovava nella ROOT e da li poteva scorrazzare in giro per le cartelle all’interno del servizio FTP (i danni si potevano limitare con appositi permessi NTFS, ma almeno la visione era possibile per un motivo che spiegherò più avanti).

Questa cosa è stata risolta con IIS6 e la User Isolation: in pratica si tratta di un nuovo modello di configurazione per il servizio FTP (relativo ad uno specifico sito FTP – ricordo che si possono creare molteplici siti FTP sotto lo stesso server) che rende la home directory dell’utente la sua root, al di sopra della quale è impossibile andare.

Le altre due impostazioni disponibili sono “Do not isolate users” (che è il vecchio sistema di default fino ad IIS 5.0) e Isolate User Using Active Directory. Questi ultimi due, per quanto per il primo abbia dato accenno su cosa realmente faccia, non verranno trattati nel seguente articolo.

Attenzione: la scelta su come impostare il modo di isolazione la si può fare esclusivamente durante la creazione del sito FTP, e non la si può assolutamente cambiare a posteriori; pensate prima di agire.

 

Alcune configurazioni essenziali, altrimenti non si va avanti !!

Essenziale perché il servizio FTP di MS possa funzionare sono due aspetti importanti.

1) I permessi utente: ogni utente che accede ad uno specifico sito FTP deve avere almeno i permessi di Lettura e di Folder listing; pena errore 530 User ftp_adhoc cannot log in, home directory inaccessibile. Questo spiega perché era sempre possibile vedere tutto il contenuto delle varie cartelle fino ad IIS 5.0 e anche con IIS 6.0 se configurato in modalità “Do not isolate user”.

Consiglio pratico: create un gruppo di utenti, con i soli permessi di List e read, associateci tutti gli account windows che utilizzeranno il servizio FTP e assegnate a livello NTFS questo gruppo alla ROOT del sito FTP, facendo in modo da abilitare la propagazione dei permessi partendo dal padre, così che per ogni nuova cartella creata, sempre e comunque tutti gli utenti di quel gruppo avranno garantita la lettura (che sarà invece circoscritta dalla user isolation) .

2) Partendo da una data directory X che sarà per noi la Home Directory del servizio FTP o ROOT che dir si voglia, per creare una Home Directory specifica per l’utente in modalità Isolated user e fare in modo che quello sia il suo punto di partenza e non possa andare oltre, bisogna creare dentro la X una cartella denominata LocalUser e dentro a questa cartella create tante cartelle, una per ogni account Windows che farà login al servizio FTP.

Per intenderci quindi avremo una struttura di questo tipo:

C:\FTP <Home del server FTP>

C:\FTP\LocalUser\Public <Home directory per l’account anonymous qualora lo abilitiate>

C:\FTP\LocalUser\Test <Home directory per l’account test>

C:\FTP\Domain\Test <Dove al posto di domain ci deve essere scritto il nome del dominio, qualora il server sia appartenga ad un dominio o sia lui stesso un PDC>.

 

Un caso reale

Create un nuovo sito FTP e seguite il wizard. Per quanto riguarda i permessi da assegnare alla ROOT directory, indichiamo sia lettura che scrittura e non preoccupiamoci di questo, perché il servizio FTP verifica i reali permessi dell’account che si sta loggando prima a livello di FileSystem e poi a livello di servizio.

Mi spiego meglio: ipotizziamo di impostare a livello di servizio i permessi in lettura/scrittura per la ROOT ma nella scheda Security (permessi NTFS) della cartella X indichiamo solo quelli di lettura per l’account Test. Test in quella cartella non scriverà mai.

Dopo aver ultimato il wizard, create un gruppo di utenti per l’accesso FTP, un utente vero e assegnatelo al gruppo. Create la sua home directory come descritto nel paragrafo precedente.

Se avete seguito tutto fin qua descritto, vi ritroverete con un servizio FTP parzialmente utilizzabile. Perché? Beh, l’impossibilità di poter redirigere un utente su di uno specifico path, rende di fatto il servizio FTP come una specie di storage folder personale. Ma cosa succede se due account utente (perché utenti dello stesso sito) devono poter inserire/modificare/cancellare dati nella stessa directory?
Così come siamo questa cosa è impossibile. Impensabile di mettere lo stesso contenuto nelle due home directory. Chi sincronizzerebbe il contenuto e con che precedenza? Ma soprattutto perché far fare del lavoro inutile ad un software di terze parti?

La soluzione è quindi quel