<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:copyright="http://blogs.law.harvard.edu/tech/rss" xmlns:image="http://purl.org/rss/1.0/modules/image/">
    <channel>
        <title>ASP.NET 5</title>
        <link>http://blogs.ugidotnet.org/PietroLibroBlog/category/ASP.NET 5.aspx</link>
        <description>ASP.NET 5</description>
        <language>it-IT</language>
        <copyright>Pietro Libro</copyright>
        <managingEditor>pietro.libro@libero.it</managingEditor>
        <generator>Subtext Version 2.6.0.0</generator>
        <item>
            <title>ASP.NET 5 e AzureTableStorage</title>
            <link>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/30/asp.net-5-e-azuretablestorage.aspx</link>
            <description>Riprendiamo l’esempio del post precedente per testare l’integrazione tra EF7 e lo storage di Azure. Apriamo NuGet ed installiamo il package “EntityFramework.AzureTableStorage” (sempre in beta):    Modifichiamo il codice della classe ItemDB in questo modo:      1     public class ItemDB : DbContext
 2     {
 3         public DbSet&amp;lt;Item&amp;gt; Items { get; set; }
 4 
 5         protected override void OnConfiguring(DbContextOptions options)
 6         {
 7             options.UseAzureTableStorage("[Storage_Name]", "[Secret_Key");
 8         }
 9 
10         protected override void OnModelCreating(ModelBuilder modelBuilder)
11         {
12             modelBuilder.Entity&amp;lt;Item&amp;gt;().ForAzureTableStorage()
13                 .PartitionAndRowKey(a =&amp;gt; a.CategoryId, a =&amp;gt; a.Id)
14                 .Table("Items");
15         }
16     }


Rispetto all’esempio precedente è stato rimosso il metodo di estensione UseSqlServer ed aggiunto un degli overload di UseAzureTableStorage che accetta in ingresso due parametri: accountName ed accountKey. Tramite l’override di OnModelCreating andiamo ad istruire il runtime sulle propietà della classe Item che rappresentato rispettivamente la PartitionKey e la RowKey del Table Storage su Azure. Modifichiamo il file Project.json commentando la voce aspnetcore50 nella sezione frameworks:



La classe Item modificata è la seguente:

1     public class Item
2     {
3         public int Id { get; set; }
4         public int CategoryId { get; set; }
5         public string Code { get; set; }
6         public string Description { get; set; }
7     }

Infine modifichiamo la classe Program.cs:






   1  public void Main(string[] args)
 2         {
 3             using (ItemDB db = new ItemDB())
 4             {
 5                 int nextId = new Random().Next(100000);
 6 
 7                 db.Items.Add(new Item()
 8                 {
 9                     Id = nextId,
10                     Code = "Item #" + nextId,
11                     Description = "Description #" + nextId
12                 });
13 
14                 db.SaveChanges();
15             }
16 
17             using (ItemDB db = new ItemDB())
18             {
19                 foreach (Item item in db.Items)
20                 {
21                     Console.WriteLine("Item Id: {0}, Code: {1}, Description : {2}",
22                         item.Id, item.Code, item.Description);
23                 }
24             }
25 
26             Console.ReadLine();
27         }


Proviamo quindi ad eseguire l’applicazione:



Ulteriore prova che tutto funzioni correttamente si puo’ avere utizzando l’”Azure Storage Explorer”:

