.NET Standard Platform
<img class=”alignleft size-medium wp-image-23101″ src=”/wp-content/imported/2015/11/asp.net_.jpg” alt=”ASP.NET logo” width=”199″ height=”170″” />Le framework .NET 4.5, le framework .NET 4.6, .NET Core, etc. Si vous suivez ASP.NET Core vous avez dû voir défiler de nombreuses versions de Framework dans vos fichiers project.json. Certaines ne sont restées que le temps d’une ou deux versions de betas puis ont disparu. Avec la version RC1 d’ASP.NET Core, les bases sont maintenant posées et le futur de .NET prend enfin forme. Aujourd’hui, je vous propose une introduction à .NET Standard Platform, qui devrait répondre aux questions que vous pourriez avoir quant aux différentes plateformes et environnements liés à ASP.NET Core et à .NET en général.
PCL et portabilité
A l’heure actuelle, créer une librairie qui peut être déployée sur plusieurs plateformes passe presque automatiquement par l’utilisation de la PCL. Généralement, en tant que développeurs Web, c’est une problématique qui se pose moins souvent que pour nos collègues développeurs Windows Phone / Windows. Pourtant, avec ASP.NET Core, c’est un sujet qui a maintenant toute son importance. En effet, une application ASP.NET Core peut être déployée vers un environnement utilisant mono, ou dotnet core, ou le framework.net 4.5, etc.
Pour les lecteurs qui ne connaissent pas la PCL, il s’agit un type de projet spécifique dans Visual Studio. Ce type de projet permet de produire un binaire qui peut être référencé par un ensemble de plateformes. Cet ensemble de plateformes est défini à la création du projet, mais il peut bien évidemment changer au cours du temps. En fonction des plate-formes choisies, le processus de compilation s’adapte automatiquement afin de restreindre les librairies et fonctions utilisables à celles compatibles avec la cible.
Avec une PCL, les plateformes choisies sont exprimées sous la forme d’une combinaison du type portable-net45+win8. Vous avez probablement déjà vu ce genre de chaîne de caractères sur NuGet. Ainsi, une telle librairie serait restreinte à ne pouvoir s’exécuter que sur le framework .NET 4.5 et sur Windows 8. Si demain, une nouvelle plate-forme apparaît et est compatible avec les mêmes APIs que .NET 4.5 et Windows 8, alors la PCL ne sera pas compatible avec cette nouvelle plate-forme. Il faudrait alors republier une nouvelle version de la librairie, en ajoutant la nouvelle plate-forme dans la liste des cibles.
Dans le jargon de la PCL, le terme moniker est utilisé pour désigner une plateforme. Ainsi, net45 est un moniker. Et win8 en est en autre.
Ainsi, on peut maintenant affirmer que dans son fonctionnement, la PCL utilise une liste statique de monikers pour exprimer les plate-formes cibles compatibles avec la librairie.
Qu’est-ce que .NET Standard Platform ?
Microsoft propose maintenant une nouvelle approche. Vous pouvez avoir à une pré-version de cette approche si vous choisissez de créer une librairie ASP.NET Core en ayant installé les outils de développement Web de la RC1 d’ASP.NET Core. Cette nouvelle approche se base sur ce qui est appelé .NET Standard Platform. Avec l’approche .NET Standard Platform, une librairie n’est plus une combinaison de monikers, mais un seul et unique moniker.
Ce moniker unique, est ensuite implémenté par un ensemble non fini de plateformes. Ainsi, si une nouvelle plate-forme fait son apparition, et qu’elle respecte une version de .NET Standard Platform, alors toutes les librairies compatibles avec cette version de .NET Standard Platform deviennent automatiquement compatibles avec cette plateforme.
En fait, le terme .NET Standard Platform est trompeur. Il ne faut pas le considérer en tant que plate-forme mais plutôt en tant que standard. Ce standard étant lui-même un ensemble de contrats. .NET 4.5, Windows 8 ou dnxcore50 sont autant de plateformes qui implémentent ou non une version spécifique du standard.
La notion de version du standard est très importante. Dans les principes de base de .NET Standard Platform, il est dit que chaque version V est toujours compatible avec les versions V+1. En d’autres termes, les librairies qui ciblent une version V de .NET Standard Platform peuvent également être exécutées par toutes les plateformes compatibles avec la version V de .NET Standard Platform, et avec toutes les versions supérieures. Cela permet d’élargir le spectre de diffusion d’une librairie, mais bien évidemment, la contre-partie est que le nombre d’APIs accessibles est d’autant plus limité que la version *V. de .NET Standard Platform est basse.
Jusqu’à présent, je n’ai pas encore mis de noms sur les différentes versions de .NET Standard Platform accessibles. C’est totalement volontaire, car je souhaite que vous vous concentriez plus sur les concepts de .NET Standard Platform plutôt que ce qui est concrètement accessible dès maintenant. En effet, les ingénieurs de Microsoft sont encore dans les premières phases de leur réflexion, il leur reste beaucoup de chemin à parcourir.
A titre d’exemple, les deux liens suivants correspondent à l’embryon de spécification de .NET Standard Platform à seulement quelques jours d’intervalle (le premier lien correspond au document le plus ancien) :
Entre ces deux versions, les noms des monikers, et la numérotation des versions de .NET Standard Platform ont changés. Si vous voulez vous essayer au développement d’une librairie compatible avec .NET Standard Platform, alors à l’heure où j’écris ces lignes, le premier document est celui qui devrait vous intéresser le plus. En effet, il correspond à ce qui est proposé par défaut avec les outils dev web d’ASP.NET Core RC1.
Les deux tableaux ci-dessous sont particulièrement intéressants. Tous deux présentent la compatibilité entre les versions de .NET Standard Platform et les différentes plateformes compatibles.
Le premier tableau correspond à la spécification initiale.
| Target Platform Name | Alias | |||||
|---|---|---|---|---|---|---|
| .NET Standard Platform | dotnet | 5.1 | 5.2 | 5.3 | 5.4 | 5.5 |
| .NET Framework | net | X | X | X | X | 4.6.X |
| X | X | X | 4.6 | |||
| X | X | 4.5.2 | ||||
| X | X | 4.5.1 | ||||
| X | 4.5 | |||||
| Universal Windows Plat. | uap | X | X | X | 10 | |
| Windows | win | X | X | 8.1 | ||
| X | 8.0 | |||||
| Windows Phone | wpa | X | X | 8.1 | ||
| X | 8.0 | |||||
| Windows Phone Silverlight | wp | 8.1 | ||||
| 8.0 | ||||||
| DNX Core | dnxcore | X | X | X | X | 5.0 |
| Mono / Xamarin Platforms | X | X | X | X | ||
| Mono | X | X |
Ce second tableau correspond à la spécification mise à jour.
| Target Platform Name | Alias | |||||
|---|---|---|---|---|---|---|
| .NET Standard Platform | netstandard | 1.0 | 1.1 | 1.2 | 1.3 | 1.4 |
| .NET Framework | net | X | X | X | X | 4.6.X |
| X | X | X | 4.6 | |||
| X | X | 4.5.2 | ||||
| X | X | 4.5.1 | ||||
| X | 4.5 | |||||
| Universal Windows Plat. | uap | X | X | X | 10 | |
| Windows | win | X | X | 8.1 | ||
| X | 8.0 | |||||
| Windows Phone | wpa | X | X | 8.1 | ||
| X | 8.0 | |||||
| Windows Phone Silverlight | wp | 8.1 | ||||
| 8.0 | ||||||
| DNX Core | dnxcore | X | X | X | X | 5.0 |
| Mono / Xamarin Platforms | X | X | X | X | ||
| Mono | X | X |
L’élément qui varie entre les deux tableaux est la première ligne. Son alias a été modifié (de dotnet vers netstandard) et l’intervalle des versions a également changé (de 5.1-5.5 a 1.0-1.4).
Comment lire ces tableaux ? C’est simple, les plateformes compatibles avec une version de .NET Standard Platform sont représentées par un indicateur de version dans une des cinq colonnes les plus à droite du tableau. Automatiquement, la colonne contenant l’indicateur de version correspond à la version de .NET Standard Platform minimale requise. Toutes les colonnes à droite de cette colonne (qui sont normalement vides et pas marquées d’un X) sont également compatibles du fait du principe de compatibilité ascendante.
Ainsi, si vous choisissez de cibler .NET Standard Platform dans sa version 5.4 (ou 1.3 selon la version de la spécification), votre application pourra uniquement être déployée sur une des plateformes suivantes :
- .NET 4.6 et les versions ultérieures ;
- UWP 10 ;
- DNX Core 5.0 ;
- Mono / Xamarin Platforms.
Cibler .NET Standard Platform
Faîtes le test, créez un nouveau projet de type librairie sous ASP.NET Core. Dans le fichier project.json, modifiez le noeud frameworks de la manière suivante.
"frameworks": {
"dotnet5.4": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-23516",
"System.Runtime": "4.0.21-beta-23516"
}
}
}
Créez ensuite une application web ASP.NET Core. Dans son fichier project.json, modifiez le noeud frameworks de la manière suivante. Notez qu’ici, j’ai fait le choix de ne cibler que DNX Core 5.0.
"frameworks": {
"dnxcore50": { }
}
Sans surprise, la restauration des paquets, et notamment de ma librairie personnalisée, se fait sans aucun problème.
A présent, retournez dans le fichier project.json de l’application web ASP.NET Core et modifiez le noeud frameworks de la façon suivante. Ici, j’ai fait le choix d’ajouter le framework .NET 4.6 comme cible potentielle.
"frameworks": {
"dnxcore50": { },
"net46": { }
}
A nouveau, sans surprise et conformément aux tableaux présentés plus tôt dans ce billet, la restauration se fait sans incident.
Maintenant, modifiez le noeud frameworks de la façon suivante. J’ai remplacé le framework .NET 4.6 par le framework .NET 4.5.
"frameworks": {
"dnxcore50": { },
"net45": { }
}
Cette fois-ci, la restauration échoue. En effet, le framework .NET 4.5 n’est pas une plate-forme compatible avec .NET Standard Platform dans sa version 5.4.
Le message d’erreur suivant apparaît lors de la restauration des paquets.
The dependency ClassLibrary1 1.2.0-main in project WebApplication3 does not support framework .NETFramework,Version=v4.5.
J’ai deux solutions envisageables :
- Je peux modifier la version de .NET Standard Platform ciblée par ma librairie. En utilisant, par exemple, le moniker dotnet5.2, la librairie devient alors compatible avec la plateforme framework .NET 4.5. Cependant, j’aurais alors accès à un nombre plus limité d’APIs.
- Je peux modifier la cible de mon application web, en ciblant le framework .NET 4.6 et en abandonnant le support du framework .NET 4.5.
Conclusion
Voilà. Mon objectif avec ce billet était de réussir à proposer une introduction assez simplifiée de .NET Standard Platform. La nombre de plateformes cibles pour nos applications a exlosé en quelques mois. Très bientôt, tous les développeurs .NET devront obligatoirement se poser des questions quant au multi-targeting de leurs librairies. L’approche proposée par les PCL jusqu’à présent était viable du fait du faible nombre de plateformes disponibles.
Mais le contexte a maintenant évolué et il fallait trouver une nouvelle approche, une alternative plus flexible. Celle proposée par Microsoft avec .NET Standard Platform est très intéressante et semble répondre aux derniers travers des PCL.
Si vous êtes un développeur .NET, je ne peux que vous conseiller de vous intéresser à la chose. .NET évolue, et le fait même que le framework .NET soit considéré comme une plate-forme, faisant partie d’un tout bien plus grand, est un changement de perspective qui mérite bien qu’une partie de votre temps consacré à la veille se porte maintenant sur .NET Standard Platform.
Je reviendrai sur le sujet dans un prochain billet en allant plus loin dans la technique, notamment en analysant les différents éléments qui caractérisent une plate-forme. Cela sera également l’occasion pour moi d’aborder la manière dont un lien peut être fait entre une plateforme et une version spécifique de .NET Standard Platform.