6. Changement de paradigme
ASP (1996) ASP.NET MVC (2009) ASP.NET Core (2017)
ASP.NET Webforms (2002) ASP.NET Web API et SignalR (2012)
IIS Extension .NET Framework + IIS .NET Core
(2007 – 2012)
7. One ASP.NET
ASP.NET
Sites Services
MVC Webpages Webforms SPAs Web API SignalR
http://www.hanselman.com/blog/OneASPNETMakingJSONWebAPIsWithASPNETMVC4BetaAndASPNETWebAPI.aspx
8. ASP.NET Core et ASP.NET 4.6
http://www.hanselman.com/blog/ASPNET5IsDeadIntroducingASPNETCore10AndNETCore10.aspx
9. Pas un simple changement de version
ASP.NET Core app
Upgrade
ASP.NET 4.6 app
Portage
14. Cell’Insights
• Distribué par Yasmine (sois polie, dis
bonjour, Yasmine)
• A télécharger :
http://www.cellenza.com/cellinsights/
15. Programme de la journée
Plénière : les
fondamendaux
.NET Core
• Nicholas Suter
(MVP)
• Clément Puëll
ASP.NET Core
MVC
• Georges Damien
(MVP)
• Emilien Bassez
• Jean Dumas De
Rauly
Retour
d’expérience à
la MAF
• Matthias
Grosperrin
• Mikaël Krief
(MVP)
• Georges Damien
(MVP)
ASP.NET Web
API et les SPA
• Rémy Royer
Entity
Framework
Core
• Nicholas Suter
(MVP)
ASP.Core et
DevOps
• Guillaume
Rouchon (MVP)
• Mikaël Krief
(MVP)
17. Petit historique
Début 2014
Project K
• .NET sous Unix
Mai 2014
ASP.NET vNext
• Cloud
• NuGet
• Mac et Linux
Novembre 2014
ASP.NET 5
• .NET Core 5
• GitHub CoreFX
2015
GitHub CoreCLR
Juin 2016
.NET Core 1.0
• ASP.NET Core 1.0
• EF Core 1.0
• .NET Standard
• CLI
21. La machine d’exécution
Garbage
Collector
JIT Compiler
Multithreading
Types de base
(Object, String)
Exceptions
Multi-plateforme
(Windows, Linux,
macOS)
Multi-architecture (x86,
x64, arm)
3 à 5 millions de lignes
de code
C / C++ / C#
CoreCLR
Microsoft.NETCore.Runtime.CoreCLR
22. La bibliothèque de classe
CoreFX
Types primitifs
Int32
String
Structures de
données
System.Collections
List
Dictionary
Classes
utilitaires
System.Net
HttpClient
System.IO
File
System.Collections System.ThreadingSystem.Linq
System.Net.Http System.Text.EncodingSystem.Xml.XDocument
System.IO System.ReflectionSystem.Globalization
25. Métapackage
Toutes les API
de CoreFX
CoreCLR
.NET Standard
+ Linq.Parallel,
Net.Security, …
Microsoft.NETCore.App
Toutes les API du
.NET Standard
Collections, IO, Linq,
XML, Tasks, …
NETStandard.Library
26. .NET Core : nouvelle stack
incompatible !
Recompiler pour chaque SDK ?
Depuis 2011 : Portable Class
Libraries
Problème…
27. Un standard pour les gouverner tous
netstandard
2.0
netstandard
1.6
netstandard
1.2
netstandard
1.0<TargetFramework>netstandard1.6</TargetFramework>
29. Choisir son framework cible
SDK et runtime Bibliothèque de classe
Packages NuGet Compatibilité
Target
Framework
• net45
• net461
• netcoreapp1.0
• netcoreapp1.1
• netstandard1.6
• netstandard2.0
Moniker
30. Tableau comparatif
net
Pour windows
Accès à toute la bibliothèque historique
Peut référencer n’importe quelle librairies tierces
Dépendance à Windows et à .NET
netcoreapp
Pour la portabilité
Multi-plateforme
Plus de package que netstandard
Compatibilité moyenne
netstandard
Pour les bibliothèques
Référençable par tout type de projet
Moins d’API disponibles
33. C:> La ligne de commande dotnet
L’homme à tout faire de .NET Core
Universelle
Scriptable
Extensible
Multi-plateforme (évidemment)
Fondation pour les outils de plus
haut niveau
restore
Restauration
des packages
new
build test
add
Ajout de
références
publish
clean pack
Templates
projet
Création
d’un
package
Génération
des binaires
34. Visual Studio Code
Petit Visual Studio deviendra grand
Éditeur de texte enrichi
Adapté pour le Web, node.js et .NET Core
Très extensible
Environnement .NET
complet pour Linux !
dotnet
Extension
C#
VS
Code
37. Petite histoire du fichier de configuration
.kproj + project.json
.xproj + project.json
.csproj
• Très recent !
Pourquoi un project.json ?
Facile à éditer “à la main”
sur Linux et macOS
Retour au .csproj XML
Compatible msbuild
Mais cette fois-ci, facile à
lire et à éditer !
40. Publication
“Framework”
• DLL portable
• A charger via dotnet
“Self-
contained”
• Exécutable natif
• Cible un OS : Windows, Ubuntu…
• Embarque tous le framework
dotnet publish
42. A retenir
Multi-plateforme avec des DLL portables ou des exécutables natifs
Open-source sur GitHub, ouvert aux contributions
Framework distribué par NuGet
Ligne de commande dotnet
Éditeurs Visual Studio 2017 et Visual Studio Code
Templates d'applications Console – Tests unitaires – Bibliothèques – ASP.NET
.NET Standard pour le partage de code
Bonjour, on est ravis
Objectif de la journée : partager ce qu’on a appris nous
Tout d’horizon :
Qui est développeur ?
Qui a joué avec ASP.NET Core ?
Qui est dev web ?
Qui est dev ASP.NET MVC ? Webforms ?
Autres technos ?
On est grands, on est beaux, on est forts, envoyez-nous votre CV.
Oui et non
Oui :
le flux de travail va beaucoup changer
de nouveaux concepts sont à comprendre et assimiler.
Non :
TOUT ne change pas
Non. Clairement non.
Nous allons tenter de démystifier les nombreux changements qu’apportent .NET Core et ASP.NET Core
ASP.NET 4.5+ avait déjà fait un pas en avant vers l’homogénéisation des différentes technologies web de Microsoft.
Mais cette homogénéisation ne faisait que masquer la complexité sous-jacente.
ASP.NET 4.6 et Core COHABITENT
ASP.NET 4.6 est le framework mature, robuste et éprouvé, reposant sur .NET
ASP.NET Core est le nouveau joujou qui vient de sortir et n’est pas forcément LA nouvelle réponse à tout
On peut développer en ASP.NET Core avec le framework .NET Complet.
Il n’y aura pas de conversion auto 4.6 > Core
Certaines API changent
D’autres ont des noms similaires mais un comportement différent
Trop longtemps, nous avons tout fait pour masquer la complexité du développent web.
On a cru pouvoir développer pour le web sans connaître les technologies du web : http, Javascript, css.
Il est grand temps de se les réapproprier.
Les applications modernes ont des architectures plus complexes que par le passé.
En revanche, les possibilités sont tellement plus grandes. Et notre travail nettement plus intéressant.
La complexité n’est plus masque, mais le développement est accompagné. Philosophie plug & play.
Il y a un wagon à prendre.
Ne le ratez pas.
Définir .NET Core
Nouveau composants qui forme le framework
Pas de Web, programmes simples
Project K :
K Runtime Environment / K Package Manager / K Runtime
project.json
ASP.NET vNext :
TechEd
Projet pilote autour duquel se construit la plateforme .NET Core
ASP.NET 5 :
Connect()
Visual Studio 2015
Briques sous-jacentes à ASP.NET > code au coeur du framework > .NET Core
Suite logique de l’orientation de Microsoft depuis quelques années
C’est tout un écosystème qui est open-source (machine virtuelle, bibliothèque de classe, ASP.NET, ligne de commande, Visual Studio Code)
GitHub : L’équipe .NET de Microsoft suit le même processus de développement que la communauté et passe par des Pull Request et des revues de code
Pourquoi l’open-source :
Manière naturelle de construire une solution multi-plateforme
S’appuyer sur l’expérience de Mono
Cycles de livraison court, feedback rapide des utilisateurs
.NET Foundation :
NuGet et Mono
Que faut-il pour se lancer dans .NET Core ?
SDK :
Les outils en ligne de commande
Multi-plateforme
Visual Studio Code :
Expérience épurée, rapide mais très complete (IntelliSence, débuggeur, etc.)
Multi-plateforme
Visual Studio 2017 :
- RC gratuite
- Expérience complète, toute-en-un
Multithreading : création de threads, type Thread et Task
Multiplateforme : écrit en C++ donc compilé pour chaque plateforme
CoreFX fournit tous les types utilisables dans nos applications
Les types de bases sont visibles publiquement dans CoreFX mais « redirigent » le compilateur vers leurs implémentations dans CoreCLR
Chaque namespace est distribué dans un package NuGet
Plateforme pensée très modulaire
NuGet est le vecteur principal de distribution : runtime, assemblies, spécification .NET Standard
Objectifs :
Réduire les dépendances inutiles (chaque package a les siennes)
Réduire l’empreinte mémoire des exécutables
Evolution des packages indépendante du framework dans son ensemble (dans la pratique : nouvelle version de .NET Core = nouvelle version de chaque package)
Code source de System.Collections dans GitHub
Le package NuGet généré
La référence dans le fichier projet
L’usage dans le code
“Package de packages” : ne contient que des dépendances vers d’autres packages NuGet
.NET, écosystème fragmenté
Positif : chaque projet a une méthode de développement et des outils bien calibrés
Mais : bibliothèques de classe réutilisable, dépendances entre projets
.NET Core est une nouvelle stack, incompatible avec .NET Classique
Exemple : impossible de référencer un projet .NET depuis une application .NET Core
Distribuer une bibliothèque :
Anciennement : Recompiler pour chaque SDK cible
Depuis 2011 : PCL (union de SDKs)
Problèmes des PCL :
Liste et version des Targets en dur
Non versionné
Plus de target = moins d’API
(SDKs : .NET complet, .NET Core, Mono, Windows, Windows Phone, Unity, Silverlight)
Définition d'une liste d'API que chaque runtime doit implémenter
Spécification du contenu que l’on attend d’un framework
Pas de code, seulement des redirections vers les classes du runtime sous-jacent (“TypeForwading”)
Versionné
Métapackage NuGet : NETStandard.Library
Cibler netstandard signifie : le programme déclare qu’il utilise ces API, et qu’il est prêt à s’exécuter sur les runtimes compatibles
Adapté aux bibliothèques de classe
Exemple : une bibliothèque écrite pour .NET Standard 1.2 pourra être référencée par un programme .NET Core 1.0, .NET 4.5.1, Mono 4.6, etc.
Conclusion : .NET Standard déjà supporté par la plupart des plateformes
PI : on peut créer des PCL .NET Standard ou des projets au format .NET Core.
SDK : compilateur, machine d’execution
Bibliothèque de classe : Assemblies et APIs accessible depuis notre code
Packages NuGet : chaque package est accessible pour certains framework
Compatibilité : la capacité de votre programme à être référencé par d’autre
“net” :
On peut très bien s’appuyer sur le framework “traditionnel”, Windows (dépendance à Windows, au framework disponible sur la machine cible, accès à toutes les APIs de la BCL)
(SDKs : .NET complet, .NET Core, Mono, Windows, Windows Phone, Unity, Silverlight)
net46 (windows, bcl, compatibilité lib) :
Rapide et facile pour les applications qui s’exécutent sous Windows
netcoreapp (multi-plateforme, compatibilité difficile)
Pour les applications “finales” Console ou Web
netstandard (pour les libs, grande compatibilité, api réduites) :
Pour les bibliothèques partagées
Résumé des composants :
CoreCLR
CoreFX
Distribué par NuGet
.NET Standard, pour se réconcilier avec l’écosystème .NET
Choisir son target framework
dotnet new
dotnet restore
dotnet build
dotnet run
Installée avec le "SDK .NET Core" (windows, linux, etc.) Anciennement "dnu/dnx/dnvm" Outil universel pour centraliser toutes les opérations d’un projet CoreDélègue la compilation à msbuild depuis la preview3
Commandes de bases : new (templates Console, Web, Tests), restore, build, test, publish Et aussi : pack, add package, clean
Open-source, multi-plateforme, gratuit
Ressemble beaucoup à Atom, basé sur le même framework (Electron)
IntelliSense, Coloration, Debugguer, Git, extensions, (+ refactoring)
Orienté Web, node.js et .NET Core
dotnet new -t webcode .
Ctrl+P
Remove using
Intellisense
CodeLens
Breakpoint Startup + F5
Fermer VS Code
dotnet add package AutoMapper
code .
« mapper » > Ctrl+; > using
Nouvel installeur Performance (démarre 50% plus vite)Live testing
Débuggueur (exceptions, profiling), éditeur (refactoring)
Ouvrir un dossier (projets Web)Support .NET Core avec template, gestion unifié des dépendances
Bénéfices du project.json progressivement ajouté dans le CSPROJ
Le web.config / app.config a disparu ! (Non c’est faux, IIS en a besoin pour démarrer un site Web…)AppSettings sont déplacés dans un fichier JSON : appsettings.json
Petit détail qui change la vie : plus besoin de lister les fichiers sources dans le XML ! Ceux-ci sont détectés automatiquement dans le dossier
Templates CoreProjet Xunit
Clic droit > Edit .csproj.csproj : liste des fichiers sourceAssert(1,2)Run tests
(Supprimer <Compile> )
cmd : dotnet test
Basé sur un framework : génère une .dll portable exécutable avec le loader dotnet :
Même pour une application console, on a une dll dont le Main sera lancé par la commande dotnet
« Auto-contenu » : génère exécutable basé sur un runtime (.exe, etc.), embarque le framework (hello world 50 Mo)
Pour résumer, nous avons vu que :
-
-
NuGet est le vecteur principal de diffusion des nouveaux composants
La CLI dotnet est légère, facile d’accès. Ce sera votre meilleur ami pour travailler en .NET Core
Visual Studio 2017 est bientôt prêt, et VS Code propose une experience de développement très satisfaisante
Les templates suivants sont disponibles pour initialiser un projet : …
.NET Standard est l’avenir du partage de code dans tous l’écosystème .NET
Nous allons enchainer sur la session MVC
Si vous avez des questions : pause déjeuner, ou en fin de journée pendant une session de questions/réponses et débats sur tous les sujets