E’ uscita la preview di quello che sarà l’evoluzione della tecnologia dynamic data. Eccellente: controlli più sofisticati, relazioni N a N, possibilità di filtraggi sulle gridview più granulari, e un sacco di altre feature carine ma soprattutto utili.

Peccato che importando le DLL nei progetti web in VS capiti che il progetto non compili più, perchè le DLL contenute nella GAC (quelle originali del framework) contengano le stesse definizioni di metodi e classi di questa nuova versione. E il compilatore – giustamente – s’incazza perchè non sa quale versione utilizzare.

Error    7    Il tipo 'System.ComponentModel.DataAnnotations.MetadataTypeAttribute' esiste sia in 'c:WindowsassemblyGAC_MSILSystem.ComponentModel.DataAnnotations3.5.0.0__31bf3856ad364e35System.ComponentModel.DataAnnotations.dll' che in 'c:UsersCaioAppDataLocalTempTemporary ASP.NET Filesxxxf719f7a77b9814d9assemblydl3�a760a26�007f03e_bcd3c901System.ComponentModel.DataAnnotations.DLL'

Error    1    Il tipo 'System.Web.DynamicData.FilterUserControlBase' esiste sia in 'c:UsersCaioAppDataLocalTempTemporary ASP.NET Filesxxxf719f7a77b9814d9assemblydl3�57b97ce�007f03e_bcd3c901System.Web.DynamicData.DLL' che in 'c:WindowsassemblyGAC_MSILSystem.Web.DynamicData3.5.0.0__31bf3856ad364e35System.Web.DynamicData.dll'

Peccato anche che non ci siano spiegazioni su come far funzionare il tutto (anche se, effettivamente, copiare le dll nel posto giusto non è poi così complicato), e che in questo caso non sia chiaro come proseguire in presenza di questo errore.

tagPrefix="asp" namespace="System.Web.DynamicData" assembly="System.Web.DynamicData, Version=99.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/;

La soluzione consiste nel modificare la dichiarazione della libreria dynamicdata nel web.config in modo che la versione utilizzata sia quella di codeplex e non quella ufficiale del framework:

e nel sostituire le versioni delle librerie che vogliamo utilizzare da quelle pescate dalla GAC a quelle importate dal nostro progetto.

Poniamo il caso in cui sia necessario utilizzare dei database che contengono per caso 2 tabelle uguali, o in cui comunque ci siano gli stessi nomi di tabella, e includerli in un modello LINQ to SQL per riutilizzarli ad esempio con dynamic data.

Se ci limitiamo a creare i dbml e ad aggiungervi le tabelle del nostro DB, al primo CTRL + B il compilatore di Visual Studio fallirà riportando tanti errori quante ridefinizioni delle stesse tabelle troverà.

Per risolvere questo problema è sufficiente aggiungere un Context Namespace ed un Entity Namespace per ogni dbml, in modo che durante la compilazione non ci saranno conflitti nella dichiarazione delle classi (visto che le tabelle sono rappresentate da classi nel dbml).

Ovviamente sarà necessario scegliere la connessione corretta per gestire il DB relativo al dbml, dichiarata preventivamente nel web.config, e visto che probabilmente vorremo usare il dbml nel progetto, ad esempio con dynamic data, dovremo modificare il global.asax dicendogli di utilizzare il datacontext corretto ed eventualmente registrando le nuove routes.

Un buon articolo su come fare per registrare diverse routes di diversi dbml è disponibile qui.

Errore interno del compilatore: fase 'BIND'

Errore interno del compilatore: fase 'COMPILE'

Internal Compiler Error: stage 'BIND'

dopo parecchio tempo alla ricerca della causa riesco a circoscrivere il problema, e alla fine scopro che il mancato parsing di una variabile di sessione a stringa manda in palla il compilatore che non riesce a completare il suo lavoro.

Basta un pezzo di codice come questo nel page_load di una pagina aspx:

if (Session["VarToControl"] != "myPersonalValue")
Response.Redirect("/URLRedirect/Page.aspx");

per sollevare il problema, mentre per risolverlo è sufficiente convertire a stringa il valore letto in questo modo:

if (Session["VarToControl"].ToString() != "myPersonalValue")
Response.Redirect("/URLRedirect/Page.aspx");

e come per magia tutto riprende a compilare senza problemi..