[Tips] Changer la culture de tous les threads en 1 ligne de code

Avec ASP.net, il est possible de définir globalement la culture via le fichier de configuration web.config et les attributs uiCulture et culture de la balise globalization :

<globalization uiCulture="fr-FR" culture="fr-FR"/>

Seul problème, cette configuration ne s’applique pas à l’ensemble des threads créés manuellement depuis les pages/handlers/modules.

En effet, si on créé un thread depuis une page, la culture par défaut de ce thread sera la culture du système sur lequel l’application est installée.

Avant .net 4.5, il était donc nécessaire de changer la culture manuellement à chaque création de thread.

Depuis .net 4.5, il est possible de définir une culture par défaut pour tous les threads qui seront créés par votre application via la propriété statique DefaultThreadCurrentCulture de classe CultureInfo :

CultureInfo.DefaultThreadCurrentCulture = ci

A la découverte d’Hololens !

Vous avez très probablement tous vu plusieurs vidéos de démonstration des lunettes de réalité augmentée proposée par Microsoft : Hololens.

Et c’est avec un grand plaisir que j’ai pu essayer ces lunettes grâce aux copains d’Infinite Square.

image

Je ne vais pas ici vous proposer une n-ième description du device, mais plutôt vous proposer une petite synthèse de mon ressenti.

Les points forts :

  • Ces lunettes sont en réalité un vrai PC sous Windows 10 ! Même si nous avons maintenant l’habitude d’avoir des monstres de puissance dans nos poches grâce aux smartphones, avoir un PC autour de la tête reste une prouesse technologique impressionnante, d’autant plus que les lunettes ne sont pas lourdes, elles sont confortables et se laissent porter tout naturellement.
  • Très bonne fluidité de l’image (applications, et hologrammes), on ne ressent pas de lag gênant lorsque l’on bouge la tête, le ressenti est naturel.
  • La précision des gestures. Le tracking de la position de la main et des doigts et la reconnaissance des gestures sont plutôt bluffants. Les manipulations effectuées dans les vidéos de démonstrations sont tout à fait réalistes, la prise en main est vraiment aisée.

Les points faibles :

  • Je vais rejoindre l’ensemble des articles sur le sujet : le champ de vision ! Alors que les différentes vidéos de démonstration du device nous vendent du rêve, en nous faisant croire que l’ensemble du champ de vision est couvert grâce aux lunettes, le résultat final est assez éloigné de ce que l’on a pu voir dans les démonstrations de la Build, ou encore de TED :
    image
    Cela ne supprime pas toute utilité aux lunettes, loin de là, mais cela réduit l’adoption de scénarios nécessitant d’avoir l’intégralité du champ de vision disponible.

Microsoft n’arrive pas en tant que pionnier dans le domaine de la réalité augmentée via des lunettes spécialisées car Google avec ses célèbres Google Glass a permis de mettre la lumière sur ce domaine prometteur, même si les approches et les possibilités proposées par les deux devices sont très différentes.

Même si les lunettes disponibles sont une vraie prouesse technique, le vrai défi sera d’arriver à faire d’Hololens un vrai produit ! Google a, pour le moment, échoué sur ce point, et il n’est pas simple d’arriver à percevoir si Microsoft va réussir à convertir ce qui peut être considéré comme un prototype très prometteur en succès commercial.

L’augmentation du champ de vision serait un atout vraiment considérable qui pourrait positionner les lunettes comme étant un must-have dans de nombreux scénarios. Un positionnement clair du géant de Redmond est également indispensable afin de démarrer une vraie phase de commercialisation.

Et même si des projets comme Hololens nous démontrent que de gros progrès techniques sont faits dans le domaine, il y a bien une chose de sûre :  nous allons encore devoir attendre un temps certain avant d’avoir un device grand public qui nous permettrait de nous guider dans les gares et aéroports, qui nous donnerait des informations sur notre environnement proche, etc.

Il est d’ailleurs frappant de constater que Google et Microsoft ont tous deux présenté leurs premières démonstrations en montrant des usages orientés “consumer” (démonstration à la maison, dans son salon, dans la cuisine, ou dans la vie quotidienne) pour finalement indiquer que la cible des devices est le monde professionnel. Preuve que le chemin est encore long avant de disposer d’un device répondant à toutes les promesses de la réalité augmentée.