&lt;img src="http://blogs.ugidotnet.org/PietroLibroBlog/aggbug/101909.aspx" width="1" height="1" /&gt;</description>
            <dc:creator>Pietro Libro</dc:creator>
            <guid>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/30/asp.net-5-e-azuretablestorage.aspx</guid>
            <pubDate>Sun, 30 Nov 2014 23:48:00 GMT</pubDate>
            <comments>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/30/asp.net-5-e-azuretablestorage.aspx#feedback</comments>
            <wfw:commentRss>http://blogs.ugidotnet.org/PietroLibroBlog/comments/commentRss/101909.aspx</wfw:commentRss>
            <trackback:ping>http://blogs.ugidotnet.org/PietroLibroBlog/services/trackbacks/101909.aspx</trackback:ping>
        </item>
        <item>
            <title>ASP.NET 5 e Entity Framework 7 (beta)</title>
            <link>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/30/asp.net-5-e-entity-framework-7-beta.aspx</link>
            <description>Vediamo in questo post come iniziare a giocare con Entity Framework 7 “beta” (in “beta” solo per uniformità con in rilascio della preview di VS 2015, cosi come descritto in questo post). Partiamo con aprire VS 2015 e creare un progetto di tipo “ASP.NET 5 Console Application”:    Per utilizzare Entity Framework 7, apriamo il file Project.json e aggiungiamo nella sezione dependencies le tre dipendenze seguenti:     "EntityFramework": "7.0.0-beta1"    "EntityFramework.Commands" : "7.0.0-beta1"    "EntityFramework.SqlServer": "7.0.0-beta1"   Le dipendenze 1 e 3 ci servono per integrare EF nel nostro progetto ed “informare” che andremo a lavorare utilizzando EF per SQL Server (dato che nella nuova versione, il provider di EF puo’ essere utilzzato nativamente per interagire con SqlServer, SqlLite, AzureTableStorage e InMemory, quindi non solo database relazionali), la dipendenza 3 ci serve per utilizzare i comandi di DB Migration all’interno del nostro progetto.  Sempre in Project.json aggiungiamo la sezione Commands con la relativa voce “EF”:  "commands": {       "ef": "EntityFramework.Commands"    },         Cosi’ che alla fine delle modifiche il file Project.json sia simile a quanto illustrato nella figura seguente:       Aggiungiamo al progetto un file di tipo “ASP.NET Configuration file” (Config.json):    Il quale di Default si presenta in questo modo:    Nella sezione “Data\DefaultConnection” modifichiamo la voce ConnectionString editando la propietà Database oppure cambiando l’intera stringa di connessione, secondo di dove vogliamo ospitare il nostro database (Istanza di SQL Server Express piuttosto che LocalDB ad esempio). Tramite “NuGet Package Manager” (molto piu’ carino graficamente di quello precedente), aggiungiamo un riferimento al Package “Microsoft.Framework.ConfigurationModel.Json” :    Aggiungiamo al progetto il file Startup.cs:    E modifichiamolo come segue:   1     public class Startup
 2     {
 3         public static Microsoft.Framework.ConfigurationModel.IConfiguration Configuration { get; set; }
 4 
 5         static Startup()
 6         {
 7             Configuration = new Microsoft.Framework.ConfigurationModel.Configuration()
 8              .AddJsonFile("config.json").AddEnvironmentVariables();
 9         }
10     }

Aggiungiamo al progetto due nuovi classi C#, “Item” e “ItemDB”, dove “ItemDB” è la classe derivata da System.Data.Entity.DbContext ed “Item” il Data Model:

 1     public class Item
 2     {
 3         public int Id { get; set; }
 4         public string Code { get; set; }
 5         public string Description { get; set; }
 6     }
 7 
 8     public class ItemDB : DbContext
 9     {
10         public DbSet&amp;lt;Item&amp;gt; Items { get; set; }
11 
12         protected override void OnConfiguring(DbContextOptions options)
13         {
14             options.UseSqlServer(Startup.Configuration.Get("Data:DefaultConnection:ConnectionString"));
15         }
16     }

Il nuovo metodo OnConfigure di cui abbiamo eseguito l’override ci permette di specificare quale Data Provider (nel nostro caso SqlServer) lavorerà con il nostro DbContext. UseSqlServer accetta come parametro  una stringa di connessione che recuperiamo dal file Config.json tramite la proprietà Configuration (Microsoft.Framework.ConfigurationModel.IConfiguration) presente nella classe Startup.cs.

