In ASP.NET 4.0 sono stati apportati dei cambiamenti a livello di Code Access Security (CAS ).
Questi cambiamenti sono necessari ad apportare maggiore sicurezza e controllo nell'esecuzione delle applicazioni. Di default, la configurazione della CAS di ASP.NET 4.0 è più restrittiva rispetto alle versioni precedenti, e questo può essere causa di eccezzioni nel caso applicazioni esistenti (che utilizzano versioni precedenti del framework) vengano pubblicate su hosting con la versione 4.0 del framework.

Nel mio caso mi sono ritrovato con la seguente eccezzione:

System.TypeInitializationException:
The type initializer for 'PingFM.PingFMApi' threw an exception.
---> System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
at System.Security.CodeAccessSecurityEngine.Check(Object demand, StackCrawlMark& stackMark, Boolean isPermSet)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark) at System.Security.CodeAccessPermission.Demand()
at System.Reflection.RuntimeAssembly.VerifyCodeBaseDiscovery(String codeBase)
at System.Reflection.RuntimeAssembly.GetName(Boolean copiedName)
at System.Reflection.Assembly.GetName()
at PingFM.PingFMApi..cctor()
--- End of inner exception stack trace ---
at BlogEngineToPingFm.Ping(Post item, Uri itemUrl, ExtensionSettings settings)

Una possibile soluzione è modificare la configurazione dell'applicazione, in modo che la CAS abbia lo stesso comportemento delle precedenti versioni di ASP.NET.
Per fare ciò, nel file web.config sarà necessario valorizzare l'attributo legacyCasModel a True, presente nell'elemento trust. (Prestate attenzione al livello di trust che andate ad utilizzare)

<system.web>
    <trust level="Medium" legacyCasModel="true" />
</system.web>

Per maggiori informazioni sull'argomento, cosiglio la lettura dei seguenti link:
Code Access Security in ASP.NET 4 Applications 
What is New in ASP.NET 4.0 Code Access Security
Changes to the ASP.NET Code Access Security (CAS) Implementation

Ecco disponibili al download codice e slide della sessione What's new in ASP.NET 4.0 che ho tenuto al Visual Studio 2010 Community Launch che si è tenuto il 15 Aprile 2010 a Marghera Venezia.

Il Microsoft .NET Framework è in continua evoluzione ed ha raggiunto la versione 4.0 accompagnato da moltissime novità. In questa sessione andremo in dettaglio per ciò che riguarda l'ultima versione di ASP.NET 4.0, ponendo il focus sulle nuove funzionalità e sui cambiamenti più importanti. Con esempi pratici vedremo come questa nuova versione agevolerà lo sviluppatore nel realizzare le proprie applicazioni. Maggiore controllo del codice prodotto, SEO, nuovi template project, Script Loader, Client Data Access e migliorie ai controlli esistenti, sono solo alcuni degli argomenti che verranno trattati.

Ecco disponibili al download, il codice e le slide dell'evento che ho tenuto il 9 Aprile 2010 su Microsoft ASP.NET MVC 2.0.

•  
  • Codice: http://files.dottor.net/xedotnet/XeDotNet.Dottor.MVC_code.zip
  • Slide: http://files.dottor.net/xedotnet/XeDotNet.Dottor.MVC_slide.zip

Per chi non avesse partecipato al community meeting, nel codice è presente una semplice ma completa applicazione, (ovviamente) realizzata in ASP.NET MVC 2.0, che permette la gestione e visualizzazione di news:

• Pannello di controllo (utenti autenticati),
• Inserimento, Modifica, Cancellazione News (utenti autenticati)
• Visualizzazione lista news
• Visualizzazione dettaglio news
• Inserimento commenti nel dettaglio news

Giovedì 15 Aprile 2010 si terrà l'evento Community Tour - Visual Studio 2010, per il lancio della nuova versione di Visual Studio.
Il luogo dell'evento sarà:

Hotel Holiday Inn Venice
Rotonda Romea 1/2 
30175 Marghera (VE)