Un grand merci à Thomas et Florent pour avoir passer pas mal de temps à me montrer cette belle innovation conçue par Microsoft.

Build 2016 : Building a conversational bot in 60 minutes B821

Comme annoncé lors du premier keynote, Microsoft lance son framework de bot simplement baptisé Microsoft Bot Framework.

Ce framework vous permet de créer un nouveau type d’UI où au lieu d’interagir avec une application avec une interface graphique, vous pouvez directement discuter en langage naturel avec un bot. Vous pouvez penser à un Cortana ou Siri personnalisé et spécialisé et accessible via le channel que vous souhaitez : chat web, slack, sms, mail, skype, etc.

Ainsi au lieu de faire l’effort de traduire ce que vous souhaitez faire en manipulations, vous pouvez directement demander ce que vous souhaitez faire, à charge au bot de répondre à votre demande et de réaliser les actions souhaitées.

L’intelligence du bot ne se situe pas au niveau du Bot Framework qui n’est “qu’” une couche technique, mais vous allez pouvoir utiliser les différentes briques d’IA proposées par Microsoft (ou par d’autres) afin d’apporter cette intelligence. Si vous souhaitez comprendre les phrases formulées naturellement, vous pouvez par exemple utiliser le service Langage Understanding Intelligent Service (LUIS) qui est directement accessible via les API du Bot Framework.

Briques du Bot Framework

Le Bot Framework se compose d’un Bot Builder SDK, qui permet de créer la logique du bot en étant appelé lors de la réception d’un message et en permettant d’y répondre, et ceci “manuellement” ou en utilisant une analogie de formulaire qui permet de décrire les différentes étapes d’une conversation.

Le service Bot Connector reçoit techniquement les messages et envoie les réponses à l’utilisateur, et fournit des services additionnels tels que de la traduction à la volée des messages, ou de la télémétrie.

Ce service reçoit envoie des messages via les différents channels déjà cités précédemment.   

Un bot créé via le Bot Builder SDK est en réalité un endpoint HTTP appelé par le Bot Connector, et qui renvoie des informations au format json à celui-ci.

Cet endpoint doit donc être accessible de manière publique afin d’être appelé par le Bot Connector.

Le développement d’un bot se fait via un template de projet Visual Studio qui vous permet de vous abonner aux différents évènements de réception de messages utilisateurs ou système.

Une API assez simple vous permet de répondre aux messages reçus de l’utilisateur. D’un point de vue débogage il vous ait possible d’utiliser un émulateur qui vous permettra d’interagir avec votre bot sans avoir à le publier et à le configurer.

LUIS

Le service d’interprétation de langage naturel proposé par Microsoft fonctionne selon un principe simple : il faut définir des “intentions” c’est à dire des actions paramétrables que vous souhaitez être capable d’interpréter. Ainsi si vous souhaitez être capable de comprendre que l’utilisateur souhaite “formater un disque dur”, vous pouvez créer une intention décrivant cette demande, et ensuite entrainer le moteur de LUIS afin de lui apprendre à reconnaitre les différentes formulations de cette intention (“formater lecteur C:”, “formater disque D:”, “ressusciter le drive E:”, etc.”).

Cet apprentissage se fait en donnant différents exemples de formulation et en identifiant  les valeurs que vous souhaitez récupérer via la notion d’Entity. Dans notre précèdent exemple, il faudra identifier la lettre du lecteur (C:, D: , etc.) pour que le service LUIS nous renvoie directement cette valeur sans avoir besoin de parser manuellement celle-ci.

Il n’est donc pas utile d’écrire du code pour parvenir à avoir une IA capable d’interpréter du langage naturel, il suffit d’utiliser l’UI de LUIS, puis de consommer le service exposé par LUIS pour ajouter ce type de fonctionnalité dans une application !

Création de “formulaires”

Le Bot Builder SDK permet la création de “formulaires” qui ne sont pas réellement des formulaires mais un template de dialogue. Vous pouvez définir les différentes informations souhaitées (les “contrôles”) sous forme de propriétés, et créer automatiquement une conversation grâce à ce mécanisme :

A noter la possibilité d’ajouter de la validation, et de combiner cela avec LUIS pour toujours bénéficier de la reconnaissance de langage naturel à chaque étape.

Build 2016 : Building a 3D Game with Unity and Visual Studio T607

Unity est environnement de création de jeux qui propose un moteur graphique 2D et 3D ainsi qu’un moteur physique.