Per utilizzare EF Migrations, non è ancora finita, in quanto è necessario installare e configurare KVM (K Version Manager), sul sito è presente una piccola guida all’installazione. 

Apriamo un’istanza di Windows PowerShell (o Command Prompt secondo le preferenze) e ci spostiamo nella directory del nostro progetto, dopo digitiamo il comando “K ef migration add initial”:



Se tutto è stato eseguito correttamente, nel nostro progetto viene aggiunta la classica cartella “Migrations” con tutti i file necessari:



Applichiamo quindi il nostro “piano di migrazione” tramite il comando “migration apply”:



Ora possiamo testare che tutto l’Ambaradan () funzioni, modificando la classe Programs.cs in questo modo:

 1  public void Main(string[] args)
 2         {
 3             ////Save data.
 4             using (ItemDB db = new ItemDB())
 5             {
 6                 db.Items.Add(new Item()
 7                 {
 8                     Code = "Item #1",
 9                     Description = "Description #1"
10                 });
11 
12                 db.SaveChanges();
13             }
14 
15             ////Load data.
16             using (ItemDB db = new ItemDB())
17             {
18                 foreach (Item item in db.Items)
19                 {
20                     Console.WriteLine("Item Id: {0}, Code: {1}, Description : {2}",
21                         item.Id, item.Code, item.Description);
22                 }
23             }
24 
25             Console.ReadLine();
26         }

E poi avviando il tutto con un bel F5:



Sicuramente la versione 7 di EF è ancora “poco” matura per essere utiizzata in progetti reali, ma questo esempio vuole essere un punto di partenza per scoprire quali novità ci attendono &lt;img src="http://blogs.ugidotnet.org/PietroLibroBlog/aggbug/101908.aspx" width="1" height="1" /&gt;</description>
            <dc:creator>Pietro Libro</dc:creator>
            <guid>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/30/asp.net-5-e-entity-framework-7-beta.aspx</guid>
            <pubDate>Sun, 30 Nov 2014 13:21:00 GMT</pubDate>
            <comments>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/30/asp.net-5-e-entity-framework-7-beta.aspx#feedback</comments>
            <wfw:commentRss>http://blogs.ugidotnet.org/PietroLibroBlog/comments/commentRss/101908.aspx</wfw:commentRss>
            <trackback:ping>http://blogs.ugidotnet.org/PietroLibroBlog/services/trackbacks/101908.aspx</trackback:ping>
        </item>
        <item>
            <title>Asp.Net 5, MVC 6 e Web Api</title>
            <link>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/23/asp.net-5-mvc-6-e-web-api.aspx</link>
            <description>E’ qualche mese che non scrivo nulla sul blog, ma gli studi, come la vita, sono andata avanti. Ora eccoci qui a fare qualche test con le nuove versioni delle ultime tecnologie\framework web del mondo Microsoft, che ci regala ogni giorno qualcosa di tecnlogicamente fantastico…alla faccia dei soliti criticoni . Torniamo con i piedi per terra e proviamo ad utilizzare le Web Api in un progetto MVC 6 (attualmente in versione beta, ASP.NET 5 fonde i framework MCV e Web Api). Apriamo il nostro VS 2015 preview (scaricabile nella versione ultimate a questo indirizzo: ) e creiamo un nuovo progetto “ASP.NET Web Application”:    Poi selezioniamo il template ASP.NET 5 Empty:    Attendiamo qualche secondo che Visual Studio crei l’alberatura della soluzione con tutti i relativi file:    Notiamo due file in formato “.json”, global.json e project.json, che possiamo editare rispettivamente per i settings e per le references a livello globale (solution) o di singolo progetto. La classe Startup.cs ed in particolare il metodo Configure(…) definisce l’entry point della pipeline di ASP.NET, ed è qui che andremo ad aggiungere il codice necessario all’esecuzione dell’applicazione. Prima, apriamo il file project.json, e nella sezione dependencies aggiungiamo la riga seguente:  "Microsoft.AspNet.Mvc": "6.0.0-beta1"