e ci terremo compagnia per un'intera giornata, piena zeppa di interessanti sessioni, che ci vedranno impegnati dalle 9.30 alle 18.15 con la seguente agenda:

• 09:00 - Registrazione
• 09:30 - Apertura Lavori e Keynote con Vittorio Bertocci
• 10:20 - Vittorio Bertocci - Claims-based identity e Windows Identity Foundation
• 11:25 - Sospensione
• 11:40 - Davide Vernole - Microsoft Test Manager, mai più senza!
• 12:45 - Lorenzo Barbieri - Introduzione allo sviluppo con Windows Phone 7 Series
• 13:45 - Pausa Pranzo (a carico dei convenuti)
• 14:45 - Andrea Boschin - Silverlight 4.0 Overview
• 15:50 - Andrea Dottor - What's new in ASP.NET 4.0
• 17:10 - Davide Senatore - WPF 4.0 – The Golden Age of Windows Client
• 18:15 - Chiusura lavori

Agenda completa e abstract: Community Tour Visual Studio 2010
Registrazione: clicca qui

Vi aspettiamo numerosi!!

Non so come mai, ma utlimamente mi scontro con problematiche non molto documentate. Una di queste è la possibilità di lanciare l'esecuzione di Package di SQL Server Integration Services da un'applicazione ASP.NET.

Cercando in rete, ho trovato solamente due possibili soluzioni, entrambe elencate in questo post. Una soluzione richiede la chiamata ad un job di SQL Server Agent, mentre l'altra soluzione fa uso di un Web Service da pubblicare nella macchina di SQL Server.

La prima soluzione l'ho scartata in quanto non sono riuscito a trovare il metodo per poter passare dei parametri utili a valorizzare le variabili del package (mia ignoranza). Mentre la seconda richiede di installare un'ulteriore applicazione (da dover poi mantenere e ripubblicare), nella macchina di SQL Server, e quindi anche questa scartata.
Può sembrare banale, ma avere un'applicazione in più da mantenere non è sempre semplice, specialmente nel caso l'applicazione sia distribuita in diversi server, e sia presente in casa di diversi clienti.

Guardando le diverse soluzioni, mi è venuta l'idea di provare a adattare la soluzione del Web Service, ma eseguita direttamente da un server remoto. Devo ammettere che ci sono state svariate problematiche, ma alla fine, sono arrivato ad una soluzione perfettamente funzionante.

Ecco come eseguire un package di SSIS da remoto:

Per l'esecuzione del package sarà necessario creare un utente nel database (oppure utilizzarne uno di esistente) ed assegnargli il ruolo db_dtsoperator nel database msdb. Questo ruolo attribuisce all'utente i permessi di:

• Enumerate all packages.
• View all packages.
• Execute all packages.
• Export all packages.
• Execute all packages in SQL Server Agent.

Per quanto rigurda la connessione verso il database, nel web.config ho creato una ConnectionString che contiene solamente "Data Source", "User ID" e "Password", questo perchè poi tramite l'uso della classe DbConnectionStringBuilder, verrà poi parsata per recuperarne i singoli valori. Così ho un unico punto dove saranno contenute le credenziali di accesso.

   1: <add 

   2:   name="olapServerAuth"

   3:   connectionString="Data Source=192.168.0.100;User ID=usr;Password=p4$$w0rd;" 

   4:   providerName="System.Data.EntityClient" />

Nell'applicazione sarà necessario referenziare la dll Microsoft.SQLServer.ManagedDTS, e aggiungere alla classe uno using a Microsoft.SqlServer.Dts.Runtime.