Permettant de déployer un jeux sur une variété impressionante de plates-formes différentes (iOS, Android, Windows, PS4, WiiU, 3DS, XBox, etc. etc.), Unity est devenu ultra-leader sur un marché qui a beaucoup changé suite à l’explosion de l’adoption des smartphones.

image

Unity revendique une communauté de 5 millions de développeurs et dispose un eco-système très riche grâce à cette très importante communauté. Près de la moitié des développeurs de jeux (tout support confondus – mobiles, consoles, etc.) sont des développeurs Unity, et 90% d’entre eux sont sous Windows.

En plus de proposer le développement de jeux, Unity est également présent dans un secteur prometteur qui débute à peine : la réalité virtuelle mais également la réalité augmentée. Unity est en effet le moteur utilisé par Oculus et par Hololens.

Il est possible d’écrire du code pour Unity dans une variété de langages : C#, Javascript ou encore Boo.

Depuis Unity 5.2, Visual Studio est l’éditeur de script par défaut de Unity sur Windows ! Les créateurs de jeux utilisant cette plate-forme installent donc par défaut Visual Studio Community 2015 et les Visual Studio Tools for Unity afin que chacun utilise C# comme langage de script :

image

Il s’agit clairement d’un big win pour Microsoft et pour Visual Studio, .NET est une brique importante de la plate-forme ultra-leader sur le développement de jeux pour mobiles parce qu’Unity utilise la VM de Mono pour exécuter les scripts C# et Visual Studio pour l’édition de ce code.

Visual Studio peut donc être utilisé en tant que complément de l’éditeur d’Unity, celui-ci s’intègre directement au sein de cet éditeur. Dès lors où l’on souhaite éditer un fichier C# dans un projet Unity ouvert depuis l’éditeur d’Unity, Visual Studio s’ouvre :

Ne cherchez donc pas de templates de projets particulier dans Visual Studio. Le workflow n’est pas l’habituel File\New Projet dans VS, mais bien d’éditer les fichiers C# depuis Unity pour accéder aux Visual Studio Tools for Unity.

Pour consulter une démonstration complète : https://channel9.msdn.com/Events/Build/2016/T607

Build 2016 : How Cortana Can Proactively Drive Engagement With Your Apps B834 / B833

Le résumé de ces deux sessions va être à l’image de ma déception, et du contenu de celle-ci : rapide et sans trop d’intérêt. Bien que largement plus dynamique que la B834, la B333 illustre bien ce “ratage” : une session qui dure moins de 23 minutes au lieu d’1h. C’est dire si le contenu ciblé était intéressant et fourni…

Ces deux sessions décrivent comment s’intégrer au panneau de Cortana via des “Proactive Actions”. On parle donc ici uniquement de la manière d’accéder à vos applications depuis Cortana.

L’idée est que Cortana a différentes connaissances au niveau du contexte de l’utilisateur et sur l’utilisateur de manière générale, et qu’elle va être capable de communiquer certaines de ces informations à votre application, afin que vous puissiez proposer et exécuter certains actions :

image

Ces actions sont enregistrables et paramétrables sur http://developer.microsoft.com/cortana

N’hésitez pas à consulter uniquement les slides de ces sessions si vous êtes intéressés, tout y est indiqué, inutile de regarder les sessions qui n’ont malheureusement que peu d’intérêt.

Il est dommage d’avoir ce type de sessions et de contenu sur un sujet aussi intéressant avec autant de potentiel que Cortana… Espérons que Microsoft nous proposera des intégrations riches et pertinentes afin que nous puissions interagir avec Cortana avec une vraie dose d’intelligence !

Build 2016 : .NET Overview B891

.NET Everywhere

.NET change radicalement de dimension en permettant de développer n’importe quel type d’application et sur n’importe quel type de plate-forme :

L’environnement de développement et d’exécution de .NET se trouve à présent décomposé au sein de 3 frameworks distincts :

  • L’historique Framework .net maintenant livré avec chaque version de Windows. Destiné au développement d’applications desktop sous Windows (en Windows Forms ou en WPF), aux applications serveurs sous Windows
  • .NET Core : framework .NET cross-platform pour Windows, Linux, OS X, etc. 
  • Xamarin : Le framework de développement d’applications managées en C# pour iOS, Android et MacOS.

