Visual Studio 2013

EF 6.1 : What’s new (3)

Pietro Libro — Thu, 27 Mar 2014 10:04:00 GMT

Supporto a “.ToString()” e “String.Concat()”, un esempio: var queryConcat = from c in db.Vehicles where string.Concat(c.EngineSize, c.HP).Equals("1600110") select c; var queryToString = from c in db.Vehicles where c.HP.ToString().Equals("110") select c; Abbiamo due Query LINQ che filtrano i dati in base a condizioni su stringhe, la prima “tira fuori” tutti i veicoli dove la concatenazione dei valori delle proprietà “EngineSize” e “HP” è uguale a “1600110”, mentre la seconda esegue un filtro su di un valore intero convertio in stringa. Se proviamo ad eseguire il codice in un ambiente con EF 6.0 otteniamo un’eccezione a runtime in tutti e due i casi: Con EF 6.1 le query sono eseguite correttamente: Cosa succede dietro le quinte: SELECT [GroupBy1].[A1] AS [C1] FROM ( SELECT COUNT(1) AS [A1] FROM [DomusDotNet].[Vehicles] AS [Extent1] WHERE N'1600110' = (CASE WHEN ([Extent1].[EngineSize] IS NULL) THEN N'' ELSE [Extent1].[EngineSize] END + CAST( [Extent1].[HP] AS nvarchar(max))) ) AS [GroupBy1] SELECT [GroupBy1].[A1] AS [C1] FROM ( SELECT COUNT(1) AS [A1] FROM [DomusDotNet].[Vehicles] AS [Extent1] WHERE N'110' = CAST( [Extent1].[HP] AS nvarchar(max)) ) AS [GroupBy1] Da analizzare il funzionamento di “String.Concat(…)” con SQL Server 2012 per verificare la conversione in SQL con la funzione “nativa SQL” “Concat”.

EF 6.1 : What’s new (2)

Pietro Libro — Thu, 20 Mar 2014 17:49:00 GMT

Altra feature introdotta, l’attributo “IndexAttribute” che ci permette di definire un indice su una o piu’ colonne. Ad esempio, per creare un indice (di nome “IX_FreeDailyKm”) sulla proprietà “FreeDailyKm” del nostro modello, scriviamo: [Index("IX_FreeDailyKm_Clustered", IsUnique = false, IsClustered = false)] public int FreeDailyKm { get; set; } Mentre per creare un indice che insiste su due proprietà, è sufficiente utilizzare lo stesso nome come da esempio: [Index("IX_Engine", 2)] public string EngineSize { get; set; } [Index("IX_Engine", 1)] public int HP { get; set; } Utilizzando EF migrations per aggiornare il database, avremmo: CreateIndex("DomusDotNet.Vehicles", "FreeDailyKm", name: "IX_FreeDailyKm_Clustered"); CreateIndex("DomusDotNet.Vehicles", new[] { "HP", "EngineSize" }, name: "IX_Engine"); Quindi, a livello di database:

EF 6.1 : What’s new (1)

Pietro Libro — Thu, 20 Mar 2014 12:42:00 GMT

Da qualche giorno è stata rilasciata in RTM la versione 6.1.0 di Entity Framework. Una delle novità piu’ interessanti è sicuramente la possibilità di utilizzare l’approcio Code First partendo da un database esistente (potrebbe sembrare strano, ma se pensiamo ad un nuovo sviluppo potrebbe non esserlo). I “ferri” da utilizzare sono ovviamente EF 6.0.1 e la nuova versione di EF Tools, “scaricabile” per VS 2012 e VS 2013 seguendo questo link. Per un semplice test, apriamo VS 2013 (o 2012), magari creando un semplice progetto “Console” al quale aggiungiamo tramite NuGet i riferimenti a EF 6.0.1. Poi tasto destro sul progetto e “Add New Item”, e scegliamo “ADO.NET Entity Data model”: Il testo di “Name” infuenzerà il nome della classe “DbContext” generata. Dalla scheramata successiva (“Entity Data Model Wizard”) scegliamo “Code First model from Database”: Nella schermata successiva del Wizard verrà chiesta la connessione dati da utilizzare (eventualmente ne creiamo una nuova), nel mio caso, per i test ho utilizzato un DB di un evento “DomusDotNet”. L’ultimo passo è la scelta degli oggetti da “importare”: Dopo aver premuto “Finish” e qualche secondo di pazienza, VS aggiungerà all’alberatura del progetto, tutte le classi necessarie, una “buildata” per verificare che sia tutto a posto , e qualche riga di codice per verificare l’estrapolazione dati : using (CarRental db = new CarRental()) { System.Console.WriteLine("There are {0} cars.", db.Cars.Count()); System.Console.ReadKey(); }

