Upgrade progetto MVC4 a MVC5 in VS2012

Se avete un progetto ASP.NET MVC4 in VS2012 e, ingenuamente, credete che basti aggiornare i pacchetti nuget per passare alla nuova versione di MVC5 beh, siete leggermente fuori strada.

In primis occorre modificare opportunamente i web.config e il file csproj come spiegato in questo articolo:
http://www.asp.net/mvc/tutorials/mvc-5/how-to-upgrade-an-aspnet-mvc-4-and-web-api-project-to-aspnet-mvc-5-and-web-api-2

Dopo tali modifiche tuttavia vi renderete conto di non aver più intellisense nelle pagine razor.
Per riaverlo è necessario installare ASP.NET and Web Tools 2013.1 for Visual Studio 2012:
http://blogs.msdn.com/b/webdev/archive/2013/11/18/announcing-release-of-asp-net-and-web-tools-2013-1-for-visual-studio-2012.aspx

Oppure rimane valido il passaggio a VS2013 🙂

Buon ASP.NET MVC5 a tutti.

Pubblicità

Remove Magic strings with T4MVC [2]

Il mio precedente post mostrava come, tramite l’utilizzo di T4 e del package nuget T4MVC, fosse possibile eliminare senza problemi di performance (nessuna valutazione di expression tree o altro) le stringhe utilizzate per definire link a viste, route, link a file statici ecc ecc…
Come avevo accennato, il problema del refactoring dei metodi è “quasi” risolto. Spiego il “quasi”:
Il problema principale è che i file cshtml non vengono compilati. Non essendo compilati, non è possibile valutare la presenza di possibili errori. E poichè il refactoring non funziona in questi file, la compilazione non produce errori.

Per caso mi sono imbattuto in un post (non ricordo, sorry) che spiegava come forzare la compilazione dei file cshtml: Editare csproj e impostare <MvcBuildViews>true</MvcBuildViews>. In questo modo, ad ogni build, le viste vengono compilate mostrandone i problemi nella Error List View.
Tutto perfetto se non fosse che abilitare la compilazione delle viste comporti tempi di compilazione (decisamente) più lunghi.

Il compromesso tra impostare MvcBuildView e avere tempi di compilazione decenti è spiegato qui: http://www.luisrocha.net/2011/10/avoiding-mvcbuildviews-build-time.html
In pratica è possibile, tramite External Tools, effettuare una compilazione delle views solo su richiesta dello sviluppatore.

Bye bye magic strings.

Remove Magic strings with T4MVC

T4MVC è un progetto opensource sviluppato da @davidebbo ospitato su codeplex, precedentemente parte di MvcContrib, ora standalone.
Cosa pemette di fare? rimuovere, grazie ad un template T4, l’uso delle “stringhe” da un progetto MVC (riferimenti a controller, action, le area, i file statici …), il tutto con una curva di apprendimento minima (anzi, direi che non vi è curva di apprendimento e che i vari extension method di HtmlHelper sono più “complicati” da scrivere e da leggere).
Alcuni esempi di utilizzo:

• return RedirectToAction(“Index”);
  returnMVC.People.Index();
• @Html.ActionLink(“Edit”, “Edit”, new { id=Model.Id })
  @Html.ActionLink(“Edit”, MVC.People.Edit(Model.Id))
• @using (Html.BeginForm(“Create”, “People”))
  @using(Html.BeginForm(MVC.People.Create()))
• href=“@Url.Content(“~/Content/Site.css“)”
  href=“@Links.Content.Site_css”
• @Html.Partial(“_LogOnPartial”)
  @Html.Partial(MVC.Shared.Views._LogOnPartial)

In package nuget contiene due template T4:

• T4MVC.tt: il template che si occupa di generare classi e metodi da utilizzare degli esempi sopra elencati. In particolare si occupa di creare
  • classi T4MVC_*Name*Controller che ereditano *Name*Controller ed ne effettuano l’ovverride dei metodi. In questo modo il refactoring dei metodi è immediato (ovviamente una build è necessaria)
  • Classi partial *Name*Controller che aggiungono alcune shortcuts direttamente ai nostri controller.
  • Una classe statica MVC che raccoglie istanze statiche di classi T4MVC_*Name*Controller
  • Classi statiche Scripts e Contents che raccolgono i link alle varie risorse statiche
• T4MVC.tt.settings.t4: raccoglie le convenzioni utilizzate dal precedente template, tra le quali:
  • string HelpersPrefix=”MVC”: l’entry point per lo sviluppatore
  • string ControllersFolder e ViewsRootFolder: i nomi delle cartelle dove risiedono i controller e le view
  • string[] StaticFilesFolders: una lista di cartelle contenenti file statici dai quali T4MVC.tt genererà i riferimenti

T4MVC permette quindi di eliminare le stringhe, facilitare la scrittura e lettura di codice e rifattorizzare lo stesso (anche se alcuni problemi persistono, soprattutto nei cshtml). Buon coding.

ASP.NET MVC4 [RC] – Bundles

Dalla beta di asp.net mvc4 sono stati fatti passi avanti nelle API riguardanti i Bundle.

Giusto per informazione, i bundle sono presenti in ASP.NET MVC4 (assembly System.Web.Optimization.dll) e servono per riunire e minificare gruppi di risorse css e js. Questo permette di ridurre il payload e ridurre le connessioni HTTP. Ci sono molte librerie che svolgono lo stesso compito (es Combres, Cassette …), ma per i pigri (e chi non vuole troppe dipendenze al di fuori dallo stack ms) ora è tutto integrato.

Alcune novità rispetto alla beta:

• Rimozione del metodo “BundleTable.Bundles.RegisterTemplateBundles()”     Imho bene, tutto a favore di una registrazione manuale.dei bundle. Il template di asp.net mvc4 di default registra i js e css aggiunti automaticamente nel progetto.     E’ così possibile da un lato capire come vengono registrate le risorse dall’altro si possono aggiungere le proprie senza troppi problemi.     Rimane disponibile (giustamente) il metodo “BundleTable.Bundles.EnableDefaultBundles()” che raggruppa js e css in base alla struttura a folder della progetto.
• Dichiarazione nelle pagine dei bundle tramite @Script.Render(jspaths) e @Styles.Render(csspaths)     Eccellente. Rispetto a <link href=”@System.Web.Optimization.BundleTable.Bundle.ResolveBundleUrl(“~/Content/boot/css”)” rel=”stylesheet” type=”text/css” /> è una manna dal cielo. Questo infatti ci permette di avere:      – riduzione del codice scritto      – possibilità di renderizzare più tag script o link in modo di avere risorse non compresse per debug (ottimo!).
• (segue) Il rendering delle risorse è stabilito con due modalità:     1) Tramite Web.config verificando l’attributo debug=true (del tag compilation). Da osservare come questo venga rimosso in fase di publishing tramite web.config transformation (quindi in release le risorse vengono compattate e minificate automaticamente) mentre in fase di sviluppo questo è impostato di default a true e le ottimizzazioni non sono applicate.     2) Tramite chiamata al metodo BundleTable.EnableOptimizatoins=true/false.     In ogni caso, imho, l’impostazione di default è ottima.

Grazie agli ultimi due punti, la libreria optimization è finalmente utilizzabile in modo proficuo. Benone.