Ces 3 frameworks disposent chacune de ses propres libraires de base. Un travail d’uniformisation doit être fait afin d’uniformiser l’ensemble et ne plus avoir 3 frameworks complètement distincts.

Une .net Standard Library est donc en cours de conception afin d’uniformiser les bibliothèques de base de ces 3 plates-formes de développement. La réutilisation/partage de code sera donc réél, et non dépendant de « bidouilles » techniques comme cela peut être le cas actuellement.

Avant :

clip_image002

Après :

clip_image004

Open Source

De plus en plus de briques de l’eco-système .NET sont Open Source, EF 6, EF Core, ASP.NET Core, .NET Core, Mono, Xamarin, Roslyn, NuGet, et tout cela est fait sans compromettre la qualité et la stabilité des produits finis car toutes les soumissions sont validées et suivent le même processus d’intégration/validation que les développements effectués en interne par les Microsoftees.

De plus, bien qu’Open Source, et bien qu’utilisant des technologies tierces (bootstrap, jQuery, etc.) l’intégralité de la plate-forme est supportée par Microsoft.

Signe de l’investissement de Microsoft sur l’open source, une organisation spécifique a été créé afin de gérer les projets Open Source liés à la plate-forme de développement de l’éditeur : .NET foundation.

Le rôle de cette organisation est de gérer l’ensemble des projets Open Source dont elle est a la responsabilité. Par gestion, on n’entend gestion des problématiques légales, gestion des secrets (certificats SSL, etc.), cette gestion n’inclue évidemment pas l’écriture de code qui par définition est ouverte à tous.

Cette organisation doit également dynamiser et animer tout l’éco-système Open Source autour de .NET, deux nouveaux membres ont rejoint cette organisation :

  • RedHat : pour leur inclusion de .NET Core au sein de RedHat Enterprise Linux
  • Unity : pour leur utilisation de C# et de Mono au sein de leur produit

Nouveautés de .NET

Les premières nouveautés décrites dans cette session sont détaillées dans les résumés des deux session suivantes :
The future of C#
Building Desktop Apps

La conversion de FxCop en tant qu’analysers Roslyn. Au lieu de vérifier des règles statiques lors de la compilation, il est désormais possible d’avoir une analyse en temps réél comme peut l’être la vérification syntaxique de code.

Déjà disponible en F#, une nouvelle fenêtre C# Interactive permet d’exécuter du code C# en live, sans effectuer la traditionnelle boucle écriture de code + F5 pour lancer l’exécution de l’application ainsi que le débugger.

Ajout d’un « super using » qui permet d’ajouter une référence à un namespace mais surtout de récupérer les assemblys nécessaire directement depuis nuget ! Ainsi au lieu d’accéder aux métadonnées d’assemblys Open Source référencées, nous aurons la possibilité de directement à leurs sources. A noter également la possibilité de débugger directement le code ainsi récupéré sans avoir à télécharger des PBDs ou autre fichier.

Build 2016 : EF Core B852

Tout comme ASP.NET 1.0 Core qui fut renommé à juste escient, EF Core a également été baptisé plusieurs fois avant de posséder ce nom (final ?). Entity Framework Everywhere, Entity Framework 7, et EF Core désignent donc un seul et même framework.

Comme pour la plupart des autres technos de développement Microsof, Entity Framework a évolué avec le temps avec d’être plus agile et livrer de nouvelles versions beaucoup plus rapidement :

image

Tout comme ASP.NET Core, EF Core ne couvre pas le même périmètre fonctionnel qu’EF 6, et est cross-platform :

De la même manière qu’EF cherche à tourner sur différentes plates-formes, Entity Framework cherche à être capable de consommer d’autres types de sources de données.

Les sources de données non relationnelles deviennent en effet de plus en plus présentes, et EF Core va donc s’adapter afin de supporter ces scénarios. Même s’il est à noter que la V1 ne contiendra que les providers relationnels. Des providers pour Azure Table Storage, et Redis devraient être disponibles ultérieurement.

Comme pour ASP.NET Core, EF est basé sur une architecture modulaire et extensible, avec la possibilité de rajouter les briques proposées par Microsoft ou utiliser des briques tierces.

Microsoft positionne EF 6 comme étant la version mature de d’EF, la version stable et fonctionnellement la plus avancée. A noter qu’il est probable que cette version n’évolue plus de manière importante. Vu le discours tenu, on peut penser que Microsoft la considère comme étant feature-complete, et ne fera pas d’investissement significatif dessus.