Dynamic Data Provider per EF6 released

Pietro Libro — Mon, 03 Mar 2014 10:06:00 GMT

Sono stati rilasciati in RTM, ASP.NET Dynamic Data e EntityDataSource per EntityFrameowrk 6. Per provare la nuova versione di Dynamic Data è sufficiente creare un nuovo progetto di tipo “ASP.NET Dynamic Data Entities Web Application”, ed installare tramite NuGet il package Microsoft.AspNet.DynamicData.EFProvider: Eventualmente forziamo la scrittura dei Template (“A” per sovrascrivere tutto): Aggiungiamo in modalità Code First una semplice classe Book e relativo DbContext: public class Book { public int Id { get; set; } public string Title { get; set; } public string Authors { get; set; } public int Pages { get; set; } } public class Db : DbContext { public DbSet<Book> Books { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); } } Nel Global.asax registriamo il nostro DbContext: DefaultModel.RegisterContext( new Microsoft.AspNet.DynamicData.ModelProviders.EFDataModelProvider(() => new Db()), new ContextConfiguration { ScaffoldAllTables = true }); F5, per vedere in azione il nostro Data Site: Discorso simile per l’utilizzo dell’EntityDataSource control.

Windows Azure WebJobs (parte 4)

Pietro Libro — Mon, 17 Feb 2014 10:02:00 GMT

Per automatizzare tramite script il processo di creazione di un WebJob utilizzando Windows Azure Power Shell (Windows PowerShell ISE), i principali comandi da utilizzare sono: Add-AzureAccount, che ci permette di autenticarci utilizzando Active Azure Directory Get-AzureWebsite, per avere una panoramica dei WebSites legati alla subscription con la quale siamo collegati Get-AzureWebsiteJob, il quale ritorna le informazioni sul WebJob specificato dal paramentro Name New-AzureWebsiteJob, il quale permette la creazione di un nuovo WebJob ed accetta in ingresso i seguenti parametri: Name, il nome del WebSite di riferimento JobName, il nome del WebJob JobType, la modalità di esecuzione del WebJob come descritto nel primo post relativo a questa serie JobFile, il percorso dell’archivio compresso contenente tutti i file necessari all’esecuzione del Job Remove-AzureWebsiteJob, il quale rimuove il WebJob specificato ed necessita dei parametri: Name, JobName e JobType Per eseguire “Start&Stop” del WebJob, possiamo utilizzare i comandi: Start-AzureWebsiteJob, con parametri Name, JobName e JobType Stop-AzureWebsiteJob, con parametri Name e JobName Se i comandi sopracitati non dovessero essere presenti nel tool (I WebJob sono in Preview) è sufficiente aggiornare la documentazione della guida:

Windows Azure WebJobs (parte 2)

Pietro Libro — Thu, 06 Feb 2014 12:22:00 GMT

