Part de l'initiative ASP.NET vNext, ASP.NET MVC 6 représente un changement fondamental pour Microsoft dans sa façon de construire et de déployer ses frameworks Web. L'objectif est de créer un framework agnostique de l'hôte qui élimine les dépendances avec l'infrastructure historique System.Web.
Microsoft ressent le besoin de supprimer System.Web car celui-ci représente un coût relativement important. Un graphe d'objet HttpContext classique peut consommer jusqu'à 30K de mémoire par requête et lorsque l'on se contente de travailler avec des petites requêtes, à base de JSON par exemple, ceci représente un coût disproportionné. Avec la nouvelle conception d'MVC 5, le surcoût à la requête descend à près de 2K.
MVC 6 inclut Web API et Web Pages, ce qui permet à Microsoft de supprimer une bonne part du chevauchement entre les trois frameworks. Résultat de ces modifications, MVC sera auto-hébergé, au même titre que Web API 2 et SignalR 2.
Afin de rendre les déploiements plus faciles et plus fiables, "vNext supportera un vrai déploiement side-by-side". Plutôt que de s'installer dans le GAC, chaque librairie MVC nécessaire à un site donné sera référencée comme une DLL classique, comme celles créées par les développeurs. "Ceci signifie que vous pouvez mettre à jour votre application sans affecter d'autres applications sur le même serveur".
Payez pour ce que vous utilisez
MVC 6 est construit sur une philosophie "payez pour ce que vous utilisez", "pay as you go". Chaque fonctionnalité que vous souhaitez utiliser doit explicitement être activée dans la routine de démarrage de l'application. Même le fait de servir des fichiers statiques requiert un appel à IBuilder.UseStaticFiles. Ceci fonctionne de la façon suivante : chaque site Web doit avoir une classe nommée Startup avec une méthode "void Configure(IBuilder app)". À l'intérieur de cette méthode, vous pouvez appeler des fonctions comme "app.UseServices" pour activer des fonctionnalités telles qu'MVC. Le routing est défini dans la méthode Configuration. Les routes MVC 6 sont similaires (pas identiques) aux routes MVC 5. Par exemple, un point d'interrogation peut être ajouté à un fragment pour le rendre optionnel. Avec MVC 5, il était nécessaire d'utiliser la valeur UrlParameter.Optional pour obtenir le même résultat.
Déploiements Azure et PowerShell
Microsoft pousse toujours Azure comme standard de déploiement des sites Web. Mais Microsoft a réalisé que les développeurs peuvent être réticents à publier directement depuis Visual Studio. À la place et par défaut, donc, des scripts de déploiement PowerShell sont générés. Ces scripts peuvent être édités dans Visual Studio, qui est maintenant équipé de l'outillage de base pour supporter PowerShell.
Le processus de Build ne construit pas
Avec ASP.NET vNext, le processus de Build ne construit rien du tout, en réalité. Aucun binaire n'est généré. Il exécute simplement la vérification de type pour s'assurer qu'il n'y a pas d'erreur ou de warning à traiter. À la place, le code est compilé à la volée, au besoin, à la manière d'ASP.NET Web Pages. Ceci permet des itérations plus rapides, en particulier sur les sites de taille importante. Si vous avez besoin que des binaires soient déployés sur un serveur, il vous faudra exécuter la commande package and publish. Ceci offrira plusieurs options, allant du code source uniquement, qui continuera à se compiler à la volée, jusqu'à des versions compilées natives. Cette dernière donnera très probablement de meilleures performances mais nécessitera un processus de Build plus long.
De nombreuses API déplacées ou supprimées
Comme mentionné plus haut, la taille d'HttpContext sera réduite de 30K par requête à quelques 2K par requête. Le prix à payer pour cela est un ensemble de méthodes disponibles réduit de façon significative sur cet objet et ses enfants. D'ici à ce que tout soit finalisé, il y aura probablement d'autres coupes dans les API. Afin de rendre cette transition moins fastidieuse, il est prévu de développer un outil similaire à FxCop qui détectera les appels aux anciennes API. Même si celui-ci ne sera pas capable de réécrire votre code automatiquement, l'outil pourra au moins indiquer quels changements sont nécessaires avant migration vers ASP.NET vNext et MVC 6. Parfois, ce changement impliquera uniquement l'appel d'une méthode différente, depuis un package ou une librairie optionnelle. D'autres fois, le code devra être revu de façon significative. Le produit étant encore en version alpha, la liste complète des changements n'est pas disponible actuellement.
Framework complet vs Framework optimisé pour le Cloud
Les avertissements ci-dessus sont à prendre en compte à cause de la suppression de System.Web. À côté de cela, vous pouvez rester sur le Framework .NET complet. Si vous souhaitez franchir l'étape suivante vers ce qu'on appelle le Cloud Optimized Framework, alors vous perdrez l'accès à encore d'autres API. Lors de la session de Q&A sur Channel 9, System.Drawing a été donné comme exemple de ce que vous ne pourrez plus utiliser. L'avantage d'utiliser le Cloud Optimized Framework est que vous pouvez inclure une copy du Core CLR (ou Mono) dans votre projet. Vous n'avez plus à mettre à jour .NET sur toute la machine pour les seuls besoins d'un unique site Web. Vous pouvez même avoir plusieurs versions de la CLR exécutées côte à côte, pour différents sites.
Le Core CLR est aussi censé faire l'objet d'un réglage "hautement optimisé pour l'efficience des resources". Ce que cela signifie exactement n'a pas encore été révélé.
Librairies vs Packages
Avec le modèle .NET vNext, les projets ne référencent plus les librairies de façon individuelle. À la place, ce sont des Packages NuGet qui se retrouvent référencés. Comme vous devez le savoir, les packages peuvent contenir plusieurs versions d'une librairie, divisées par plate-forme cible. ASP.NET vNext peut mettre cela à profit pour décider à runtime s'il faut charger la version Full .NET, Mono ou Core CLR d'une librairie donnée.
Si cela ne vous semble pas convenable, vous avez toujours la possibilité d'utiliser les Portable Class Librairies. Bien que tout ne soit pas encore prêt, il est prévu de créer un profil PCL pour le Cloud Optimized Framework.
Support de Mono
Dans le passé, le discours au sujet de Mono était essentiellement "nous espérons que ça fonctionne, si ça n'est pas le cas, voyez avec Xamarin". À présent, Microsoft annonce Mono comme étant l'officielle cross-platform CLR pour ASP.NET vNext. À cet effet, Microsoft travaille activement avec les équipes Mono pour s'assurer qu'elles ont tout ce dont elles ont besoin et incluront Mono dans leurs tests d'intégration continue.
Ceci dit, Microsoft n'offre pas de support officiel pour Mono via leurs canaux de support payant. Ils se contentent de promettre de maintenir la compatibilité et, si un test d'intégration continue échoue, qu'ils travailleront avec les équipes Mono pour le réparer.
Développement Cross-Platform
Microsoft prévoit non seulement un déploiement cross-platform mais aussi un développement cross-platform. Des fichiers batch pour toutes les plate-formes majeures comme OS X et Linux seront fournis afin de permettre de packager et de déployer les projets ASP.NET vNext sans avoir besoin de Windows et de Visual Studio.
Les modules KPM, "Katana Packages Modules", inspirés des modules node.js, les Node Packaged Modules, sont inclus également. Katana a été un projet de recherche visant à modulariser ASP.NET MVC pour son utilisation sur Owin. KPM s'appuiera sur les repositories NuGet.
Essayer ASP.NET vNext
La version en preview des binaires ASP.NET vNext sont d'ores et déjà disponibles. Le support Visual Studio est attendu d'ici les trois ou quatre semaines à venir.