Quand à EF Core, il s’agit d’un développement from-scratch. Il s’agit donc d’une reélle V1. Il sera possible de porter du code d’EF 6 vers EF 1, mais il s’agira d’une migration avec probablement des adaptations manuelles à faire pour être compatible avec ce nouveau framework.

EF Core

Passons donc enfin à EF Core. Ce nouveau framework abandonne le principe du designer d’EDMX qui permet de manipuler plusieurs fichiers XML pour représenter le modèle. Il sera néammoins bien évidemment possible de gérer les scénarios database-first et code-first. Il n’y aura juste plus de designer usine à gaz, qui manipule des fichiers XML qui ne sont quasiment pas modifiables manuellement.

D’un point de vue performance, Microsoft annonce d’importants gains. Une démonstration est faite sur de la lecture simple d’une table à partir de modèles générées à partir de la BDD :

Les mêmes résultats ont été obtenus avec une requête ayant des critères Where assez simples ainsi qu’un regroupement, mais également sur des requêtes de modifications. Si les gains de performances annoncés sont rééls dans de réélles conditions d’utilisation, il s’agira là d’une très importante amélioration !

L’API de consultation des méta-données a été grandement simplifiée :

La gestion des applications multi-devices et cross-platform est supportée via la gestion de deux scénarios :

  • Partage d’un modèle unique utilisé par des applications sur différentes plates-formes
  • Partage d’un modèle unique stocké sur plusieurs bases de données et synchronisées au sein d’une BDD centrale

Des améliorations au niveau de la génération du code SQL sont également apportées avec notamment le support du batching de mise à jour et d’insertion :

La possibilité de composer une requête mixteà partir d’une requête SQL et d’un requête LINQ :

image

image

Build 2016 : The Future of C# B889

A l’écoute des développeurs et notamment des sondages StackOverflow, l’équipe Langages de Microsoft semble revenir sur la co-évolution des langages C# et VB :

Alors que depuis Visual Studio 2010, l’ensemble des nouveautés proposés par un des deux langages étaient implémentées sur le second, l’éditeur de Redmond identifie que les populations de développeurs sont différentes avec des besoins différents.

Aucune annonce précise n’a été faite en ce sens, nous devrons donc attendre de voir les résultats de ce changement de politique.

Passer d’un langage Windows à un langage fonctionnant partout

Autre changement celui-ci vraiment fondamental, comme pour les autres technologies de développement, l’équipe du langage C# est maintenant d’avoir un langage utile pour réaliser des applications sur n’importe quel type de plate-forme.

Ce changement de stratégie s’illustre par différent changement importants :

image

Pièce maitresse de cette nouvelle stratégie : Roslyn. L’équipe langages de Microsoft souhaite en faire la plate-forme commune à tout l’outillage, à tout l’éco-système des langages C# et VB. Ainsi, l’objectif de l’équipe est que l’ensemble des IDE et éditeurs de code, des outils d’analyse statique, des outils de refactoring, etc. permettant de manipuler/travailler avec du code C# utilisent Roslyn.

“There should only need to be one code base for understanding C#”

Un objectif atteignable pour Microsoft à une exception majeure près : Jetbrains ! Ceux-ci ont en effet clairement indiqué qu’ils ne passeraient pas sur Roslyn pour le plug-in le plus important de Visual Studio : ReSharper. Cela est également valable pour l’IDE C# cross-platform toujours de Jetbrains : Project Rider.

Les nouveautés de C# 7

Microsoft souhaite livrer plus rapidement les évolutions du langage C#, il faut donc s’attendre à des mises à jour plus régulières des compilateurs.

Ajout des binary litterals :

image

Support des local functions : Il est à présent possible d’écrire des méthodes à l’intérieur de méthodes :

 

Le langage C# supportera de manière native les tuples. A noter que ces tuples ne sont pas basés sur le type Tuple du framework .net mais sur une struct :

image

A noter la possibilité de nommer les membres du tuple en complément de la syntaxe décrite dans le screenshot ci-dessus.

Ajout du Pattern matching :

image

Côté Outillage

Une des priorités étant le support du langage par toutes les plates-formes, il est indispensable de supporter d’autres environnements de développement et éditeurs de code.

