"ASP.NET Core est le nouveau framework Open Source et Cross Platform pour développer des applications connectées modernes : applications webs, backends mobiles ou applications IoT.
ASP.NET Core peut tourner sur .NET Core ou sur le .NET Framework complet. Son architecture a été complètement revue depuis la précédente génération du framework afin de fournir une expérience de développement plus moderne, plus flexible et plus performante.
Venez découvrir les bases d'ASP.NET Core afin de pouvoir l'envisager dans vos futurs projets !"
2. ²
Introduction à ASP.NET Core 1.0
Julien Corioland
Evangéliste Technique
Microsoft France
@jcorioland
Benjamin Talmard
CTO in residence
Microsoft Accelerator Paris
@benjiiim
4. Les principes d’ASP.NET Core
N° 4
Indépendant de l’éditeur
Open Source
avec contributions Cross-Platform
Cloud-ready
Productivité pour
les développeurs
Totalement modulaire
Performant
OSS
18. Notez cette session
Et tentez de gagner un Surface Book
Doublez votre chance en répondant aussi
au questionnaire de satisfaction globale
* Le règlement est disponible sur demande au commissariat général de l’exposition. Image non-contractuelle
Notes de l'éditeur
Benjat
Certain d’entre vous étaient peut-être développeurs web en 1996, à la sortie de ce qu’on appelle maintenant : classic ASP.
Cela fait maintenant 20 ans, et de l’eau à coulé sous les ponts.
Pourtant, certains concepts qui ont dictés des points d’architecture du framework ASP.NET 4.6 datent de cette époque.
Plus récemment mais il y a plus de 15 ans, lors de la sortie de .NET, des décisions d’architecture ont été prises et étaient dictées par le besoin d’attirer les développeurs Windows VB habitués à la programmation évènementielle.
C’est de cette époque que date les WebForms et la dll System.Web centrale à ASP.NET.
En 2015, il était temps de remettre en cause un certain nombre de ces choix, et de faire table rase du passé.
L’équipe a donc pris une feuille blanche et a commencé par énoncer un certain nombre de principes.
Julco
Enoncer les principes 1 par 1 avec 1 ou 2 exemples.
Totalement modulaire
Le premier principe était de construire un nouveau Framework qui soit totalement modulaire et composable, une sorte “d’anti System.web” pour permettre de ne charger dans son application ASP.NET Core que les dépendences qui sont vraiment necessaires.
Cloud Ready
L’idée c’est d’avoir un Framework qui soit pensé pour le Cloud : par exemple, de base en Asp.Net core, les applications sont state-less et la gestion de session ne se fait pas in proc.
Il est possible de faire tourner différentes version d’Asp.Net core dans un environnement mutualisé sans souci, en embarquant le runtime avec l’applicatif
Productivité pour les développeurs
Basé sur la puissance de .NET/C# sans les contraintes de plateforme, puisque basé sur .NET Core ou encore l’intégration avec des outils communs dans le monde du web comme Bower & NPM, pour la partie cliente
Indépendant de l’éditeur
Bien sûr, Visual Studio reste l’outil par excellence pour travailler en ASP.NET Core 1.0, mais l’architecture de ce nouveau Framework fait que l’on peut l’utiliser avec n’importe quel éditeur de texte – simple comme notepad ou plus avancé comme Visual Studio Code et Sublime text, et gérer tous les aspects liés à la compilation et au run en ligne de command avec l’executable “dotnet”
Cross Platform
Du point de vue du développeur, on peut faire de l’ASP.NET Core 1.0 sur Windows, Mac OS et Linux
Du point de vue du hosteur, on peut choisir Windows + IIS ou Linux + Nginx par exemple
Julco repasse la parole à Benjat pour OSS & Perf
Normalement, on devrait pouvoir vous démontrer au moins 5 de ces principes via nos démonstrations, mais pour les apsects OSS et Performance, prenons quelques minutes.
Benjat
Concernant l’aspect Open Source, cela se passe sur github, dans le repository aspnet.
Et quand on parle d’Open Source, on parle vraiment d’Open Source, avec le code disponible bien sûr, comme c’était déjà le cas sur une grosse partie de .NET, mais avec la capacité de contribuer également.
C’est vrai pour le code, mais c’est aussi vrai pour les issues et leur résolution (un architecte ou un développeur de l’équipe va pouvoir communiquer directement sur l’issue, ce qui change de l’époque de Connect…) ou encore pour la documentation, elle aussi gérée en Open Source.
Benjat
C’est quelque chose qui se passe de plus en plus chez Microsoft, qui a véritablement changé ces dernières années sur cet aspect.Les chiffres suivants, qui proviennent directement de GitHub montrent le nombre de contributeurs dans différentes organisations, et vous pouvez constater que Microsoft est en tête.
Cela représente les employés de Microsoft, mais également les personnes externes qui ont contribuées, comme certains d’entre vous peut-être dans la salle.
Benjat
Et sur les representations suivantes, on a les emplacements de chaque contributeur externes à Microsoft sur le repository GitHub .NET.
On est donc sur un projet global également d’un point de vue géographique, et pas sur le jouet d’une petite équipe à Redmond.
D’ailleurs, on a encore queqlues espaces vide en France, contrairement à l’Angleterre ou à l’Allemagne. Donc n’hésitez pas à contribuer également. :-)
L’un de ces contributeurs est Ben Adams, le CTO d’Illyriad games, le créateur d’Age of Ascent, un jeu online dont le backend sur Azure est écrit en .NET
Pour lui, chaque ms gagnée est essentielle pour gérer les centaines de millions de messages par jour nécessaire pour gérer des milliers de joueurs en simultané.
Il a donc commencé à travailler avec l’équipe sur ces aspects performances.
Benjat
Et c’est notamment grâce à son travail que les benchmarks montrent dans certains cas des performances 8 fois supérieures à Node.js.
Quand on sait qu’un certain nombre de développeurs web se sont tournés ces dernières années vers Node.js pour des raisons de performances, c’est encourageant pour le futur d’ASP.NET
Et le mode opératoire pour ces tests est lui aussi Open Source. N’hésitez pas à jeter un œil sur le repository correspondant.
From zero to hello
Benjat sur Windows pour créer le projet
Dans cette première démo, utilisation de la ligne de commande pour pouvoir vous expliquer certains principes qui vous sont masqués quand vous utiliser Visual Studio.
Et en .NET Core, il y a un nouvel outil très important, cross-platform, qui s’appelle tout simplement dotnet. Regardons sa page d’aide pour voir tout ce qu’il sait faire.
dotnet help
dotnet new => dotnet restore => dotnet build : il ne faut pas s’attendre à générer un .exe ici. Finit le monde Windows only avec le mécanisme qui savait détecter qu’un .exe devait lancer la CLR .NET puis votre code. Il est nécessaire de passer par un mécanisme indépendant pour lancer .NET et charger votre code, et cela passe par l’outil dotnet.
dotnet run => Hello World : exécution du projet .NET Core le plus simple possible
Il est maintenant temps de collaborer avec Julien qui va passer ce projet dans le monde ASP.NET
git init
yo aspnet:gitignore =>génération d’un fichier .gitignore pour ne garder que le code dans le repository
git add .
git commit -a -m “initial"
Création d’un projet dans GitHub
git remote add origin https://github.com/Benjiiim/testxp.git
git push origin master
Julco sur Mac
Je vais maintenant pouvoir récupérer le travail de Benjamin sur mon Mac et travailler avec Visual Studio Code
git clone URL_REPO experiences
cd experiences
code .
Accepter d’ajouter le debug & restore nuget
Pour le moment on est sur une application console .NET Core, mais c’est très simple de rajouter la couche http / asp.net core. Il faut d’abord modifier le project.json
Microsoft.AspNetCore.Server.Kestrel | 1.0.1
Accepter le restore de package
Puis, éditer le fichier Program.cs pour ajouter le web host (les applications aspnet core sont toujours self hostée) et l’utilisation de Kestrel
using Microsoft.AspNetCore.Hosting
var host = new WebHostBuilder()
.UseKestrel()
.UseStartup<Startup>()
.Build();
host.Run();
Enfin, on ajoute le Startup.cs qui défini le point de configuration d’ASP.NET Core et notamment comment gérer les requêtes http, ici on fait un hello world dans tous les cas
using System;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;
namespace ConsoleApplication
{
public class Startup
{
public void Configure(IApplicationBuilder app)
{
app.Run(context =>
{
return context.Response.WriteAsync("”);
});
}
}
}
Maintenant tout est ok / prêt pour exécuter notre première application Asp.Net Core avec VS Code.
On peut mettre un point d’arrêt dans le app.run et lancer le debug
Lancer Safari sur http://localhost:5000 et on vient bien qu’on a une stack http qui est en place
Commit dans GitHub depuis VS Code
Benjat sur Windows pour publish
Nous avons maintenant une application ASP.NET fonctionnelle, avec son propre serveur http pour traiter les requêtes.
L’étape d’après est la mise en production de l’application, et il est nécessaire pour cela de déployer son application derrière un serveur web complet. Sur Linux, on conseille l’utilisation de Nginx et sur Windows, il s’agit bien sûr d’IIS.
Mais le travail d’IIS est bien différent dans le cas d’ASP.NET Core par rapport à ASP.NET. Avec ASP.NET Core, IIS n’est utilisé que comme reverse proxy, pour rediriger les requêtes vers kestrel. Et pour cela, on utilise un module IIS que j’ai préalablement installé sur mon poste et qu’il est nécessaire d’installer sur les serveurs qui devront hoster du code ASP.Net Core.
Git pull origin master => récupérer le code de Julien
Ouverture via Visual Studio Code
Ajout du package Microsoft.AspNetCore.Server.IISIntegration
Pour travailler avec IIS, on a deux choses à faire dans son application. La première, c’est d’utiliser un middleware spécifique, qui permettra à ISS de transférer des éléments de contexte comme l’authentification Windows
.UseIISIntegration()
La deuxième chose, c’est d’utiliser un outil, disponible dans le même package, pour générer un fichier Web.Config lors de la publication de son application,
Je vais donc utiliser deux notions de .NET Core : la notion d’outil, pouvant être déclaré pour être utiliser avec dotnet, et la notion de script, dans notre cas un script de post-publish. Tout cela se passe aujourd’hui dans le projet.json
Donc à chaque publish, l’outil dotnet va appeler l’outil publish-iis pour créer ou modifer le Web.Config de mon projet
dotnet publish
Aller voir résultat dans le bon folder
Utiliser IIS Manager pour créer une nouvelle application.
Désactiver la CLR dans IIS.
Tester dans le browser
Julco
Avant :
Le principal souci rencontré avec ASP.NET MVC tel qu’on le connaissais avec ASP.NET Core est la division entre les Framework WebPages/MVC 5 et Web API 2, le second étant sur une stack identique mais complètement différente : du coup, compliqué de factoriser du code entre les deux, deux pipelines à gérer (System.web et OWIN) etc…
Et surtout très confusant, car modulo le namespace, les classes étaient les mêmes avec quelques subtilité.
On sentait bien une volonté d’unification, mais l’histoire d’ASP.NET fait que ce n’était pas totalement possible
Julco
Maintenant :
Avec ASP.NET Core & MVC Core : on a tout réecrit pour que ce soit un seul et même Framework unifié. On a plus qu’un seul pipeline ASP.NET MVC Core, des classes de bases communes pour les contrôleurs & actions résults, la possibilité d’avoir des filters, attributs, model binder commun, et surtout un seul dependency resolver pour gérer les dépendances.
Démo #1 : ASP.NET MVC / Web API unifié
Montrer le scenario en rappelant que cette fois on est dans Visual Studio qui reste le meilleur IDE pour développer en ASP.NET
Montrer qu’on retrouve une structure qui a un peu changé :
Les références qui sont branchées sur le project.json
Le dossier wwwroot
Les dependencies bower / npm
Et on retrouve bien le project.json, le Program.cs et le Startup.Cs
Montrer le Startup.cs en expliquant il n’y a plus qu’un seul et unique pipeline pour MVC & Web API
Montrer le AddMvc / UseMvc ainsi que l’enregistrement de ISpeakerService dans le dépendency resolver que l’on a pas à configurer comme c’était le cas avant et qui marche pour MVC & Web API
Présenter la structure du projet : j’ai un Models, une « fake » implémentation du service et ensuite deux contrôleurs, un MVC qui renvoie une vue Razor et un web API qui renvoie du JSON. Les deux injectent le service Speakers dans le ctor, depuis le dependency resolver.
Lancer l’appli, montrer la page Speakers et l’API speakers
Moralité :
Encore une fois on remarque bien qu’il y a eu des changements profonds au niveau des fondations ASP.NET Core et du Framework MVC par-dessus, mais on voit bien que pour un développeur qui fait du MVC depuis plusieurs années dans Visual Studio, on retrouve très facilement ses marques
Wrap up / Relance de Benjat pour introduire la démonstration
Démo #2 : ASP.NET Core MVC – Tag Helpers
Effectivement, une autre nouveauté très sympa sont les tags helper, pour regagner un peu de contrôle sur le HTML dans les vues razor et gagner du temps.
Explication rapide du scenario : vous avez déjà tous eu à gérer une page ou les champs doivent être en lecture seule en function d’une valeur d’un Boolean du modèle
Avant, on aurait fait quelque chose comme ça : et on montrer les if / else dégueu dans la page
Avec les tag helpers ça donne ça (waouhou la foule est en délire)
Je montre le code du tag helper pour montrer que c’est tout bête
Et là ou je fais le @addTagHelpers dans la page
Benjat
ASP.NET Core est donc en 1.0 depuis le 27 juin 2016 => support de Microsoft et passage en production tout à fait possible.
Une version mineure est sortie depuis il y a quelques semaines et les deux prochaines versions sont déjà annoncée, avec un certain nombre d’améliorations prévues.
La encore, tout est open source, avec la roadmap sur GitHub.
Benjat
Dans la roadmap, un point important a également été annoncé : l’utilisation à venir de MSBuild comme modèle de projet pour ASP.NET Core.
L’équipe ASP.NET Core a créé un nouveau modèle de projet, basé sur le fichier project.json que vous avez vu aujourd’hui, et a pu intégrer un certain nombre de fonctionnalités intéressantes.
Pour plus de cohérence entre les différents types de projet .NET et quelque soit les outils utilisés, l’équipe .NET souhaite revenir à un seul modèle de projet.
Plutôt que de passer au project.json pour tous les autres, de WPF à Xamarin en passant par UWP, il a donc été décidé de faire l’inverse et de remplacer project.json par MSBuild dans le futur.
L’équipe travaille sur cela en ce moment, en faisant le nécessaire pour trouver le bon équilibre entre l’héritage de MSBuild et les qualités de project.json
Il est important de comprendre qu’ASP.NET 4.6 (et ses prochaines versions) et ASP.NET Core sont sur deux branches différentes.
Ce n’est pas parcequ’ASP.NET Core est sorti que vos applications existantes ne sont plus supportés.ASP.NET 4.6 va continuer d’évoluer et à être supporté pendant longtemps. Donc pas d’inquiétude à ce niveau.
Par contre, pour vos nouveaux projets ou dans le cadre de réécritures d’applications existantes, on vous encourage à regarder si les avantages d’ASP.NET Core peuvent vous aider (cross-platform, performances, architecture plus moderne, …)
Si vous êtes comme Julien et moi, vous devriez rapidement être convaincus, mais il faudra accepter quelques changements et quelques contraintes.
Entre ces deux options, une troisième existe : l’utilisation d’ASP.NET Core au dessus du .NET Framework classique, qui vous apportera le nouveau modèle mais sans toutes les améliorations et tous les changements.
C’est donc à vous de jouer maintenant !