Téléchargé 49 fois
Téléchargé parMicrosoft
Introduction à ASP.NET Core
Le document présente une introduction à ASP.NET Core, mettant en avant son caractère open source, modulaire et performant. Il compare les performances d'ASP.NET Core avec d'autres frameworks et décrit la feuille de route pour les mises à jour et les fonctionnalités à venir. Des démonstrations et des informations sur les contributions à la communauté OSS sont également mentionnées.
Contenu connexe
![02 - [ASP.NET Core] ASP.NET Core MVC](https://cdn.slidesharecdn.com/ss_thumbnails/02-asp-170124120155-thumbnail.jpg?width=640&height=640&fit=bounds)
![04 - [ASP.NET Core] Entity Framework Core](https://cdn.slidesharecdn.com/ss_thumbnails/04-efcore-170124115631-thumbnail.jpg?width=640&height=640&fit=bounds)
![01 - [ASP.NET Core] Plénière](https://cdn.slidesharecdn.com/ss_thumbnails/01-plnire-170124120818-thumbnail.jpg?width=640&height=640&fit=bounds)
![03 - [ASP.NET Core] Services RESTful et SPA](https://cdn.slidesharecdn.com/ss_thumbnails/03restfuletjavascriptservices-170124115925-thumbnail.jpg?width=640&height=640&fit=bounds)
![5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux](https://cdn.slidesharecdn.com/ss_thumbnails/05-devops-170124114304-thumbnail.jpg?width=640&height=640&fit=bounds)
![[XamarinDay] Développez de manière 100% native avec Xamarin](https://cdn.slidesharecdn.com/ss_thumbnails/xamarinnatif-160916155735-thumbnail.jpg?width=640&height=640&fit=bounds)
Introduction à ASP.NET Core
- 1.
- 2. ² Introduction à ASP.NETCore 1.0 Julien Corioland Evangéliste Technique Microsoft France @jcorioland Benjamin Talmard CTO in residence Microsoft Accelerator Paris @benjiiim
- 3.
- 4. Les principes d’ASP.NETCore N° 4 Indépendant de l’éditeur Open Source avec contributions Cross-Platform Cloud-ready Productivité pour les développeurs Totalement modulaire Performant OSS
- 5.
- 6.
- 7.
- 8. Performance .NET Core: >8xfaster than Node.js N° 8 5.2 2.4 1.8 0.6 0 1 2 3 4 5 6 .NET Core Java servlet Go Node.js Requestssec(millions) https://github.com/aspnet/benchmarks
- 9.
- 10. ASP.NET MVC Les Frameworksapplicatifs avant N° 10
- 11. ASP.NET MVC Les Frameworksapplicatifs maintenant N° 11
- 12.
- 13. ASP.NET Core Roadmap N° 13 EchéanceFonctionnalités 27 Juin 2016 Cross-Plat, dotnet, .NET Core, tooling preview, … 13 Septembre 2016 Mises à jour mineures T4 2016 / T1 2017 Nouveau middleware, Meilleure intégration Azure, … .NET Core Tooling update T1 2017 / T2 2017 WebSockets, SignalR, View Pages, … .NET Standard 2.0 https://github.com/aspnet/Home/wiki/Roadmap
- 14. ASP.NET Core Unification dumodèle de projet N° 14
- 15.
- 16.
- 17. @microsoftfrance @Technet_France @msdev_fr @jcorioland| @benjiiim N° 17
- 18. Notez cette session Ettentez 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
- #4 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.
- #5 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.
- #6 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.
- #7 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.
- #8 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.
- #9 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.
- #10 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
- #11 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
- #12 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.
- #13 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
- #14 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.
- #15 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
- #16 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 !