L’intégration de C# au sein de Visual Studio Code s’améliore, celle-ci se base sur un plug-in présent sur le Marketplace  et utilise techniquement le projet OmniSharp afin de proposer le service d’Intellisense par exemple.

Du côté de Visual Studio, l’Intellisense est amélioré afin de mettre en gras les éléments saisis qui correspondent aux résultats proposés par l’Intellisense :

image

Autre amélioration de l’Intellisense, il sera possible de filtrer les résultats de l’affichage afin de masquer toutes les méthodes d’extensions associées à un type :

L’Intellisense devrienda également plus tolérant aux fautes de frappes. Ainsi une saisie de XlmDocument permettra de d’effectuer différentes actions malgré l’erreur de typo :image

Et enfin dernière nouveauté, l’ajout de gestion de styles de code dans Visual Studio afin indication visuelle si les conventions ne sont pas respectées :

image

Build 2016 : Building Desktop apps in Visual Studio “15” B824

 

Depuis Windows 8, le monde des applications desktop se décompose en 2 univers :

image

Première nouveauté pour les applications XAML, l’ajout d’un outil de debug, un cousin de snoop directement intégré à votre application en debug et à Visual Studio.

Il est également possible d’appliquer l’edit & continue pour les modifications de code XAML, il est ainsi plus rapide de modifier son code et de voir le résultat en temps réél, sans stopper et relancer son application en débug à chaque fois.

Autre nouveauté, les light bulbs, des actions contextuelles comme par exemple la suppression de références de namespaces XAML inutiles.

Des avancées en terme d’accessibilité seront également, avec notamment un nouvel environnement de tests permettant de valider le bon fonctionnement d’une application dans des conditions particulières d’utilisation.

Desktop to UWP Converter

L’objectif de ce projet est d’être capable de convertir n’importe quel application Win32 (C++, VB6, etc.) et .net afin de les rendre disponible sur le Windows Store. Bien évidemment tout n’est pas magique, les applications repackagées seront disponibles uniquement sur le Windows Store PC, et non sur les autres Windows Store (et cela est déjà très bien).

L’idée est de repackager vos packages MSI sous forme de packages APPX qui pêuvent donc être déployables via le Windows Store. Techniquement, l’opération de rapackaging doit actuellement être réalisé via une commande Powershell. Il n’est à pas douter que cela sera directement intégré à Visual Studio prochainement.

Cette reconversion ne concerne que les programmes d’installation ne nécessitant pas de de saisie d’information particulière (ex : chemin réseaux, etc.), car l’installation de packages APPX se fait de manière automatisée, sans saisie d’informations.

L’opération de conversion exécute le package MSI afin d’analyser toutes les actions effectuées par le MSI. L’outil détecte les ajouts de fichiers effectuées, les modifications de registre effectuées, afin de pouvoir être virtualisées lors de l’installation via un package APPX.

L’ensemble des fichiers générés peuvent suite être retravaillés sous Visual Studio afin d’avoir une application UWP prête à être packagée. Il vous est alors possible de débugger votre application Win32 en tant qu’applicatin UWP, définir les propriétés nécessaire à la création du package, etc.

image

Nouveautés de WPF 4.6.2

Support du clavier logiciel lorsqu’une textbox a le focus. Cet affichage du clavier sera automatique avec une prochaine mise à jour du framework .net, et ne demandera aucune modification de code. A noter que cela ne concernera que Windows 10 et non les versions précédentes de Windows.

Support du multi-écran avec des écrans ayant des définitions différentes. Un simple abonnement à un évènement permettra d’adapter l’affichage de son application lors du changement d’écran.

Build 2016 : ASP.NET Overview B810

L’équipe ASP.NET a annoncé il y a quelques semaines un changement important de nommage au niveau ASP.net. ASP.NET 5 a été renommé en ASP.NET 1.0 Core. Comme je l’avais indiqué à ce moment-là, ce changement est vraiment pertinent afin de clairement indiquer qu’ASP.NET 5 n’est pas le successeur d’ASP.net 4.6.

Il s’agit d’une nouvelle version, cross-plate-forme.différente de la version 4.6 et qui ne couvre pas le périmètre fonctionnel d’ASP.net 4.6.

Il est important de noter qu’ASP.net Core fonctionne certes sur le NET 1.0 Core mais il peut également fonctionner sur le framework .NET 4.6 traditionnel sous Windows.

