Ok, en tant que nouvel écosystème de développement .net, je suis un peu perdu dans les outils Core, les versions, etc.
Que sont les aperçus et comment sont-ils liés à la numérotation de la version principale?
Sur le référentiel github core de dotnet , nous pouvons voir sur certains outils disponibles dans différentes versions:
1.0.3 publié le 13/12/2016
- Mise en cache des frameworks et des pages WinRT / UWP: comment créer une nouvelle instance de page sur Navigate () et conserver l’instance de page sur GoBack ()
- Vue de grid ASP.NET et vue liste
- Qu’est-ce que ResolveAssemblyReference.cache?
- Devrais-je avoir un assemblage distinct pour les interfaces?
- LINQ to SQL et le modèle de référentiel
1.1 publié le 16/11/2016
1.1.0 Preview 1 publié le 24/10/2016
1.0.2 publié le 17/10/2016
1.0.1 publié le 13/09/2016
1.0.0 disponible le 27/06/2016 RC2 disponible le 16/05/2016 RC1 publié le 18/11/2015
Sur le référentiel CLI de dotnet (je comprends qu’il s’agit de créer des outils?), Nous voyons qu’ils parlent de preview4, mais dans les liens de téléchargement, tout est marqué d’aperçu 5. Et ils parlent de télécharger un programme d’installation .NET Core SDK l’installateur principal, donc une autre version, ou est-ce mal nommé et c’est en fait le CLI seulement? Ou le SDK inclut-il la CLI, dans quelle version alors?
Il vous donne un dotnet-win-x64.latest.exe qui semble installer .NET Core 1.0.1 Preview 5 …
Enfin, sur Azure, une console d’application Web vous donnera:
dotnet --version D:\home\site\wwwroot 1.0.0-preview3-004056
Quels sont les outils appropriés, dans quelle version correcte pour démarrer un nouveau projet et le déployer correctement sur Azure?
Vous confondez quelques concepts ici. Ce n’est pas parce qu’une version est sortie plus tard qu’elle a plus de fonctionnalités. .NET Core 1.0 est une version LTS et sera fourni avec des mises à jour pour 2 ou 3 ans iirc.
Ainsi, même après la publication de la version 1.1, il y aura une maintenance pour la version 1.0 qui corrigera les bogues ou les problèmes de sécurité. Cela a toujours été le cas dans le développement de logiciels, regardez Java. Lorsque Java 1.8 est sorti, il y avait encore des mises à jour pour Java 1.7.
Le .NET Core SDK contient les outils dotnet cli, utilisés pour restaurer les packages, générer, déployer et exécuter des applications .NET Core. Il contient également le runtime .NET Core, qui fournit les DLL du framework (comme la configuration de .NET Framework 4.x). ) dont vous avez besoin pour exécuter des applications portables.
Le runtime / SDK Core .NET est indépendant des outils CLI et peut également être obtenu via des packages nuget.
Les outils .NET Core pour Visual Studio 2015/2017 ne sont qu’un ensemble d’outils permettant à Visual Studio d’append un support aux nouveaux types de projets et de créer un pipeline.
Les outils .NET Core pour VS contiennent également le SDK / runtime.
Ce que vous devez exécuter sur Azure dépend de vos besoins et du type d’exécution installé sur les instances Azure App Service, car elles sont généralement un peu en retard sur les versions standard.
C’est-à-dire que si vous créez des applications autonomes, déployées avec l’environnement d’exécution .NET Core, vous pouvez simplement utiliser n’importe quelle version, car chaque application aura son propre runtime pouvant s’exécuter côte à côte.
Si vous souhaitez exécuter des applications portables (livrées sans les bibliothèques d’infrastructure .NET Core lorsqu’elles sont déployées), vous devez installer le bon environnement d’exécution sur Azure App Service (le blog Azure publie généralement lorsque de nouveaux temps d’exécution deviennent disponibles).
Toutes les autres dépendent de votre environnement de développement.
TL; DR: Si vous
ou
cli-tools et Visual Studio Tools ne sont pas encore terminés, donc en avant-première. Ils devraient aller avec RTM avec VS2017 et la nouvelle structure de projet basée sur MSBuild (en passant de fichiers xproj à csproj), mais cela n’affecte pas l’état de l’environnement d’exécution / SDK.