Questa è una di quelle notizie che meritano di essere riportate anche solo come link. Ora vedrò di studiarmi bene il sorgente di ASP.NET, nell'attesa di LINQ, WCF e WF (che non sono ancora disponibili), anche se magari finirò ancora per continuare ad usare Reflector, almeno se non devo fare debug ma studio, ricerca e sviluppo. Interessante anche il fatto che dovrebbero rendere disponibile un download per l'utilizzo off-line dei sorgenti in debug.
Un titolo complicato :-) per un post semplice!
Oggi ho riscontrato un problema con SharePoint Designer 2007. Da un PC del dominio del mio ufficio, con i profili e i folder salvati su Distributed File System via Group Policy, non riuscivo a creare workflow su un site MOSS2007.
Il problema era in realtà molto semplice: il folder che contiene gli Application Data degli utenti, viene utilizzato da SD2007 per salvare in una cache temporane degli assembly, tra cui quelli con le activity offerte dai vari portali MOSS2007/WSS3 a cui ci si collega.
In pratica in <User Folder>\Application Data\Microsoft\SharePoint Designer\ProxyAssemblyCache\12.x.y.z vengono salvati gli assembly scaricati dai vari server MOSS2007/WSS3. SD2007 poi carica questi assembly per metterceli a disposizione durante la definizione dei workflow. Ora dal momento che nel mio caso il folder <User Folder>\Application Data\ risiedeva su di una share raggiunta via DFS, la Code Access Security di .NET - giustamente - non dava un livello di trust adeguato agli assembly, quindi SD2007 falliva durante il loro caricamento.
L'errore restituito era un criptico po': "Failed to load the workflow". Guardando però cosa SD2007 tentava di caricare, ho capito l'arcano mistero. Sono dovuto andare in "Microsoft .NET Framework 2.0 Configuration" dagli strumenti amministrativi della macchina, per definire un code group (a livello di macchina nel mio caso) che corrispondesse alla URL \\dominio\DFSRoot\* (attenzione al \* in fondo che è necessario) per dire poi che volevo dare ai file provenienti da quella URL un livello di trust pari a quello che ho su "My Computer", simulando il fatto che i file provengano dal mio disco locale anziché dal profilo sul server, cioè in questo caso "Full Trust". Ora tutto funziona regolarmente.
Probabilmente se non avessi saputo come funziona la Code Access Security di .NET ... sarei ancora lì :-) a cercare la causa del problema. Per questo insisto sempre sul fatto che anche i sistemisti dovrebbero conoscere almeno di massima il funzionamento di .NET!