A l’heure actuelle, .NET Core 1.0 et ASP.NET Core 1.0 ne sont pas disponible en RTM, seuls les frameworks sous Windows que nous connaissons le sont.

A noter qu’ensemble des framework “Core” sont disponibles en Open Source, ainsi qu’ASP.net 4.6. Et on parle bien ici, de “vrai” Open Source, le code source est réellement ouvert à contribution de chacun.

ASP.NET Core 1.0 est basé sur une architecture totalement modulaire, l’idée est de vous permettre de construire votre propre “stack” ASP.NET en y incluant les modules de Microsoft que vous souhaitez, mais également des modules tiers. Il est ainsi possible d’avoir une version très spécialisée en fonction de vos besoins.

Par défaut, aucun module n’est chargé et ASP.net 1.0 Core ne gère “pas grand-chose”, pas de gestion de pages d’erreurs, pas de gestion de pages statiques.

Afin de simplifier l’adoption de Visual Studio pour les développeurs “non-microsoft” de très importants efforts ont été fait au sujet de l’installation.

VS15 propose en effet un nouveau programme d’installation plus léger et surtout vraiment beaucoup plus rapide. Installer Visual Studio en moins de 3 minutes est à présent possible :

 

L’ouverture d’ASP.NET s’illustre par différents points :

  • La manière de l’utiliser. Vous pouvez récupérer la version d’ASP.NET proposé par défaut mais également récupérer les builds issus du processus de CI de Microsoft, ou encore compiler directement vous-même le sources du framework :

image

  • Il est également possible d’utiliser vos éditeurs code favoris (ex : sublime) via le projet Omnisharp
  • Et enfin, cette ouverture s’illustre par l’adoption des “standards” du web (npm, bower, less, sass, etc.)

ASP.NET 1.0 Core se base sur un nouveau type de projet. Fini les traditionnels fichiers .csproj ou .vbproj contenant une description au format msbuild (fichier XML), les fichiers de projets sont à présent au format .json afin d’être plus lisible et plus facilement outillables sur l’ensemble des plates-formes supportées.

A noter que l’inclusion des fichiers au sein des projets est inversée par rapport à ce que Visual Studio faisait avec les .csproj. Au lieu d’indiquer l’ensemble des fichiers inclus dans le projet, les fichiers présents dans le dossier du projet sont automatiquement inclus, on indique uniquement les fichiers qui en sont exclus.

Visual Studio permet d’utiliser bower et npm afin de gérer les packages clients, nuget étant uniquement pour les packages .net.

ASP.NET Core propose de nouveaux tag helpers afin d’éviter de trop polluer le code HTML des vues avec du code C#. L’idée est de simplifier le code afin d’avoir une vue HTML qui continue de ressembler à l’HTML.

Une utilisation pertinente de l’ajout du support de Bash sous Windows a également été montrée. Installer redis sous Windows est à présent très simple puisqu’il suffit de faire un apt-get !

A noter qu’il est possible assez simplement d’utiliser redis en local sur son poste de développement puis d’utiliser une instance sur le cloud sans modification de votre applicatif. Un bel exemple d’intégration de technologies tierces directement au sein d’ASP.NET.

Afin de montrer la souplesse d’ASP.NET Core et la non-adhérence à une plate-forme spécifique, une démonstration a été faite de l’utilisation d’un raspberry 3 en tant que serveur ASP.NET ! Une démonstration qui n’est pas sans rappeler la mise en place d’un serveur ASP.NET basé sur Mono et fonctionnant sous XBOX faite il y a quelques années par @jbevain Clignement d'œil

Visual Studio proposera un support intéressant de Docker pour Windows. L’intégration proposée, permet d’ajouter le support de Docker au niveau d’un projet ASP.NET Core, et de démarrer une session de debug qui va automatiquement mettre en place et configurer un container Docker (sous Linux par exemple), effectuer le déploiement et lancer le débug de l’application ainsi déployée.

Il sera donc possible d’utiliser Docker et de bénéficier de tous les avantages de l’utilisation de Containers ! Une démonstration intéressante d’hébergement de déploiement d’une application ASP.NET Core dans des containers déployés sur Azure et sur Amazon a été faite en fin de session afin de démontrer la possibilité d’automatiser ce type de déploiement et ainsi avoir une application résiliente dont la charge est répartie sur deux fournisseurs de cloud différents.