Il codice per eseguire il package da remoto sarà il seguente:

   1: // recupero delle informazioni per l'autenticazione al server

   2: DbConnectionStringBuilder cs = new DbConnectionStringBuilder();

   3: cs.ConnectionString = ConfigurationManager.ConnectionStrings["olapServerAuth"].ConnectionString;

   4:  

   5: Application integrationServices = new Application();

   6: // recupero del package che deve essere presente in SQL Server

   7: Package package = integrationServices.LoadFromSqlServer(

   8:                         @"\Data Collector\Test\TestETL",

   9:                         cs["Data Source"] as string,

  10:                         cs["User ID"] as string,

  11:                         cs["Password"] as string,

  12:                         null);

  13:  

  14: // set delle variabili

  15: Variables variables = package.Variables;

  16: variables["VariabileDaSettare"].Value = valoreDaSettare;

  17:  

  18: // set delle connessioni

  19: Connections connections = package.Connections;

  20: connections["AdoNetAnalysisDatabase"].ConnectionString = ConfigurationManager.ConnectionStrings["AdoNetAnalysisDatabase"].ConnectionString;

  21:  

  22: // esecuzione del package

  23: DTSExecResult result = package.Execute(connections, variables, null, null, null);

  24: if (result != DTSExecResult.Success)

  25:     ... // errore nell'esecuzione

  26: else

  27:     ... // avvio corretto del package

Da notare che:

• DbConnectionStringBuilder: permette di recuperare ogni singolo elemento che compone una ConnectionString. Utile in questo caso per salvare i dati del server di SQL Server, il nome dell'utente di accesso, e la relativa password in un unico container, e poterli poi recuperare singolarmente.
  
• Application.LoadFromSqlServer: permette di recuperare un package presente in SQL Server. Se i campi username e password non vengono valorizzati, viene fatto uso della windows authentication.
  
• package.Variables: recupero delle variabili utilizzate nel package. Utile nel caso sia necessario modificarne il valore di default prima dell'esecuzione.
  
• package.Connections: recupero delle connessioni utilizzate nel package. Da notare che oltre alle stringhe di connessione, compaiono in questa lista anche le connessioni per i Flat File.
  In questi elementi devono essere presenti tutti i valori richiesti, come ad esempio nel caso di una connessione OLEDB dovranno essere presenti: Provider, Application Name e Auto Translate. (per facilità controllate come sono composte nel vostro package).
  
• package.Execute: avvia l'esecuzione del package con le nuove variabili e connessioni impostate. 
  
• In caso di non successo nell'esecuzione del package, in package.Errors saranno presenti gli errori.

Devo ammettere che ricostruire questo codice non è stato per niente facile, in quanto gli errori che mi si presentavano non erano proprio semplici da decifrare.
La maggiore difficoltà è stata nel capire che le connessioni dovevano riportare tutti i parametri (gli stessi che si possono vedere quando si esegue il package dal SQL Management Studio), ed infine anche il capire quali fossero i permessi minimi da dover dare all'utente per poter eseguire il tutto (per evitare problematiche di sicurezza).
Ma alla fine, tutto ha funzionato alla perfezione, e questo ripaga del tempo speso/investito in questa soluzione.

Ecco disponibile per il download il codice e le slide della mia sessione "Write less do more...with jQuery" tenuta venerdì 5 Marzo 2010.

• Codice: http://files.dottor.net/xedotnet/XeDotNet.jquery-code.zip
• Slide: http://files.dottor.net/xedotnet/XeDotNet.jquery-slide.zip

Come scritto nel post precedente, stò dando all'utente finale la possibilità di gestirsi gli snapshot direttamente dall'applicazione, ed ora tocca alla fase di creazione di uno snapshot.

Come ben sapete (e come ho scritto in questo post) gli snapshot vengono creati utilizzando i valori di default dei parametri.
Reporting Services fornisce la possibilità di forzare la creazione di uno snapshot tramite il metodo CreateReportHistorySnapshot, che si comporta esattamente come il pulsante presente nel sito di sharepoint di Reporting, che crea lo snapshot utilizzando i valori dei parametri in quel preciso istante (quindi facendo uso dei valori di default).

Ma se volessimo eseguire uno snapshot che abbia diversi parametri?
E' il caso in cui il report abbia le date o dei filtri calcolati in automatico, magari perchè deve venire eseguito con i dati della settimana precedente, o del mese precedente. Però Il cliente potrebbe avere la necessità di rigenerare il report riferito ad un perioso diverso (magari di 2 settimane prima).
In questo caso si può intervenire andando a modificare da codice i valori di default dei parametri del report, e dopo aver eseguito lo snapshot, ripristinarli ai valori normali.