Nella prima parte abbiamo visto come creare un’applicazione console ed utilizzarla per elaborare (ridimensionare) in modalità Continuously dei Blob contenenti immagini, caricati in un particolare container del nostro storage. L’applicazione non è stata fisicamente copiata su un Web Site di Azure, ma è stata eseguita “in locale” sfruttando gli endpoint allo storage. Per caricare il nostro processo su Web Site i passi da compiere sono pochi e semplici: Accedere al portale di Windows Azure (https://manage.windowsazure.com) Se non presente, creare un nuovo Web Site: Aprire il Web Site e visualizzare la sezione “Configure”: Nella sottosezione “connection strings”, aggiungiamo la stringa di connessione “AzureJobsRuntime”: Visualizziamo la sezione “WebJobs”: Prima di effettuare l’upload dell’eseguibile è necessario creare una cartella compressa contenente sia “.exe” che “.dll” necessari al corretto funzionamento dell’applicazione. E’ sufficiente creare un archivio “zip” partendo (ad esempio) dalla cartella Debug\Release del nostro progetto. A questo punto è sufficiente cliccare sul bottone “ADD”, assegnare un nome al nostro “WebJob”, specificare il percorso della cartella compressa ed infine la modalità di esecuzione: Una volta caricato il file compresso, dovremmo avere una situazione simile alla seguente: Il Job caricato è in stato “STOP”, per entrare in “RUNNING” è ncessario cliccare l’icona con la dicitura “START” in fondo alla pagina: Per testare che tutto funzioni correttamente è sufficiente utilizzare il tool Azure Storage Explorer come visto nella prima parte. Se avessimo optato per un’esecuzione On Demand del Job ci saremmo trovati in una situazione di questo tipo: Dove per eseguire il processo si rende necessario cliccare l’icona con la dicitura “RUN ONCE”. Se si vuole invece provare la versione Scheduled è necessario attivare il servizio “Windows Azure Scheduler” tra quelli presenti in questa pagina: https://account.windowsazure.com/PreviewFeatures

Windows Azure WebJobs (parte 1)

Pietro Libro — Wed, 05 Feb 2014 18:32:00 GMT

Windows Azure mi appassiona veramente tanto e le nuove funzionalità rilasciate (seppur in alpha) aumentano ancora di piu’ la voglia e volontà di adottare questa piattaforma. E’ il caso dei WebJobs, un nuovo SDK in versione alpha che permette di eseguire programmi e script ospitati nei Web Site di Windows Azure, “semplicemente” tramite upload di un file (ad esempio “.exe” o “.cmd” ) dato che tutto il “difficile” è onere del “WebJobs SDK”. Questa nuova feature permette di eseguire dei veri e propri batch, processi che normalmente impiegherebbero molto tempo per essere eseguiti, come ad esempio la riorganizzazione di file, invio di email, processamento di immagini o code (Queue). Un batch puo’ essere eseguito in tre modalità differenti: On-Demand (a richiesta) Continuously, il processo in background è sempre attivo “in attesa di fare qualcosa”, il Trigger per attivare il processo puo’ essere ad esempio la ricezione di un messaggio in una specifica coda oppure la creazione di un nuovo Blob Scheduled, vogliamo che il nostro processo esegua del lavoro ad una certa ora di uno o piu’ giorni della settimana (in modalità singola o ricorrente) Un piccolo scenario d’esempio: un task (sempre attivo) che triggerato al caricamento di un Blob (un file immagine) in uno specifico container (“inputcontainer”), lo elabora (ridimensiona l’immagine e ne cambia formato in “png”) e salva il Blob risultato in un altro container (“outputcontainer”). Per iniziare è sufficiente creare una nuova applicazione console C# ed aggiungere i package necessari traminte NuGet: PM> Install-Package Microsoft.WindowsAzure.Jobs.Host –pre In Program.cs scriviamo il codice seguente: static void Main(string[] args) { JobHost host = new JobHost(); host.RunAndBlock(); } public static void ProcessJob([BlobInput(@"inputcontainer/{name}")] Stream inputStream, [BlobOutput(@"outputcontainer/{name}")] Stream outputStream) { using (Bitmap inputImage = new Bitmap(inputStream)) { Image outputImage = new Bitmap(200, 200); using (Graphics g = Graphics.FromImage(outputImage)) { g.InterpolationMode = InterpolationMode.HighQualityBicubic; g.CompositingMode = CompositingMode.SourceCopy; g.PixelOffsetMode = PixelOffsetMode.HighQuality; using (ImageAttributes imageAttributes = new ImageAttributes()) { Rectangle destRect = new Rectangle(0, 0, 200, 200); g.DrawImage(inputImage, destRect, 0, 0, inputImage.Width, inputImage.Height, GraphicsUnit.Pixel, imageAttributes); } } System.Drawing.Imaging.ImageFormat pngFormat = new System.Drawing.Imaging.ImageFormat(ImageFormat.Png.Guid); outputImage.Save(outputStream, pngFormat); } } E’ abbastanza intuitivo che il “lavoro sporco” del Task è eseguito dal codice presente in ProcessJob, il quale verrà attivato (BlobInput) ogni volta che un nuovo Blob verrà caricato in “inputcontainer”. L’output è definito dall’attributo BlobOutput, nello specifico la creazione di un nuovo Blob (immagine 200x200) nel container “outputcontainer”. Il codice di ridimensionamento è out of scope. Il nome del Blob in ingresso sarà uguale a quello di uscita in base al pattern specificato dal token “{name}”. Chi si occupa di gestire i Bindings, di rimanere in “ascolto” e dei Trigger è la classe JobHost che puo’ essere inizializzata come specificato nel Main. In questo caso si suppone che l’App.config contenga le definizione delle due ConnectionStrings necessarie rispettivamente per lavorare con lo Storage di Azure (“AzureJobsData”) e con le attività di logging (“AzureJobsRuntime”): <connectionStrings> <add name="AzureJobsRuntime" connectionString="DefaultEndpointsProtocol=https;AccountName=ACCOUNT_NAME;AccountKey=ACCOUNT_KEY"/> <add name="AzureJobsData" connectionString="DefaultEndpointsProtocol=https;AccountName=ACCOUNT_NAME;AccountKey=ACCOUNT_KEY"/> </connectionStrings> Altrimenti è necessario specificare il nome delle due stringhe di connessione tramite costruttore della classe JobHost. Le due connessioni possono coincidere ed ovviamente per eseguire l’esempio è necessario modificarle secondo il proprio account, sostituendo i valori di ACCOUNT_NAME e ACCOUNT_KEY. Il metodo “RunAndBlock()” esegue il Task nello stesso Thread attivo, mentre per utilizzare un Background Thread è necessario invocare il metodo “RunOnBackgroundThread()” (che ritorna immediatamente il controllo al chiamante). Per testare il tutto possiamo premere F5 e dopo qualche secondo, se tutte le configurazioni sono corrette, dovremmo ottenere una console simile alla seguente: Questo implica che il nostro Job è in attesa di “fare qualcosa”. Per lavorare con lo storage di Windows Azure possiamo scaricare il Tool “Azure Storage Explorer”. Una volta installato e configurato è possibile esplorare e modificare il nostro storage, nel mo caso, inizailmente abbiamo una situazione simile alla seguente: Dopo aver selezionato la voce “inputcontainer” nella lista “Container”, scegliamo la voce “New” nella lista dei comandi “Blob”, specifichiamo il nome del nuovo Blob e premiamo “Create Blob”: Dalla lista dei Blob presenti selezioniamo quello appena creato e scegliamo la voce “View” per visualizzarne i dettagli: Click su “Upload Image File” per caricare una nuova immagine ed attendere il completamento delle operazioni di upload. Rieseguendo la nostra applicazione, dopo qualche secondo, dovremmo ottenere una console di questo tipo: A questo punto ”outputcontainer” dovrebbe contenere un Blob con lo stesso nome di quello di input e contenente un immagine di dimensione 200x200px: Nella seconda parte del post vedremo come caricare l’eseguibile direttamente in un nostro Web Site ospitato su Windows Azure.

EF6 RTM Available

Pietro Libro — Thu, 17 Oct 2013 16:25:00 GMT

Con il rilascio di VS 2013, puntuale anche il rilascio in RTM di Entity Framework 6, tutti i dettagli direttamente sul blog di ADO.NET.

Disponibile EF 6 RC

Pietro Libro — Thu, 22 Aug 2013 09:25:00 GMT

Rilasciata la RC di Entity Framework 6, tutti i dettagli e le novità rispetto alla Beta 1, qui.

VS 2013 (Preview) : ASP.NET External Authentication

Pietro Libro — Wed, 07 Aug 2013 10:13:00 GMT

Tra le novità di Visual Studio 2013 ed ASP.NET 4.5.1 , troviamo nuove opzioni per integrare applicazioni SPA (Single Page Application) e Web API (ma non solo) con servizi di autenticazione esterni basati su Social come Twitter, Facebook, Google e Microsoft Accounts o basati su OAuth/OPenID (tutto a vantaggio di noi sviluppatori). Vediamo con un esempio. Apriamo VS 2013 (Preview) e selezioniamo come template “ASP.NET Web Application”: Scegliamo il progetto di tipo SPA che di base utilizza HTML5, CSS3 e ASP.NET Web API (una semplice applicazione “Todo List”): A questo punto il gioco è quasi finito, nella Solution Explorer apriamo il file App_Start\Startup.Auth.cs e decommentiamo la riga relativa “UseGoogleAuthentication”: Eseguiamo l’applicazione con F5, e dalla schermata principale possiamo scegliere se autenticarci in modalità classica oppure utilizzando un servizio di autenticazione esterno (nello specifico “Google”): Decommentando le opportune righe di codice è possibile offrire agli utenti piu’ servizi di autenticazione, ad esempio, per aggiungere anche “Microsoft Authentication” (è necessario possedere un account come developer qui : http://go.microsoft.com/fwlink/?LinkID=144070) modifichiamo il file di codice precedente aggiungendo “ClientId” and “Client Secret” come richiesto: Eseguiamo con F5, ed ecco il risultato: Semplice, no ? Tutti gli approfondimenti del caso, sul sito di ASP.NET: http://www.asp.net/web-api/overview/security/external-authentication-services