Quando mi trovo a dover sviluppare una nuova soluzione sharepoint per un cliente che non abbia ancora installato Sharepoint, procedo allo sviluppo iniziale su Virtual Machine.
In questo modo replico esattamente l'ambiente che dovrà avere il cliente(versione di WSS, Sql Server e language pack) ed al primo deploy sarà sufficiente effettuare un semplicissimo e velocissimo backup & restore.
Ma attenzione, perchè nel momento decisivo del deploy potrebbe capitare quanto successo a me e farvi perdere tempo oltre che provocarmi un temporaneo "attacco di panico":
1) Installate sul server del cliente esattamente lo stesso ambiente che avete sulla vostra vm: il wss 3.0 inglese, il language pack italiano e stessa configurazione(standalone per esempio).
A questo punto il restore vi segnala un errore dicendo che la il backup(eseguito tramite stsadm) non può essere completato a causa della diversa versione di sharepoint tra il pacchetto di backup e l'ambiente su cui si sta facendo il restore.
Panico...ma come è possibile ? La versione installata dal cliente è "inferiore" a quella che ho sulla mia vm da cui ho creato il package di backup ? Certo. Se la vostra vm ha subito gli aggiornamenti via windows update, avrà certamente ricevuto alcune hotfix per wss 3.0 e queste ne hanno incrementato il numero di versione.
Per risolvere è sufficiente lanciare il windows update sul server del cliente e scaricare tutti gli aggiornamenti, compresi le hotfix di sharepoint rilevate.
2) Tutto sembrava a posto, l'errore precedente non viene pià segnalato, ma durante il restore un altro errore ancora più misterioso compare:
"Access to the table dbo.sites is blocked because the signature is not valid"
Una veloce "googglata" ed ecco la soluzione:
http://support.microsoft.com/kb/944154
Eseguo attentamente quanto specificato nel link sopra, rilancio il restore e mi ritrovo con tutto l'ambiente di sviluppo perfettamente replicato sul portale del cliente.
E anche questa è fatta!