Ecco qui il codice da qui potete prendere spunto:

   1: using (ReportingService2005SoapClient rs = this.CreateReportingService2005SoapClient())

   2: {

   3:     string batchID = string.Empty;

   4:     ServerInfoHeader infoHeader = rs.CreateBatch(out batchID);

   5:     BatchHeader bh = new BatchHeader()

   6:     {

   7:         BatchID = batchID,

   8:         AnyAttr = infoHeader.AnyAttr

   9:     };

  10:     CatalogItem[] items = null;

  11:     rs.ListChildren(reportFolder, true, out items);

  12:  

  13:     foreach (var item in items)

  14:         if (string.Compare(item.ID, reportId.ToString(), true) == 0)

  15:         {

  16:             // recupero gli attuali parametri e mi tengo una copia degli originali

  17:             ReportParameter[] defaultParameters = null;

  18:             ReportParameter[] parameters = null;

  19:             rs.GetReportParameters(item.Path, null, false, null, null, out defaultParameters);

  20:             rs.GetReportParameters(item.Path, null, false, null, null, out parameters);

  21:  

  22:  

  23:             foreach (ReportParameter parameter in parameters)

  24:             {

  25:                 //modifico i valori dei parametri che voglio cambiare

  26:                 if (string.Compare(parameter.Name, "dateStart", true) == 0)

  27:                     parameter.DefaultValues = new string[] { string.Format("{0:s}", startDate) };

  28:                 else if (string.Compare(parameter.Name, "dateEnd", true) == 0)

  29:                     parameter.DefaultValues = new string[] { string.Format("{0:s}", endDate) };

  30:             }

  31:             // setto i parametri modificati nel report

  32:             rs.SetReportParameters(bh, item.Path, parameters);

  33:             string historyId = string.Empty;

  34:             Warning[] warnings = null;

  35:             // creo lo snapshot

  36:             rs.CreateReportHistorySnapshot(bh, item.Path, out historyId, out warnings);

  37:             // setto i parametri originali

  38:             rs.SetReportParameters(bh, item.Path, defaultParameters);

  39:             // eseguo il tutto sotto un'unica transazione

  40:             rs.ExecuteBatch(bh);

  41:             return;

  42:         }

  43: }

Faccio notare che il tutto viene eseuito sotto un'unica transazione al comando rs.ExecuteBatch(bh), e in caso di errori, il report continuerebbe ad avere i suoi normali valori di default e non i valori da noi modificati.

Può capitare di voler dare la possibilità all'utente di cancellare uno snapshot di un determinato report, e dargli la possibilità di farlo direttamente dall'applicazione che abbiamo realizzato.

Oggi mi sono scontrato con questa problematica, e uscirne non è stato proprio immediato a causa della scarsa documentazione a riguardo. Spero quindi che questo post sia utili a qualcuno.

Nella classe ReportingService2005SoapClient (del proxy generato verso il WebService di Reporting Services) esiste un metodo DeleteReportHistorySnapshot che si occupa per l'appunto di cancellare un preciso snapshot (DeleteReportHistorySnapshot), ma il come utilizzarlo è stato un pò oscuro.

Ecco qui il codice finale, che recupera il path del report, conoscendone l'id (scorrendo i report contenuti in una precisa cartella), e successivamente richiama la cancellazione dello snapshot avente l'historyId conosciuto.

   1: using (ReportingService2005SoapClient rs = this.CreateReportingService2005SoapClient())

   2: {                

   3:     string batchID = string.Empty;

   4:     ServerInfoHeader infoHeader = rs.CreateBatch(out batchID);

   5:     BatchHeader bh = new BatchHeader()

   6:     {

   7:         BatchID = batchID,

   8:         AnyAttr = infoHeader.AnyAttr

   9:     };

  10:  

  11:     CatalogItem[] items = null;

  12:     rs.ListChildren(reportFolder, true, out items);

  13:  

  14:     foreach (var item in items)

  15:         if (string.Compare(item.ID, reportId.ToString(), true) == 0)

  16:         {

  17:             rs.DeleteReportHistorySnapshot(bh, item.Path, historyId);

  18:             rs.ExecuteBatch(bh);

  19:         }

  20: }