Notare come l’editor sia completo di IntelliSense che ci permette di scegliere dinamicamente package e versione (tra quelle disponibili):



Inizializziamo MVC nella classe Startup.cs, aggiungendo il metodo ConfigureServices:

1 public void ConfigureServices(IServiceCollection services) 
2 { 
3     services.AddMvc(); 
4 }

il quale aggiunge tutte le dipendenze di cui MVC 6 ha bisogno. Utilizziamo il metodo d’estensione UseMvc nel metodo Configure:

1 public void Configure(IApplicationBuilder app) 
2 {            
3     app.UseMvc(); 
4 } 

Aggiungiamo una classe ItemsController (“Web Api Controller Class”) nella classica cartella di progetto Controllers:



 1 [Route("api/[controller]")] 
 2 public class ItemsController : Controller 
 3 { 
 4     // GET: api/values 
 5     [HttpGet] 
 6     public IEnumerable&amp;lt;Item&amp;gt; Get() 
 7     { 
 8         return new List&amp;lt;Item&amp;gt;( 
 9             new Item[]{ 
10                 new Item() { Code= "Item#1", Description= "Item_Description#1" }, 
11                 new Item() { Code = "Item2", Description = "Item_Description#2"} }); 
12     } 
13 }

Poi aggiungiamo la classe Item:

1 public class Item 
2 { 
3     public string Code { get; set; } 
4     public string Description { get; set; } 
5 }

Avviamo il progetto ed invochiamo via browser il servizio:



Il servizio dovrebbe restituire il seguente json :

1 [{"Code":"Item#1","Description":"Item_Description#1"}
2 ,{"Code":"Item2","Description":"Item_Description#2"}]

Notiamo come la classe ItemsController a differenza delle versioni precedenti, non derivi piu’ dalla classe ApiController, ma direttamente da Controller. Se proviamo ad utilizzare uno strumento come Fiddler per analizzare le request e le response delle nostre Api, possiamo scoprire qualcosa di interessante, se ad esempio, modifichiamo la nostra Web Api in modo da tornare null, con l’attuale versione di ASP.NET Web Api otterremmo:



Ovvero una response con status 200 e corpo del messaggio vuoto, con la versione MVC 6 invece:



Una response con status 204 (No Content), che logicamente parlando IMHO è piu’ corretta (la risposta è OK, ma il contenuto del body è vuoto). Ulteriori dettagli sui Formatters in MVC6 possono essere trovati in questo post di Filip W. Per ritornare ad avere un comportamento Old Style è sufficiente agire a livello di configurazione, in ConfigureServices:

1 public void ConfigureServices(IServiceCollection services) 
2 { 
3     services.AddMvc().Configure&amp;lt;MvcOptions&amp;gt;(o =&amp;gt; o.OutputFormatters 
4     .RemoveAll(f =&amp;gt; f.Instance.GetType() == typeof(HttpNoContentOutputFormatter))); 
5 }

Ovviamente di novità ci sono e tante, ma almeno sappiamo da dove iniziare  .

  &lt;img src="http://blogs.ugidotnet.org/PietroLibroBlog/aggbug/101903.aspx" width="1" height="1" /&gt;</description>
            <dc:creator>Pietro Libro</dc:creator>
            <guid>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/23/asp.net-5-mvc-6-e-web-api.aspx</guid>
            <pubDate>Sun, 23 Nov 2014 10:17:55 GMT</pubDate>
            <comments>http://blogs.ugidotnet.org/PietroLibroBlog/archive/2014/11/23/asp.net-5-mvc-6-e-web-api.aspx#feedback</comments>
            <wfw:commentRss>http://blogs.ugidotnet.org/PietroLibroBlog/comments/commentRss/101903.aspx</wfw:commentRss>
            <trackback:ping>http://blogs.ugidotnet.org/PietroLibroBlog/services/trackbacks/101903.aspx</trackback:ping>
        </item>
    </channel>
</rss>