La difficoltà è stata nel capire cosa fosse il BachHeader, e il di dover chiamare rs.ExecuteBatch,  che si occupa di lanciare i comandi che sono stati inviati utilizzando lo stesso BatchHeader sotto un'unica transazione. Non avendo mai fatto uso (in passato) di metodi a cui viene passato un oggetto BatchHeader, questa soluzione non mi è venuta proprio spontanea.

Ecco un link a riguardo delle operazioni eseguite in batch in reporting services: Batching Methods

E' da molto che seguo questo progetto, e chi mi segue, sa che ne ho scritto una guida pubblicata su html.it (Guida BlogEngine.NET).
L'ultima release di questo engine risale alla versione 1.5.0 del 13 Aprile 2009 (veramente datata), ma per poter usufruire/conoscere/testare le varie funzionalità aggiunte a BlogEngine.NET, ho sempre tenuto aggiornato questo blog con l'ultima versione di sviluppo, e vi posso assicurare che ha fatto dei notevoli passa avanti.

E' con gran piacere che oggi apprendo (BlogEngine.NET 1.6.0 is Released)  che è stata rilasciata una nuova release, la 1.6.0, con parecchie novità.
Tra le più importanti troviamo l'inserimento di un filtro per i commenti, che di default viene fatto con le Akismet, ma anche con regole custom, e con la possibilità di svilupparsi dei proprio filtri.
Altra novità, che attendevo da molto è la presenza di una pagina per la moderazione/gestione dei commenti, evitando quindi di dover andare nelle pagine dei post.
Ma le novità non si fermano qui, ed ecco la lista completa:

• Centralized Comment Management
• Automated Comment Spam Filtering with ability to plug-in custom Filtering modules
• Multiple Widget Zones
• Referrers data and Blogroll items now stored in Database when using the DB blog provider.
• Unsubscribe Link in Comment Notification Emails
• Referrer Data can be Stored for more than 7 days.
• Blogroll items can now be Ordered.
• Newsletter Widget more Intelligent - Emails sent when a post is going from an Unpublished to Published state.
• Twitter Widget - New options and improvements
• Page Slugs now saved in Database.
• New Logging system to Track events and errors.
• Unhandled Exception Handling
• Fixes to Comment Notification Emails not being sent out correctly in some cases.
• Outgoing Email improvements
• Many other improvements and fixes

Ecco quindi il link per il download di BlogEngine.NET 1.6.0: download

Visto la mia scoperta a riguardo di Linq to Twitter, mi sono chiesto se qualcuno avesse anche scritto un provider LINQ per Facebook, ed ecco che sempre da codeplex spunta il progetto LINQ to FQL, un provider di LINQ che si interfaccia direttamente con le API di Facebook.

Un articolo a riguardo di questa libreria lo trovate a questo link su codeproject:
Facebook Developer Toolkit LINQ to FQL Addon
mentre direttamente su CodeRun trovate il codice disponibile per testare subito la libreria:
CodeRun - LINQ to Facebook

Ed ecco un esempio di sintassi:

   1: var db = new FacebookDataContext();

   2: //LINQ Query Syntax

   3: var myUser = from user in db.user where user.uid == db.uid select user;

   4: //LINQ Method Syntax (the same query)

   5: var myUser2 = db.user.Where(t => t.uid == db.uid);

Una cosa che non condivido a pieno di questa libreria, è l'aver mantenuto gli stessi nomi degli oggetti e proprietà utilizzati da Facebook, mentre io avrei preferito fossero stati rinominati con qualcosa di più leggibile/parlante (e che rispetti le Naming Convention). Capisco altresì che uno sviluppatore, in questo modo, può utilizzare la stessa documentazione delle API di Facebook per capirne il significato e l'utilità.