Aspnetcore: Discussion: ASP.NET Core 3.0 ne fonctionnera que sur .NET Core

Je pense que cela a beaucoup de sens dans la vue d'ensemble maintenant. Les deux .NET Core et ASP.NET Core existent depuis assez longtemps maintenant que les gens avaient déjà ou ont encore la possibilité d'y basculer, sans causer d'énormes problèmes (par rapport au moment où le support a été abandonné pour la première fois dans le passé avec 2.0) .

Cependant, je suis triste des implications pour certains composants d'ASP.NET Core qui peuvent actuellement exister en tant que dépendances séparées. Parce que cela signifiera probablement que les composants individuels abandonneront le support netstandard, nécessitant à la place netcoreapp3.0; et en particulier avec # 3756, ces composants seraient inutilisables en dehors d'un contexte ASP.NET Core.

Par exemple, des projets comme RazorLight seront alors effectivement forcés de supprimer .NET Framework et, plus important encore, la prise en charge de .NET Standard en général.

Cela va laisser beaucoup de gens qui ont vendu passer au nouveau modèle de programmation ASP.NET Core dans leur organisation pour rester sur une plate-forme prise en charge et activement développée dans le froid sur une plate-forme non prise en charge en moins de 3 ans (. NET Core 2.1 LTS).

Je ne sais pas quelles analyses vous avez utilisées pour justifier cette décision, mais pour l' exécution des applications ServiceStack ASP.NET Core sur le .NET Framework, nous voyons que le modèle web-corefx le plus populaire pour exécuter le projet ASP.NET Core sur le .NET Framework représente plus de 1/3 (33,8%) du partage du même modèle Web vide qui est notre modèle de projet le plus populaire pour une exécution sur .NET Core.

IMO 3 ans n'est pas assez de temps pour abandonner les clients qui ont commencé ou qui ont migré vers le nouveau modèle de programmation ASP.NET (pour échapper à la plate-forme ASP.NET Framework stagnante) pour découvrir maintenant que la plate-forme qu'ils ont vendue à leur organisation où déménager a été abandonnée.

Pour une raison quelconque, il y a des clients qui ne peuvent pas passer à .NET Core en raison de l'utilisation de dépendances .NET Framework uniquement, si MS ne souhaite pas maintenir la prise en charge de .NET Framework dans ASP.NET Core 3.0 à l'avenir IMO, vous devez étendre la prise en charge pour ASP.NET Core 2.1 sur .NET Framework sur une période prolongée comme 7 ans. Les migrations de systèmes de production existants peuvent prendre des années, depuis le démarrage de .NET Core, il est clair que ASP.NET Framework a stagné avec la position officielle selon laquelle ASP.NET Core est le futur modèle de programmation pour .NET, maintenant les mêmes clients commencez bientôt à découvrir que le nouveau modèle de programmation vers lequel ils ont déménagé / migré ne sera plus pris en charge dans quelques années. La meilleure façon de prendre en charge ces clients .NET existants est de prendre en charge .NET 2.1 pendant une période LTS supplémentaire, au moins pour les correctifs de sécurité (idéalement pour résoudre les bogues également).

"kill .NET Framework", épisode 2: même histoire, mêmes personnages : rofl:

Malheureusement, cela ne met en évidence qu'une chose: vous n'avez absolument pas réussi à faire de .NET Standard la voiture avant de l'écosystème .NET . Il ne bouge pas aussi vite qu'il le devrait et n'est rien de plus qu'un plus petit dénominateur commun qui est toujours mis à jour au tout dernier moment, lorsque toutes les plates-formes incluent (ou sont sur le point d'inclure) les nouvelles API.

C'est peut-être juste moi, mais je n'ai jamais compris pourquoi il n'a pas évolué aussi vite que netcoreapp (qui est le premier à obtenir les nouvelles API, par définition).

Vous êtes un auteur de packages NuGet et souhaitez-vous qu'ils utilisent les derniers éléments? Ciblez la version la plus récente de netstandard : bien sûr, au départ, seules les applications basées sur netcoreapp pourront les utiliser, mais éventuellement d'autres plates-formes - comme Xamarin, Mono ou .NET Framework - rattraperont leur retard et les gens pourront utiliser vos packages sans que vous ayez à changer quoi que ce soit. Voilà comment les choses devraient fonctionner.

Bien sûr, cela peut prendre un certain temps pour les plates-formes non-.NET Core comme .NET Framework pour rattraper car les versions sont plus rares et la barre de stabilité beaucoup plus élevée, mais même si cela prend 6, 12 ou même 18 mois, je ne le fais pas. Je pense que c'est un problème, car c'est ce que les gens veulent lorsqu'ils utilisent .NET Framework: un framework stable, pas une cible en mouvement rapide.

À mon humble avis, ce serait une bien meilleure approche de faire de la cible ASP.NET Core 3.0 un nouveau netstandard TFM exposant toutes les API .NET Core dont vous avez besoin. Une fois que vous êtes sûr que les nouvelles API sont suffisamment stables, rétroportez-les vers le .NET Framework afin qu'il soit compatible avec la dernière norme.

Je suis sûr que les gens préféreraient devoir attendre quelques mois avant de pouvoir déplacer leur application .NET Framework vers la dernière version d'ASP.NET Core plutôt que d'être bloqués à jamais sur une ancienne version avec un support très court de 3 ans.

Faites ce que vous avez promis: faites de .NET Framework un framework stable qui évolue plus lentement au lieu d'une impasse pour ceux qui vous ont fait confiance lors de la migration vers ASP.NET Core.

Je n'aime pas ça. Au début de .net core, Microsoft n'a pas choisi mono ou .net framework tant que plateforme multiplateforme, et vous avez dit qu'il y avait plusieurs environnements d'exécution .netstandard , maintenant il y a encore beaucoup de paquetages nuget qui ne prennent pas en charge .net core (raison moyenne). De nombreux développeurs laisseront behide dans l'ancien modèle de programmation asp.net core si asp.net core fonctionne uniquement sur .net core. alors .net standard n'existera que dans le nom (au moins pour le noyau asp.net, les gens commencent à construire des packages netcoreapp uniquement).
Peut-être qu'un jour, .net core peut remplacer le framework .net sur la fenêtre, mais qu'en est-il de mono, et d'autres plates-formes reposent sur mono (xamarin, unity3d).
et une autre raison pour laquelle je préfère parfois le framework .net est que le framework de partage de base .net est vraiment énorme, quelle est la taille de votre dossier C:/program file/dotnet si vous mettez à niveau votre application du .net core 2.0 au dernier .net core 2.1? Il y a un fichier GB dans mon dossier, et il augmente lorsque je mets à jour le runtime .net core. mais le framework .net remplacera simplement l'ancienne version.

Faites ce que vous avez promis: faites de .NET Framework un framework stable qui évolue plus lentement au lieu d'une impasse pour ceux qui vous ont fait confiance lors de la migration vers ASP.NET Core.

FWIW, ce serait la stratégie optimale, ma suggestion d'étendre le LTS est la barre minimale pour donner plus de temps aux clients existants qui ont été commercialisés de manière agressive pour migrer vers ASP.NET Core qui ont maintenant été abandonnés sur une future plate-forme non prise en charge avec cela annonce.

Le standard .net est donc une blague? J'espère que l'équipe mono va créer des dépôts aspnetcore et le renommer en aspnetmono, sinon je pourrais quitter la pile .net.

Je suppose que cela signifie qu'à mon travail, nous n'utiliserons jamais ASP.NET Core. Nous resterons à jamais chez ASP.NET, sans parler du portage d'une application vers Core, car cela impliquerait désormais encore plus de changements.

Bien sûr, si votre objectif est de n'avoir aucun changement, vous pouvez continuer à faire la même chose pour toujours. Là où je travaille, nous avons commencé à utiliser ASP.NET Core il y a quelques années, initialement fonctionnant sur .NET Framework. Au fil du temps, à mesure que la plate-forme .NET Core mûrissait et gagnait en fonctionnalités, nous avons basculé nos projets vers netcoreapp. Un ou deux projets plus anciens utilisent toujours ASP.NET, et nous n'avons pas l'intention de les réécrire - c'est du code fonctionnel. Mais pour les nouveautés, nous attendons avec impatience des fonctionnalités telles que Span.

Le changement peut être retardé, mais ce n'est pas quelque chose que vous pouvez ou devriez éviter pour toujours - la technologie _est_ change et le travail d'un développeur exigera toujours d'apprendre de nouvelles choses. Si vous utilisez ASP.NET Core sur .NET Framework aujourd'hui, il est peu probable qu'il vous faudra trois ans de travail pour le déplacer vers .NET Core.

Venez à .NET Core, l'eau est chaude ...

Pour une raison quelconque, il y a des clients qui ne peuvent pas passer à .NET Core en raison du fait de s'appuyer uniquement sur les dépendances .NET Framework ...

Plus sérieusement, vous pouvez utiliser les bibliothèques .NET 4.x sur .NET Core 2.0 depuis .NET Standard 2.0 ; bien qu'il soit possible qu'ils utilisent certaines fonctionnalités que .NET Core n'a pas; bien qu'il existe le pack de compatibilité Windows pour .NET Core qui comble beaucoup de ces trous et de nombreuses autres fonctionnalités sont prises en charge dans .NET Core 3.0, y compris l' interopérabilité COM et d'autres modèles d'application tels que WinForms et WPF, etc.

Tous les bloqueurs empêchant une application ASP.NET Core de migrer vers .NET Core à partir de .NET Framework doivent probablement être déclenchés dans

Pour Xamarin; Je peux me tromper, mais je suppose qu'il est peu probable que vous l'utilisiez pour exécuter un serveur Web sur iOS ou Android.

Pour les applications clientes Mono, le serveur Web peut manquer de processus et s'exécuter sur .NET Core pendant que l'interface utilisateur s'exécute en Mono. Kestrel n'a jamais été en mesure de fonctionner sur une plate-forme Big Endian qui supprime certaines des autres plates-formes de Mono bien que les saveurs BSD soient actuellement une lacune .NET Core.

Pour l'unité; les jeux font toutes sortes de choses étranges, alors peut-être que ce scénario n'est pas couvert; si le jeu utilisait le serveur Web dans le client; plutôt que sur un serveur ou hors de proc; quand .NET Core pourrait exécuter cette partie.

En dehors du modèle d'application ASP.NET Core; par exemple pour les bibliothèques .NET Standard est plus important car ASP.NET Core a toutes sortes de fonctionnalités utiles, Razor étant un exemple particulier.

Toutes les bibliothèques ne migrent pas uniquement vers .NET Core (par exemple, Microsoft.Extensions.* restent en tant que .NET Standard) et il serait probablement utile de fournir des scénarios spécifiques qui seraient impactés comme @daveaglick l' a fait en https: // github.com/aspnet/AspNetCore/issues/3757#issuecomment -434140416 afin qu'ils puissent être pris en considération; quant aux bibliothèques et / ou fonctionnalités spécifiques qui peuvent être maintenues disponibles sur .NET Standard plutôt que juste un nébuleux "tout".

ASP.NET Core entraîne beaucoup de changements et de nouvelles API dans .NET Core et je peux comprendre le désir d'utiliser ensuite ces fonctionnalités (puisque c'était l'un de leurs cas d'utilisation); sinon c'est un peu autodestructeur.

D'un autre côté, ce serait bien s'ils étaient également dans une version .NET Standard afin que les autres environnements d'exécution puissent ensuite prendre en charge ASP.NET Core 3.0 lorsqu'ils se déplacent pour l'implémenter. En réalité, ce ne serait pas bientôt (car .NET Standard 2.1 n'est pas encore finalisé et il faudrait une version au-delà de cela).

Peut-être que le modèle d'application ASP.NET Core reviendra à .NET Standard à une date ultérieure lorsque les choses auront rattrapé leur retard? Bien que cela puisse toujours aller trop vite pour le processus .NET Standard tel qu'il fonctionne actuellement?

@gulbanana et si votre core asp.net sur le framework .net en utilisant com? ou il existe un package nuget qui ne prend en charge que le framework .net?

Je crois qu'il n'a jamais été question de savoir si le déménagement devait être fait ou non, mais seulement quand.
La dernière fois que cela a provoqué une ~ discussion ~ shitstorm, l'écosystème n'était pas prêt à autoriser le portage d'applications existantes.
Maintenant, il existe les packages de compatibilité Windows et WinForms et WPF arrivent à .NET Core.

Je pense que les packages 2.1 existants pour .NET Framework fournissent un bon chemin de migration: migrer vers 2.1 sur netfx, puis sur .NET Core.

Ceci est similaire à AngularJS vs Angular: Migrez le code existant vers les composants (durs) dans la dernière version 1. *, puis passez à la dernière version Angular. C'est super difficile mais faisable.

Avec de nouvelles fonctionnalités intéressantes ajoutées à la fois à CoreCLR et mono (par exemple , les méthodes d'interface par s) qui ne parviendrait jamais à .NET Framework, il semble raisonnable de laisser .NET Framework derrière à un moment donné.
Cela ne signifie pas nécessairement «ne pas prendre en charge» .NET Framework, mais plutôt le laisser tel quel.

Il existe encore des sites qui utilisent ASP classique (pas ASP.NET, mais les choses vraiment anciennes). Il fonctionne toujours et est livré sous Windows, vous ne créeriez tout simplement pas de nouvelles applications avec.
Je pense que dans moins de 10 ans, ce sera peut-être le cas avec .NET Framework.

Je suis d'accord avec le support étendu demandé pour la version 2.1, mais j'aimerais que l'équipe surveille les téléchargements de packages 2.1 pour prendre une décision dans 2-3 ans s'ils ont besoin de le prendre en charge (= résoudre des problèmes de sécurité importants) pendant un peu un peu plus long.

@ John0King COM sera pris en charge dans .NET Core 3.0.

Aussi: nous avons des applications héritées utilisant des choses comme .NET Remoting.
Mais ce sont déjà des héritages.

Le monde fonctionne essentiellement sur du code hérité et continuera de le faire. C'est une décision commerciale de porter ou non quelque chose vers un élément "pris en charge" ou même "nouveau", mais d'ici là, comme le dit @dylanbeattie :

Oui, il vaut la peine de mentionner que la question de savoir si quelque chose est «pris en charge» n'est pas si pertinente - les anciennes applications n'ont pas besoin d'être portées vers un nouveau cadre simplement parce qu'elles sont disponibles. Les serveurs Web sont cependant un cas particulier en raison des menaces de sécurité. Une longue période de prise en charge des correctifs de sécurité pour le LTS aiderait les gens.

@gulbanana Cela ne fait qu'ajouter une barre plus élevée au portage des applications de System.Web vers ASP.NET Core, car vous devez changer le cadre Web, le cadre d'application sous-jacent, puis mettre à niveau ou échanger toutes les dépendances incompatibles (ce qui peut impliquer l'achat de nouvelles licences).

Si vous faisiez alors une analyse coûts / avantages, je ne suis pas sûr que ce serait dans l'intérêt d'ASP.NET Core.

Ceci est particulièrement applicable lorsque vous développez un logiciel sur la base d'un projet, et bien sûr, chaque projet est suffisamment serré sur le budget tel qu'il est, donc si une maintenance régulière est bien sûr possible, il est difficile de justifier le remplacement de l'ensemble du cadre sans avantage tangible apparent .

Si vous faisiez alors une analyse coûts / avantages, je ne suis pas sûr que ce serait dans l'intérêt d'ASP.NET Core.

Alors ... eh bien ... laissez-le? Si vous n'avez pas besoin de migrer vers ASP.NET Core, ne le faites pas.
Ne pas essayer de paraître sarcastique ou quoi que ce soit, mais s'il n'y a pas besoin de garder une application sur les «dernières choses», ne la portez pas. L'avantage est que .NET Framework / ASP.NET classic est toujours pris en charge et que votre application s'exécutera telle quelle.

Le portage est souvent inutile, je suis d'accord - ASP.NET vers ASP.NET Core est un grand changement, et une partie de ce changement est que Core se déplace plus rapidement (3.0 aura également des changements de rupture d'API, comme l'a fait 2.0). Ce problème de discussion concerne le changement netfx vers corefx, cependant, et pour la plupart des applications ASP.NET Core, ce n'est plus un grand changement,

Cela semble supprimer le point intermédiaire «ASP.NET Core sur .NET Framework» qui rendrait les migrations beaucoup plus progressives et plus faciles. Après cela, migrez un ASP.NET MVC / WebAPI / etc. L'application à ASP.NET Core sera un changement très important, modifiant à la fois le cadre Web et les environnements d'exécution sous-jacents en même temps.

Pour les grandes applications d'entreprise, je m'attends à ce que cela soit assez pénible. Mon équipe surveille cela de près depuis un an ou deux, mais:

• EntityFrameworkCore ne fait pas tout ce dont nous avons besoin, et c'est seulement maintenant avec .NET Core 3.0 qu'EntityFramework lui-même arrive à .NET Core. Combien de cela et sur quelles plates-formes il fonctionnera, je ne pense pas que cela ait été clairement communiqué, et je devrai probablement tester une version préliminaire pour voir.

• L'histoire d'OData semble toujours en suspens en termes d'applications à grande échelle. Il y a une quantité substantielle de (re) travail nécessaire pour passer d'OData 3 / System.Data.Services à OData 4 / WebAPI et au-delà. C'est quelque chose qui n'a pas été résolu depuis plusieurs années maintenant, et je ne suis honnêtement pas sûr qu'il le sera jamais.

De plus, nous devrons maintenant supprimer toutes les autres technologies non prises en charge (AppDomains, Remoting, etc.) _first_, au lieu de pouvoir faire ce travail en parallèle ou à un stade ultérieur.

De plus, nous devrons maintenant supprimer toutes les autres technologies non prises en charge (AppDomains, Remoting, etc.) d'abord, au lieu de pouvoir faire ce travail en parallèle ou à un stade ultérieur.

Pourquoi ne pouvez-vous pas d'abord migrer vers la version 2.1?

@davidfowl Nous pourrions probablement utiliser cela comme intermédiaire, à moins que nous ne rencontrions une nouvelle fonctionnalité dans 3.0 / 3.1 / etc. dont nous avons besoin pour migrer. Je n'ai pas encore fait une analyse complète, nous avons principalement été bloqués sur EF et OData jusqu'à présent.

Nouvelle fonctionnalité dans ASP.NET Core 2.1 qui est nécessaire pour migrer? Je voulais dire ASP.NET Core 2.1 sur .NET Framework.

Lorsque ce problème a été soulevé il y a quelques années, je me souviens m'être plaint qu'il était trop difficile de tout porter. Voici une citation d'un ancien commentaire github que j'ai fait à l'époque:

imaginez des applications Web qui utilisent Active Directory ou Office COM Automation, ou qui font des miniatures à l'aide d'une bibliothèque basée sur System.Drawing, ou qui partagent du code avec une application WPF

Ce qui est cool, c'est qu'à partir de .NET Core 3.0, tous ces scénarios sont pris en charge. Un énorme travail a été fait pour faciliter les choses.

@davidfowl moi aussi.

En théorie, il pourrait y avoir une fonctionnalité que nous utilisons dans ASP.NET/MVC/WebAPI qui n'est pas implémentée dans la version 2.1 mais qui arrive dans une version ultérieure. Dans ce cas, 2.1 ne serait pas un tremplin réalisable.

Je devrais faire une analyse plus approfondie cependant, pour voir s'il y a vraiment quelque chose de critique dont nous avons besoin qui ne soit pas dans 2.1.

@PinpointTownes

Malheureusement, cela ne met en évidence qu'une chose: vous n'avez absolument pas réussi à faire de .NET Standard la voiture avant de l'écosystème .NET . Il ne bouge pas aussi vite qu'il le devrait et n'est rien de plus qu'un plus petit dénominateur commun qui est toujours mis à jour au tout dernier moment, lorsque toutes les plates-formes incluent (ou sont sur le point d'inclure) les nouvelles API.

Vous n'avez pas tort, mais vous ignorez quelque peu les objectifs du .NET Standard. Le but de la norme n'a jamais été de stimuler l'innovation, mais de stimuler la convergence. Si vous l'abordez sous cet angle, c'est par conception une chose qui doit être à la traîne parce que nous devons réfléchir aux concepts qui peuvent être universels ou même devraient l'être. Si vous êtes curieux de savoir à quoi cela ressemble, je vous invite à jeter un coup d'œil aux 35+ PR que j'ai fusionnés au cours des trois dernières semaines après examen par tous les propriétaires de l'implémentation .NET.

Nous considérons .NET Core comme la plate-forme de pointe où l'innovation se produit. Nous avons construit plusieurs fonctionnalités qui nous permettent de gérer le taux de désabonnement et les risques qui en découlent, bien mieux que ce que le .NET Framework avait. Cependant, toutes les fonctionnalités importantes pour l'écosystème .NET ne font pas partie de l'expérience .NET Core. Par exemple, la compilation à l'avance est beaucoup plus importante sur Xamarin et Unity. Et lorsque nous prenons les fonctionnalités .NET Core et les ajoutons à la norme, nous devons prendre en compte leurs environnements d'exécution, leurs systèmes d'exploitation et leurs contraintes matérielles.

C'est peut-être juste moi, mais je n'ai jamais compris pourquoi il n'a pas évolué aussi vite que netcoreapp (qui est le premier à obtenir les nouvelles API, par définition).

La réalité est que «bouger rapidement et casser les choses» n'est pas quelque chose que tout notre public apprécie. C'est déjà assez grave si nous devons supprimer les API dans les versions majeures de .NET Core, mais c'est pratiquement impossible à faire avec le standard .NET. Nous devons donc avancer un peu plus lentement et n'inclure que des concepts que nous croyons suffisamment mûrs pour être ajoutés.

Faites ce que vous avez promis: faites de .NET Framework un framework stable qui évolue plus lentement au lieu d'une impasse pour ceux qui vous ont fait confiance lors de la migration vers ASP.NET Core.

Cela suppose toujours que .NET Framework obtiendra finalement toutes les fonctionnalités de .NET Core, mais avec un délai. Nous avons appris que ce n'est tout simplement pas réaliste. Nous pouvons soit décider de ne pas innover radicalement dans .NET Core, soit accepter la réalité technique selon laquelle une bonne partie des nouvelles fonctionnalités ne reviendra jamais vers .NET Framework. Nous pensons que nous servons au mieux nos clients pour préserver la valeur fondamentale de .NET Framework (une plate-forme de développement mature et riche) tout en permettant aux clients d'exploiter de nouvelles fonctionnalités sur .NET Core. À l'avenir, je m'attendrais à ce que nous soyons plus disposés à innover dans les domaines qui nécessitent des changements d'exécution, de bibliothèque et de langue, comme nous l'avons fait pour Span<T> . Bien que ces choses soient coûteuses, elles nous permettent également de changer la façon dont les gens peuvent écrire du code. Un bon exemple de ceci est l'implémentation par défaut des interfaces, la possibilité de créer du code générique impliquant l'arithmétique, la possibilité d'utiliser des éléments matériels intrinsèques, etc. .

Je pense qu'il est tout à fait logique que notre pile Web puisse exploiter ces capacités; et la seule façon de le faire est de supprimer la limitation pour ASP.NET Core à s'exécuter également sur .NET Framework. Gardez à l'esprit que la raison initiale pour laquelle nous avons fait fonctionner ASP.NET Core sur .NET Framework était que .NET Core n'avait tout simplement pas assez d'API. Sur .NET Core 3.0, nous aurons plus de 120k des API existantes . C'est plus de la moitié de l'ensemble du .NET Framework et inclut même WinForms et WPF. Oui, il manque encore un grand nombre d'API, mais nous avons fait d'énormes progrès dans la longue traîne. Bien que nous n'ayons jamais une parité de 100%, je m'attends à ce que nous comblions cet écart encore plus à l'avenir, sur la base des données des clients.

@ yaakov-h Je serais surpris si c'était le cas. Lorsque vous faites l'analyse, faites-le moi savoir.

Vous n'avez pas tort, mais vous ignorez quelque peu les objectifs du .NET Standard. Le but de la norme n'a jamais été de stimuler l'innovation, mais de stimuler la convergence.

Et vous vous dirigez exactement dans la direction opposée: abandonner .NET Standard pour ASP.NET Core car il ne se déplace pas assez rapidement, forçant les packages NuGet ciblant ASP.NET Core à l'abandonner également. Ne me faites pas penser que c'est la convergence, je ne suis pas si ignorant : rofl:

Si vous l'abordez sous cet angle, c'est par conception une chose qui doit être à la traîne parce que nous devons réfléchir aux concepts qui peuvent être universels ou même devraient l'être.

C'est un choix, pas un problème technique: rien ne vous empêche de déterminer si une API donnée doit être incluse dans une nouvelle version de .NET Standard lorsque vous l'examinez pour l'inclusion dans corefx / coreclr.

Si vous êtes curieux de savoir à quoi cela ressemble, je vous invite à jeter un coup d'œil aux 35+ PR que j'ai fusionnés au cours des trois dernières semaines après examen par tous les propriétaires de l'implémentation .NET.

Je ne dis pas que c'est une tâche facile et cela prouve mon point: vous attendez beaucoup trop pour créer de nouvelles versions netstandard et les rares fois où vous le faites, c'est un processus douloureux car il contient des tonnes de nouvelles API en même temps.

La réalité est que «bouger rapidement et casser les choses» n'est pas quelque chose que tout notre public apprécie.

Pourtant, c'est exactement comme cela que fonctionne chaque itération ASP.NET Core: elle est accompagnée de modifications (parfois massives) qui rendent les packages écrits pour une version incompatible avec les suivantes. Pourtant, vous ne nous donnez pas beaucoup d'options: mettre à jour ou rester sur les anciennes versions pour toujours, avec une politique de support qui n'a rien à voir avec ce que nous avions auparavant (ce n'est pas seulement ASP.NET/.NET, le cycle de vie de Windows est aussi plus court ces jours-ci).

À l'avenir, je m'attendrais à ce que nous soyons plus disposés à innover dans les domaines qui nécessitent des changements d'exécution, de bibliothèque et de langue, comme nous l'avons fait pour Span. Bien que ces choses soient coûteuses, elles nous permettent également de changer la façon dont les gens peuvent écrire du code. Un bon exemple de ceci est l'implémentation par défaut des interfaces, la possibilité de créer du code générique impliquant l'arithmétique, la possibilité d'utiliser des éléments matériels intrinsèques, etc. .

Qu'est-ce qui vous empêche d'introduire une nouvelle version côte à côte de .NET Framework (disons .NET Framework 5) qui inclut ces changements «risqués»? Encore une fois, ce n'est pas un problème technique.

Avez-vous une chance de promouvoir Microsoft.AspNetCore.Razor.Language et Microsoft.AspNetCore.Razor dehors de aspnet ou de le conserver sur netstandard wave? Même si razor est juste pour le HTML, il existe plusieurs bibliothèques qui l'utilisent pour les modèles de courrier et ce serait formidable si nous pouvions continuer à l'utiliser tel quel.

Ce mouvement montre un manque de support pour netstandard dans la feuille de route .NET, contrairement à ce qui a été dit auparavant. Si l'une des principales nouvelles bibliothèques abandonne netstandard, cela ne présage rien de bon pour son adoption.

Est-ce une décision que les développeurs .NET devraient désormais anticiper pour toutes les autres nouvelles bibliothèques développées par Microsoft en plein air? La communauté peut-elle obtenir une déclaration plus officielle sur l'avenir de netstandard et son adoption?

@terrajobst Je comprends tout à fait que vous dites ne pas ajouter à .netstandard ces API qui ne semblent pas prêtes à couvrir toutes les plates-formes (et ne le seront probablement jamais). Cependant, cela ne vous a pas empêché (MS) d'introduire netstandard2.0 lorsque, par exemple, UWP n'était pas prêt à le prendre en charge. Si je comprends bien, il a fallu un effort notable pour ajouter ce soutien quelque temps plus tard, mais vous l'avez fait. Était-ce en quelque sorte une histoire différente?

Et vous vous dirigez exactement dans la direction opposée: abandonner .NET Standard pour ASP.NET Core car il ne se déplace pas assez rapidement.

ASP.NET Core n'a de sens que sur .NET Framework et .NET Core, mais le .NET Standard doit être implémenté par tout le monde. Cela n'a tout simplement pas de sens, par exemple, de faire en sorte que Xamarin / Unity fournisse des API qui sont principalement utilisées par une pile Web de serveurs.

C'est un choix, pas un problème technique: rien ne vous empêche de déterminer si une API donnée doit être incluse dans une nouvelle version de .NET Standard lorsque vous l'examinez pour l'inclusion dans corefx / coreclr.

C'est ce que nous avons fait à l'époque du .NET Core v1. Nous avons découplé la norme de .NET Core avec la v2. Alors oui, c'est un choix mais ce n'était pas arbitraire. L'objectif était de pouvoir évoluer plus rapidement avec .NET Core. Il faut simplement plus de temps pour examiner le fonctionnement des fonctionnalités dans le contexte de N autres environnements d'exécution qu'un seul.

c'est un processus douloureux car il s'accompagne de tonnes de nouvelles API en même temps.

Non, c'est un processus pénible car vous devez revoir la conception avec plusieurs implémenteurs et plusieurs environnements d'exécution différents. Cependant, le faire après coup, agrégé et groupé est beaucoup moins cher que d'avoir à coordonner cela au fur et à mesure. Le repo CoreFx est un repo à volume élevé. Il est beaucoup plus facile pour Xamarin et Unity d'examiner les fonctionnalités regroupées que de boire du firehose et de s'abonner à toutes les discussions d'API sur CoreFx.

Pourtant, c'est exactement comme cela que fonctionne chaque itération ASP.NET Core: elle est accompagnée de modifications (parfois massives) qui rendent les packages écrits pour une version incompatible avec les suivantes.

Et parce que vous n'aimez pas cela, vous voulez l'imposer à tout le monde en faisant correspondre .NET Standard .NET Core? Désolé, mais cet argument n'a aucun sens pour moi.

Qu'est-ce qui vous empêche d'introduire une nouvelle version côte à côte de .NET Framework (disons .NET Framework 5) qui inclut ces changements «risqués»? Encore une fois, ce n'est pas un problème technique.

Qu'est-ce qui vous fait penser que ce n'est pas un problème technique? L'expédition de versions côte à côte de .NET Framework n'est pas une solution viable. Tout d'abord, c'est assez cher en raison du fait qu'il s'agit d'un composant du système d'exploitation et qu'il doit donc être réparé. Vous n'avez aucune idée de la complexité de notre stratégie de branchement / maintenance / correctif pour .NET Framework 3.5 et 4.x. L'ajout d'un troisième est presque irréalisable. Deuxièmement, cela comporte également des risques, car nous devons apporter des modifications à l'activation afin de sélectionner le bon moteur d'exécution pour des éléments tels que les composants gérés activés par COM. Et cela soulève la question de savoir si oui ou non nous prenons en charge côte à côte in-proc et avec combien de combinaisons. Ce n'est pas une tâche simple et non plus sans risque.

Ne me fais pas penser que c'est la convergence

@PinpointTownes C'est la convergence ... sur .NET Core 😉

Cela n'a tout simplement pas de sens, par exemple, de faire en sorte que Xamarin / Unity fournisse des API qui sont principalement utilisées par une pile Web de serveurs.

Il y a des gens qui aimeraient utiliser ASP.NET Core non seulement sur .NET Core, mais aussi sur UWP, alors pourquoi pas également sur Xamarin? https://aspnet.uservoice.com/forums/41199-general-asp-net/suggestions/32626766-support-for-asp-net-core-running-on-uwp-as-windows

Il y a une différence entre quelque chose qui n'a aucun sens - pour vous - et quelque chose que vous ne voulez pas soutenir.

Le repo CoreFx est un repo à volume élevé. Il est beaucoup plus facile pour Xamarin et Unity d'examiner les fonctionnalités regroupées que de boire du firehose et de s'abonner à toutes les discussions d'API sur CoreFx.

Ai-je suggéré une approche aussi extrême? Je suis sûr qu'il y a un compromis que vous pourriez trouver, comme discuter des nouvelles API standard peu de temps (c'est-à-dire quelques semaines) après leur introduction dans .NET Core, une fois que la poussière s'est un peu calmée.

Et parce que vous n'aimez pas cela, vous voulez l'imposer à tout le monde en faisant correspondre .NET Standard .NET Core? Désolé, mais cet argument n'a aucun sens pour moi.

Vous supposez que je n'aime pas ça mais vous vous trompez: j'aime les choses rapides - même si en tant que mainteneur de 60 packages NuGet, c'est parfois assez pénible. Ce que je n'aime pas, c'est forcer tout le monde à avancer à la même vitesse, abandonner les gens au milieu de la route parce qu'ils ne peuvent pas suivre.

Je ne sais pas comment rendre .NET Standard aussi rapide que .NET Core peut être considéré comme une punition: rien ne vous oblige à cibler le dernier netstandard TFM. Vous ne le ferez que si vous avez besoin du dernier ensemble d'API. Si vous n'en avez pas besoin, ciblez une version plus ancienne afin que vos packages puissent être utilisés par un ensemble plus large de plates-formes.

Du point de vue du développeur moyen, c'est une victoire totale: vous pouvez écrire des packages à l'aide des dernières API brillantes qui peuvent être utilisées par le dernier runtime .NET Core. Lorsque les autres plates-formes rattrapent leur retard, vos packages peuvent également y être utilisés: vous n'avez pas besoin d'utiliser le multi-ciblage ou de republier les packages.

Tout d'abord, c'est assez cher en raison du fait qu'il s'agit d'un composant du système d'exploitation et qu'il doit donc être réparé. Vous n'avez aucune idée de la complexité de notre stratégie de branchement / maintenance / correctif pour .NET Framework 3.5 et 4.x. L'ajout d'un troisième est presque irréalisable.

Je peux certainement imaginer que ce n'est pas idéal pour vous, tout comme la suppression de la prise en charge de .NET Framework pour ASP.NET Core 3.0 ne sera pas idéale pour les personnes qui ne peuvent pas passer à .NET Core. Mais ai-je totalement tort de penser que vous - Microsoft - avez beaucoup plus de ressources pour faire face à cela qu'une entreprise moyenne ne doit passer à .NET Core? (Je ne parle même pas des dépendances externes que vous ne possédez pas et ne contrôlez pas).

Deuxièmement, cela comporte également des risques, car nous devons apporter des modifications à l'activation afin de sélectionner le bon moteur d'exécution pour des éléments tels que les composants gérés activés par COM. Et cela soulève la question de savoir si oui ou non nous prenons en charge côte à côte in-proc et avec combien de combinaisons. Ce n'est pas une tâche simple et non plus sans risque.

Bien sûr, ce n'est pas facile. Et c'est risqué. Mais c'est ce qu'indiquent les versions majeures: il y a un risque que les choses se cassent. Maintenant, entre être obligé de rester indéfiniment sur ASP.NET Core 2.2 et prendre le risque de passer à .NET Framework 5 pour utiliser ASP.NET Core 3.0, que pensez-vous que les gens opteraient pour?

Mais ai-je totalement tort de penser que vous - Microsoft - avez beaucoup plus de ressources pour faire face à cela qu'une entreprise moyenne ne doit passer à .NET Core?

D'après mon expérience, les gens surestiment constamment le nombre de ressources dont nous disposons et la quantité de travail que nous avons à faire pour soutenir seul le statu quo.

Mais dans ce cas, ce n'est même pas une question de ressources. Nous aurions pu simplement ouvrir .NET Framework, puis tous les PR iraient directement à .NET Framework. Cela a à voir avec la complexité de la machine et les risques de compatibilité. Il s'agit d'un cadre centralisé et même les versions côte à côte partagent un ensemble commun de ressources, comme l'activation. Il nous a été prouvé à maintes reprises que nous ne pouvons que désigner des personnes intelligentes pour que cela se déroule correctement.

Maintenant, entre être obligé de rester indéfiniment sur ASP.NET Core 2.2 et prendre le risque de passer à .NET Framework 5 pour utiliser ASP.NET Core 3.0, que pensez-vous que les gens opteraient pour?

À mon avis, il est beaucoup plus pratique de repousser les limites des API prises en charge sur .NET Core pour permettre à plus de personnes de migrer en douceur vers .NET Core que d'essayer de rétroporter les fonctionnalités .NET Core vers .NET Framework. Tout ce que nous pouvons y faire, c'est causer du chagrin. Gardez à l'esprit que les versions côte à côte s'accompagnent d'autres défis, tels que l'obtention par l'informatique de vous permettre de l'installer, de l'enchaîner dans des installateurs ou d'attendre que votre hébergeur vous fournisse des machines, etc.

Cela s'applique-t-il à toutes les parties d'ASP.NET Core ou est-ce que certaines parties utiles et généralement réutilisables (comme Microsoft.AspNetCore.Http.Extensions ) resteront sur .NET Standard?

@andriysavin

@terrajobst Je comprends tout à fait que vous dites ne pas ajouter à .netstandard ces API qui ne semblent pas prêtes à couvrir toutes les plates-formes (et ne le seront probablement jamais). Cependant, cela ne vous a pas empêché (MS) d'introduire netstandard2.0 lorsque, par exemple, UWP n'était pas prêt à le prendre en charge. Si je comprends bien, il a fallu un effort notable pour ajouter ce soutien quelque temps plus tard, mais vous l'avez fait. Était-ce en quelque sorte une histoire différente?

Oui. .NET Standard 2.0 n'avait aucune nouvelle API nette. Il a été défini comme l'intersection de .NET Framework et Xamarin. Quel que soit le delta, nous en avons simplement besoin pour arriver à une barre de compatibilité raisonnable avec le code existant. Le seul travail était dans UWP et .NET Core. Et ces bases de code ont été initialement conçues pour être une réinitialisation moderne de .NET, que nous avons appris à ne pas être viable. Étant donné que les API / technologies à ajouter étaient en grande partie matures et prises en charge dans des environnements contraints (Xamarin iOS), la complexité était faible - juste une tonne de travail de portage.

Mais maintenant, nous parlons d'ajouter de nouvelles capacités et concepts et c'est une bête différente à conduire.

D'après mon expérience, les gens surestiment constamment le nombre de ressources dont nous disposons et la quantité de travail que nous avons à faire pour soutenir seul le statu quo.

D'après mon expérience, les Microsoft surestiment constamment le nombre de ressources dont nous disposons et la quantité de travail que nous avons à faire pour soutenir le statu quo seul. Votre argument fonctionne vraiment dans les deux sens: sweat_smile:

À mon avis, il est beaucoup plus pratique de repousser les limites des API prises en charge sur .NET Core pour permettre à plus de personnes de migrer en douceur vers .NET Core que d'essayer de rétroporter les fonctionnalités .NET Core vers .NET Framework.

Soyons clairs: je suis tout à fait pour cela , mais cela ne fonctionnera pas tant que .NET Core ne rattrapera pas et implémentera la plupart / toutes les fonctionnalités de .NET Framework. Jusqu'à ce que cela se produise, vous verrez toujours des personnes bloquées par une fonctionnalité manquante ou une API manquante. Il y a tellement de choses manquantes qu'il n'est pas raisonnable de penser que les grandes applications monolithiques héritées pourront passer à .NET Core sans rencontrer de problèmes.

Je comprends parfaitement vos préoccupations. Mais en fin de compte, ce qui vous facilite la vie a une chance de rendre la nôtre plus douloureuse: ne pas prendre en charge .NET Framework va être un PITA pour nous.

Je comprends parfaitement vos préoccupations. Mais en fin de compte, ce qui vous facilite la vie a une chance de rendre la nôtre plus douloureuse: ne pas prendre en charge .NET Framework va être un PITA pour nous.

Cette partie que je comprends. Mais l'alternative ne serait pas plus de fonctionnalités dans .NET Framework mais simplement un ASP.NET Core moins puissant.

Nous avons essayé de co-faire évoluer .NET Framework et .NET Core au cours des dernières années. Ce n'est pas comme si nous essayions d'éviter le travail. J'ai personnellement passé des milliards d'heures à parler à nos ingénieurs d'exécution pour essayer de résoudre, par exemple, le cauchemar de la redirection de liaison. Ou la prise en charge cassée de .NET Standard 2.0 dans 4.6.1. Nous avons essayé. Ce n'est pas une question de volonté, c'est une question de praticité.

cela ne fonctionnera pas tant que .NET Core ne rattrapera pas et implémentera la plupart / toutes les fonctionnalités de .NET Framework

D'après mon expérience, la disponibilité de certaines API n'est même pas si pertinente. Ce qui compte le plus dans les environnements d'entreprise, c'est la complexité du support et du déploiement. Et «pris en charge, expédié et mis à jour automatiquement avec le système d'exploitation» est beaucoup plus attrayant que le support de 3 ans que nous obtenons des versions .NET Core LTS et le déploiement capricieux qu'il implique encore actuellement. Et soyons honnêtes ici: il n'y a toujours pas d'outils stables pour .NET Core et ASP.NET Core.Je peux affirmer avec confiance que ce sera toujours le statu quo dans un an. Nous avons eu des changements avec chaque version et qui sait si la nouvelle référence de cadre avec 3.0 sera la bonne solution. C'est donc sans aucun doute un énorme problème lorsque vous traitez avec des entreprises où vous ne pouvez pas simplement mettre à jour les choses ou le faire comme il se doit; généralement, ils veulent que cela se fasse comme ils le font depuis plus de 5 ans. Ils sont gâtés par le cadre et tout ce qui n'est pas aussi confortable pour eux est presque un spectacle.

Mais l'alternative ne serait pas plus de fonctionnalités dans .NET Framework mais simplement un ASP.NET Core moins puissant.

C'est à peu près ce que j'ai suggéré l'année dernière: les packages ASP.NET Core qui fonctionnent toujours sur .NET Framework (par exemple en ciblant netstandard20 et netcoreapp30 ) mais offrent un ensemble de fonctionnalités plus limité, avec beaucoup moins performance intéressante. Parfois, ce que les gens veulent, ce sont des choses qui fonctionnent. Pas les nouvelles choses brillantes. Pas le truc super rapide.

Nous avons essayé de co-faire évoluer .NET Framework et .NET Core au cours des dernières années. Ce n'est pas comme si nous essayions d'éviter le travail. J'ai personnellement passé des milliards d'heures à parler à nos ingénieurs d'exécution pour essayer de résoudre, par exemple, le cauchemar de la redirection de liaison. Ou la prise en charge cassée de .NET Standard 2.0 dans 4.6.1. Nous avons essayé. Ce n'est pas une question de volonté, c'est une question de praticité.

Nous ne sommes clairement pas d'accord sur tout mais il va sans dire que je suis très impressionné par ce que vous avez fait (oui, même si des choses comme le hoquet HttpClient étaient assez pénibles à gérer).

Je suis vraiment désolé d'être ce type: sweat_smile:

Jusqu'à présent, sur le front d'ASP.NET Core, j'ai vu Razor apparaître comme quelque chose de concret que les gens aimeraient être disponible en dehors d'ASP.NET Core en général. Je pense que c'est raisonnable et nous devrions identifier plus de domaines comme celui-là (ce sera une discussion plus utile). ASP.NET Core 2.1 et 2.2 prendront toujours en charge le framework .NET, mais je ne pense pas qu'il soit raisonnable de prendre en charge .NET Framework pour toujours.

@terrajobst

Un bon exemple de ceci est les implémentations par défaut des interfaces, ... Et ces fonctionnalités sont probablement exactement du type que nous n'allons pas rétroporter vers .NET Framework en raison du risque.

Et avec cette déclaration est mort DIM. C'est tout l'intérêt de l'évolution de l'héritage. Si cela ne s'applique pas à l'héritage et ne peut même pas s'appliquer aux bibliothèques qui tentent de relier l'héritage et le nouveau, cela n'aide personne.

Jusqu'à présent, sur le front d'ASP.NET Core, j'ai vu Razor apparaître comme quelque chose de concret que les gens aimeraient être disponible en dehors d'ASP.NET Core en général.

Vous pouvez ajouter le package Microsoft.Owin.Security.Interop backcompat ', ASP.NET Core Data Protection et les dépendances sous -

C'est à peu près ce que j'ai suggéré l'année dernière: les packages ASP.NET Core qui fonctionnent toujours sur .NET Framework (par exemple en ciblant netstandard20 et netcoreapp30 ) mais offrent un ensemble de fonctionnalités plus limité, avec beaucoup moins performance intéressante. Parfois, ce que les gens veulent, ce sont des choses qui fonctionnent. Pas les nouvelles choses brillantes. Pas le truc super rapide.

Nous en avons également discuté. Le défi ici est que nous ne pouvons pas encapsuler cela entièrement car certaines des API et fonctionnalités de la plate-forme sous-jacente devront se retrouver dans l'API publique. Cela signifie que les bibliothèques s'intégrant dans le middleware d'ASP.NET Core devraient également fournir plusieurs implémentations. Mais pire, cela pourrait même ne pas être possible sans créer un schisme car le type d'échange public pourrait être de base uniquement, ce qui créerait deux versions d'ASP.NET Core qui ne sont plus compatibles.

@HaloFour

Et avec cette déclaration est mort DIM. Le point entier de l'évolution de l'héritage. Si cela ne s'applique pas à l'héritage et ne peut même pas s'appliquer aux bibliothèques qui tentent de relier l'héritage et le nouveau, cela n'aide personne.

Je pense que vous confondez le code hérité avec les installations existantes . Même si nous devions porter DIM vers .NET Framework, vous devrez toujours mettre à niveau vers une version plus récente pour utiliser la fonctionnalité. Bien qu'il s'agisse probablement d'une fonctionnalité réservée à .NET Core, elle nous permet toujours de faire évoluer .NET Core tout en étant capable de consommer du code compilé avec .NET Framework.

@terrajobst Vous continuez à mentionner Unity. Ont-ils leur propre implémentation CLR? J'avais l'impression qu'ils utilisent Mono.

Unity a plusieurs implémentations .NET, y compris leur propre version AOT non mono, IL2CPP. Leur bibliothèque de classes et les API prises en charge diffèrent également du Mono standard.

@terrajobst

Je pense que vous confondez le code hérité avec les installations existantes.

Il n'y a pas beaucoup de différence en ce qui concerne les applications «héritées» qui sont toujours activement maintenues et développées. Il existe une énorme différence entre la mise à niveau du framework et la migration vers .NET Core.

Bien qu'il s'agisse probablement d'une fonctionnalité réservée à .NET Core, elle nous permet toujours de faire évoluer .NET Core tout en étant capable de consommer du code compilé avec .NET Framework.

À quelle fin? Aucune de ces API «évoluées» dans .NET Core ne sera jamais applicable à .NET Standard. Et aucun rédacteur de bibliothèque n'y touchera étant donné que cela créera une divergence incompatible dans leurs propres API.

Je suis d'accord avec @HaloFour. Les seules personnes qui pourront utiliser DIM sont les auteurs de bibliothèques ciblant uniquement .NET Core ... donc essentiellement corefx et aspnetcore. Je ne peux pas imaginer que quelqu'un d'autre s'en approche.

Les seules personnes qui pourront utiliser DIM sont les auteurs de bibliothèques ciblant uniquement .NET Core ... donc essentiellement corefx et aspnetcore.

Eh bien, une autre façon de formuler serait que la seule plate-forme sur laquelle vous ne pouvez pas l'utiliser sera .NET Framework alors que vous le pouvez sur .NET Core, Xamarin, Mono et Unity.

Je ne peux pas imaginer que quelqu'un d'autre s'en approche.

J'imagine que des fonctionnalités comme celle-ci auront un modèle d'adoption du bâton de hockey dans les bibliothèques, ce qui est logique. En fin de compte, les auteurs de bibliothèques considéreront toujours la portée par rapport à l'ensemble de fonctionnalités. Pour les applications, il est plus facile de décider, car vous connaissez (et contrôlez souvent) votre environnement cible.

@ yaakov-h

Cela s'applique-t-il à toutes les parties d'ASP.NET Core ...

La liste provisoire de ce qui arrive à quel paquet est ici: https://github.com/aspnet/AspNetCore/issues/3756

@terrajobst Je pensais que les implémentations d'interface par défaut allaient être une fonctionnalité de langage de C #. En disant que .NET Framework ne le prend pas en charge, vous dites pratiquement que .Net Framework sera à jamais bloqué avec la version C # 7.3 ou tout au plus la suivante. Cette divergence n'est pas quelque chose que quiconque aimerait se produire dans l'écosystème.

Nous exécutons quelques charges de travail .NET Core, mais également des projets .NET FX pluriannuels.

La mise à niveau vers .NET Core (même sur .NET Framework pour commencer) en toute sécurité est une tâche très importante.

Existe-t-il des plans pour que Microsoft publie des outils pour aider à «mettre à niveau» des projets d'au moins ASP.NET sur .NET FX vers ASP.NET Core vers .NET FX?

Il y a des articles MSDN sur la création de nouveaux projets VS, l'importation de vues et le réaménagement de projets, mais il y a tellement de choses héritées (Global asax, routing, ....) que j'aurais aimé qu'il y ait un endroit central qui documente l'ancienne et la nouvelle façon d'aider tout porter.

Qu'est-ce qui vous empêche d'introduire une nouvelle version côte à côte de .NET Framework (disons .NET Framework 5) qui inclut ces changements «risqués»?

À ce stade, y a-t-il un avantage à ne pas être .NET Core 3.0? Son déjà côte à côte et a les changements «risqués». Le prochain ensemble de fonctionnalités pour .NET Core aurait-il alors besoin d'un .NET Framework 6, etc.?

Avec les API déjà dans .NET Core 2.0 et le nouvel ensemble de fonctionnalités à venir pour .NET Core 3.0 .NET Core ne remplit-il pas le ".NET Framework 5" avec Framework 4.x étant la version LTS extrêmement longue?

À une supposition; À ce stade, il serait plus difficile de couvrir les lacunes spécifiques identifiées de .NET Core 3.0 par rapport à .NET Framework 4.x plutôt que de modifier .NET Framework pour qu'il se comporte comme .NET Core.

Suggestion pratique: y a-t-il une chance qu'ASP.NET Core 2.2 devienne LTS avec une durée de prise en charge étendue au-dessus des 3 années courantes?

Je suis sûr que cela satisferait ceux qui doivent s'en tenir au cadre complet pour le moment, tout en leur donnant (1) suffisamment de temps pour réellement migrer vers .NET Core et (2) suffisamment de motivation pour migrer d'ASP.NET MVC vers ASP .NET Core (lorsqu'ils ne peuvent pas passer à .NET Core _yet_).

Je ne pense toujours pas que ce soit clair, est-ce qu'ASP.NET Core sur .NET Framework suit .NET Core 2.1 LTS ou suit-il le cycle de support de .NET Framework v4.6.1 + (c'est-à-dire depuis qu'il fonctionne sur .NET FX) où il est soutenu dans un avenir prévisible?

@mythz ASP.NET Core est couvert par le cycle de vie de la prise en charge de .NET Core , quelle que soit la plateforme sur laquelle vous l'exécutez.

Je pense que la meilleure solution ici serait de maintenir la norme .net à jour au moins pour au moins 3.0, 4.0 et 5.0 et de communiquer en fait qu'à un moment donné, le framework .net sera complètement migré vers .net core.
tout le reste est à moitié cuit.

Avez-vous des clients qui paient déjà pour le support LTS aujourd'hui? (Juste une question approfondie). Combien de temps est assez de temps?

@terrajobst Il semble que le vrai problème est que netstandard est monolithique. Il semble que nous n'avons pas besoin de netstandard mais d'ensembles d'API versionnés à la place. Ce sera également le TFM, par exemple base2.0 + span serait deux ensembles d'API.

Vous pouvez ensuite faire évoluer la norme en fonction des ensembles d'API et éventuellement implémenter uniquement certains ensembles d'API dans le cadre complet. (Cela faciliterait également l'implémentation de netstandard pour d'autres plates-formes, car certains ensembles d'API peuvent être laissés de côté).

Avec les ensembles d'API en place, une version distincte d'ASP.NET Core serait créée pour les cibles moins prenant en charge comme le framework complet.

@Sebazzz c'est un sujet extrêmement étrange. Ne pouvons-nous pas faire dérailler ce fil avec des tentatives de reconcevoir netstandard? Vous pouvez déposer un problème sur dotnet / standard pour cela, mais je vais vous dire que cette idée a déjà été proposée et rejetée.

@davidfowl Je ne pense pas du tout que ce soit "étrange" ou "déraillant". Cela ressemble exactement à ce dont nous avons besoin, bien qu'un peu moins précis que la façon dont il l'a proposé. Si le problème avec tout cela est que nous finirions par devoir associer tous ces éléments de serveur Web dans des implémentations telles que Xamarin et Unity qui ne se soucient pas des serveurs Web, alors IMO crée un groupe d'API ".NET Web Server Standard" distinct serait la solution idéale.

@Sebazzz @masonwheeler

@terrajobst Il semble que le vrai problème est que netstandard est monolithique. Il semble que nous n'avons pas besoin de netstandard mais d'ensembles d'API versionnés à la place. Ce sera également le TFM, par exemple base2.0 + span serait deux ensembles d'API.

Nous avons essayé cela de différentes manières (profils, PCL, contrats lâches, puis ensembles de contrats versionnés qui sont devenus .NET Standard 1.x). Il est trop difficile d'outils et de compréhension des règles de compatibilité au fil du temps (lorsque les versions des plates-formes et les ensembles d'API évoluent). Le standard .NET tel qu'il est aujourd'hui est le plus proche que nous ayons jamais été d'un modèle viable. Bien que pas parfait, c'est au moins quelque chose que je peux expliquer en quelques minutes et ne pas faire exploser la tête des gens.

Je suis heureux de discuter de .NET Standard plus en détail, mais je suis d'accord avec @davidfowl pour https://github.com/dotnet/standard.

Edit J'ai marqué nos commentaires .NET Standard comme hors sujet.

@ Shayan-To

@terrajobst Je pensais que les implémentations d'interface par défaut allaient être une fonctionnalité de langage de C #. En disant que .NET Framework ne le prend pas en charge, vous dites pratiquement que .Net Framework sera à jamais bloqué avec la version C # 7.3 ou tout au plus la suivante. Cette divergence n'est pas quelque chose que quiconque aimerait se produire dans l'écosystème.

C'est une fonctionnalité qui nécessite des changements de langue ainsi que des changements d'exécution. C'est similaire aux génériques car cela change les règles du système de types. De manière générale, C # ne sait pas pour quel framework vous compilez (il reçoit juste un ensemble d'assemblys de référence qui décrivent les API que le framework offre). Toute fonctionnalité C # qui ne nécessite pas de modifications d'API (par exemple, l'opérateur de fusion nul ?. ou _ pour supprimer les expressions) sera prise en charge. En cela, il est identique à la façon dont le compilateur a toujours fonctionné lorsque vous avez utilisé la dernière version du compilateur et du langage et ciblé une ancienne version du .NET Framework qui ne dispose pas des API correspondantes. Par exemple, async / await ne fonctionnera pas si vous ciblez .NET Framework 3.5 ou 4.0 - vous devez être sur 4.5 ou plus pour utiliser Task .

Mec, je ressens pour vous les gars .. Passer à fond vers le noyau .net est, à mon avis, la bonne chose à faire à long terme et je préfère le rythme plus élevé de l'innovation que cela fournira.

Cependant les gens seront bouleversés à ce sujet. Une partie considérable de cela est la communication. Lorsque le LTS 2.1 3 ans a été annoncé, les utilisateurs du fullfx s'attendaient à pouvoir passer à la version 3.0 tout en continuant à utiliser le fullfx, ils auront vendu le core asp.net à leurs employeurs et clients mettant leur propre réputation en jeu, et maintenant, ils auront l'impression que le tapis a été retiré sous eux. Ce qu'ils ont vendu comme solution à long terme, l'avenir d'asp.net, est maintenant (perceptivement) plafonné à 3 ans de support

Peu importe qu'il soit plus facile de migrer maintenant, changer de plate-forme sera toujours un risque, et ce sera un risque et un effort de développement auquel ces personnes ne s'attendaient pas, ne prévoyaient pas ou ne budgétiseraient pas.

La plupart des développeurs _ voudront_ passer à .net core 3, mais en plus d'avoir potentiellement des dépendances, ils ne peuvent pas changer (ou impliquer un changement de risque), ils doivent maintenant lancer une migration _à nouveau_ et promettre que _cette fois_ ce sera un investissement à long terme. . Cela peut être une vente difficile, mais ils se sentiront obligés de le faire en raison du cycle de support de 3 ans.

Encore une fois, je suis pour abandonner le fullfx, mais je pense vraiment que vous devriez envisager d'étendre le LTS pour la dernière version qui le supporte de manière considérable. Communiquer également très clairement, comme dans les blogs, les conférences / sessions, etc., quelles parties resteront standard et comment les gens encore sur 2.1 / full framework peuvent encore les exploiter.

Sinon, vous courez un grand risque que le récit devienne "Microsoft laisse à nouveau ses développeurs dévoués derrière" Ne pas dire que c'est juste , juste essayer de vous avertir de ce qui pourrait arriver.

Quel est le délai raisonnable pour le LTS?

6 ans peut-être? Je pense que la messagerie va jouer un rôle énorme dans la réception. Au final, certaines personnes seront bouleversées quoi qu'il arrive: /

@davidfowl @ aL3891

Pour référence, Java LTS "Premier Support" est de 5 ans avec "Extended Support" (payant) de trois ans supplémentaires. Java 11, qui est une version LTS et a été publié le mois dernier, sera pris en charge jusqu'en septembre 2023 et septembre 2026 respectivement

Nous étudions une offre LTS «support étendu» et fournirons plus de détails lorsque nous les aurons. Cela offrirait potentiellement aux clients qui ont besoin d'un ASP.NET Core pris en charge sur .NET Framework version (2.1.x) une option plus longue que la période de prise en charge LTS actuelle.

Aussi pour info, j'ai discuté un peu des annonces aujourd'hui sur le standup de la communauté ASP.NET: https://www.youtube.com/watch?v=-b59KvkWBUo&list=PL1rZQsJPBU2StolNg0aqvQswETPcYnNKL&index=0

Target .net standard, s'il vous plaît. asp.net core peut cibler .netstandard2.1 ou 3.0 et laisser le rattrapage mono et .netframework plus tard, mais si asp.net core cible netcoreapp , alors n'importe quelle bibliothèque essaie d'accéder à un type de ces bibliothèques aspnetcore doit être une bibliothèque .netcoreapp .

et .net core sortira toujours plus rapidement que .net framework et mono ,
mono et .netframework finiront par consommer des assemblys .netcoreapp si Microsoft start cible plus de frameworks / bibliothèques à netcoreapp (cela entraînera également plus de bibliothèque sur la cible nuget .netcoreapp ).

si tel est le cas, le .netstandard deviendra .netcoreapp 😂

@ John0King, veuillez donner des exemples de types dont vous avez besoin en dehors d'ASP.NET Core.

1. Razor comme @poke mentionné
2. Interfaces / attributs de filtre MVC (j'ai une bibliothèque de classes d'assistance qui contient des ActionFilters et TagHelpers et une méthode statique / extention commune pour string, int, long ect. J'utilise PrivateAssert="All" pour référencer les packages MVC donc lorsque j'utilise bibliothèque quelque part ailleurs, ce projet n'a pas à référencer les assemblages MVC, je suppose que je dois séparer la bibliothèque en deux, l'un est .netstandard et un autre .netcoreapp )

une autre question est: est-ce que ce sera un problème pour quel type de bibliothèque de classes dois-je créer? ( .netstandard vs .netcoreapp ). Aujourd'hui, c'est assez simple dans asp.net core 2.1. choisissez .netstandard pour la bibliothèque de classe, choisissez .netcoreapp ou net461 pour le projet Web.

mono et .netframework finiront par consommer des assemblys .netcoreapp si Microsoft start cible plus de frameworks / bibliothèques à netcoreapp (cela entraînera également plus de bibliothèque sur la cible nuget .netcoreapp)

Cela se produira si les gens ne font pas plus d'efforts pour séparer ce qui devrait arriver à une bibliothèque .netstandard et ce qui arrivera à une bibliothèque .netcoreapp

Interfaces / attributs de filtre MVC (j'ai une bibliothèque de classes d'assistance qui contient des ActionFilters et TagHelpers et une méthode statique / extention commune pour string, int, long ect. J'utilise PrivateAssert = "All" pour référencer les packages MVC donc lorsque j'utilise cette bibliothèque quelque part ailleurs, ce projet n'a pas à référencer les assemblages MVC, je suppose que je dois séparer la bibliothèque en deux, l'un est .netstandard et un autre .netcoreapp)

Peux-tu élaborer? Cela n'a pas de sens. MVC est un framework ASP.NET Core et ne peut pas être utilisé de manière autonome.

@davidfowl cette bibliothèque est une bibliothèque de classes d'assistance, je peux utiliser ces filtres lorsque je travaille dans un projet MVC principal asp.net et n'utilise ses méthodes d'extension que dans une application console.

@davidfowl cette bibliothèque est une bibliothèque de classes d'assistance, je peux utiliser ces filtres lorsque je travaille dans un projet MVC principal asp.net et n'utilise ses méthodes d'extension que dans une application console.

Je ne comprends toujours pas. Parlez-vous d'une bibliothèque contenant des éléments MVC et d'autres éléments aléatoires?

Malheureusement, ce genre de chose est courant dans les logiciels d'entreprise - des `` bibliothèques d'aide '' qui ont, comme, les utilitaires de l'entreprise pour MVC + les utilitaires de l'entreprise pour WPF + les utilitaires de l'entreprise pour la telerik ...
Cela avait plus de sens lorsque «.NET» était une plate-forme unifiée unique.

@davidfowl oui. Il y a une classe / méthode dans la bibliothèque d'aide que vous pouvez utiliser partout. et quand vous faites référence à cette bibliothèque dans un projet mvc, vous pouvez utiliser sa classe / méthode associée à mvc.

Eh bien, cela force simplement vos bibliothèques à être mieux superposées 😉

Malheureusement, cela signifie que quiconque effectue encore des déploiements sur site ne peut pas prendre en charge son logiciel pendant plus de 3 ans. Dès que vous publiez une application ciblant .netcore 3.0 par exemple, vos clients ont 3 ans et sont alors contraints de se mettre à niveau. Certaines industries vont bien, d'autres certainement pas.

C'est le plus gros problème avec cela, et fait de .net core un non-go complet pour beaucoup de gens, j'imagine. En fait, je suis d'accord pour dire qu'en fin de compte, c'est la bonne direction à prendre, mais je suis certain que cela empêchera de nombreux endroits d'aller vers .net core.

J'aimerais vraiment une réponse de l'équipe .net à ce sujet.

Le fait est que ASP.NET Core est un framework Web. Dans quel secteur est-il sûr de gérer un site Web pendant plus de trois ans sans aucune modification? S'il ne s'agit pas de vulnérabilités de sécurité, ce seront les navigateurs qui abandonneront ce sur quoi vous vous êtes appuyé, ou TLS 1.4, ou les utilisateurs exigeant que le site fonctionne sur leur nouveau watchlet.

Au cours de cette période, vous devriez être en mesure de vous en sortir avec de petites modifications et des mises à jour mineures des dépendances, mais il est imprudent de planifier de ne pas mettre à jour une application Web du tout pendant des années.

Je pense que ce serait plus acceptable pour la communauté si vous augmentez simplement la période LTS pour ASP.NET Core 2.1 à 5-7 ans.

D'après notre expérience, le développement des entreprises évolue à un rythme glacial par rapport au développement Web «moderne», et pourtant ils veulent toujours s'assurer qu'ils ne font pas de nouveaux investissements sur des plates-formes beaucoup plus anciennes. Ces applications prennent souvent plus d'un an pour même _lancer_, et encore moins pour pouvoir effectuer une mise à niveau majeure en 3 ans. Ces applications Web d'entreprise (généralement internes uniquement) sont souvent prises en charge pendant 7 à 10 ans, bien que je pense qu'il soit déraisonnable que le LTS pour ASP.NET Core 2.1 dure 10 ans. 5 ans semble être une meilleure solution que 3, 7 ans étant un chiffre qui mettrait sûrement presque tout le monde à l'aise.

Et cela n'est nécessaire que parce que ASP.NET Core 3.0 nécessite une modification de rupture majeure supprimant la prise en charge de .NET Framework. Les futures versions de LTS ne devraient pas être tenues à cette norme, en supposant que les changements de rupture ne sont pas aussi importants.

Je ne sais pas comment rendre .NET Standard aussi rapide que .NET Core peut être considéré comme une punition: rien ne vous oblige à cibler le dernier netstandard TFM. Vous ne le ferez que si vous avez besoin du dernier ensemble d'API. Si vous n'en avez pas besoin, ciblez une version plus ancienne afin que vos packages puissent être utilisés par un ensemble plus large de plates-formes.

Et si la plateforme ne rattrapait jamais son retard? Ensuite, vous aurez une bibliothèque qui cible netstandard2.3 qui nécessite la fonctionnalité A qui n'est disponible que sur .NET Core et Xamarin, mais impossible pour .NET Framework.

Ensuite, netstandard2.4 sort, avec quelques nouveaux Apis et certaines de ces API sont possibles à porter vers .NET Framework. Et maintenant?

Comment cibler une bibliothèque qui a besoin d'une fonctionnalité de netstandad2.4 qui s'exécute sur .NET Framework, mais netstandard2.4 ne peut pas cibler .NET Framework, car il ne peut pas implémenter netstandard2.2 .

Ensuite, vous devrez croiser la compilation sur trois plates-formes:
netstandard2.2 pour les anciennes plates-formes et net4x pour le standard net juste pour prendre en charge la fonctionnalité qui a été ajoutée dans netstandad2.4 et qui net4x can also implement but not support because of APIs that went into netstandard2.3`.

Comment cela faciliterait-il la tâche aux auteurs de packages d'écrire et d'expédier leurs packages de nugget?

Le tout ne peut fonctionner que lorsque le plus petit dénominateur commun que toutes les plates-formes vont prendre en charge passe dans netstandard. À moins que vous ne souhaitiez que davantage d'API lancent des exceptions PlatformNotSupported , sinon cela entraînera une fragmentation au sein du netstandard.

Je peux certainement imaginer que ce n'est pas idéal pour vous, tout comme la suppression de la prise en charge de .NET Framework pour ASP.NET Core 3.0 ne sera pas idéale pour les personnes qui ne peuvent pas passer à .NET Core. Mais ai-je totalement tort de penser que vous - Microsoft - avez beaucoup plus de ressources pour faire face à cela qu'une entreprise moyenne ne doit passer à .NET Core? (Je ne parle même pas des dépendances externes que vous ne possédez pas et ne contrôlez pas).

Quel est le problème réel ici? Les personnes qui ne peuvent pas passer d'ASP.NET Legacy à ASP.NET Core ne pourront pas déplacer, que ASP.NET Core cible ou non .NET Framework. La raison la plus probable pour laquelle ils ne peuvent pas ou ne sera pas sera System.Web bibliothèques spécifiques, qui ne fonctionneront pas non plus sur ASP.NET Core sur .NET Framework. Les personnes qui ont leurs applications maintenant, ont évidemment déjà le jeu de travail.

Et les personnes qui sont déjà sur ASP.NET Core 2.1 sur .NET Framework, si cela fonctionne, pourquoi vouloir déménager? De toute évidence, tout ce dont vous avez besoin est déjà là et tout ce qui vient récemment d'ASP.NET Core 3.0 est agréable à avoir.

Quant aux autres:
Il existe de nombreuses façons de migrer une application vers .NET Core, c'est-à-dire de séparer des parties des anciennes applications monolithiques et de les réimplémenter en tant que microservices, ce qui vous permet également de réduire le risque et de le répartir dans le temps

Et si la plateforme ne rattrapait jamais son retard? Ensuite, vous aurez une bibliothèque qui cible netstandard2.3 qui nécessite la fonctionnalité A qui est uniquement disponible sur .NET Core et Xamarin, mais impossible pour .NET Framework.

Si une API ne peut pas être implémentée par la majorité des plates-formes prenant en charge .NET Standard, il y a de fortes chances qu'elle ne fasse pas partie de la norme, non? (en pratique, c'est très probablement l'inverse, car les plates-formes sur lesquelles Xamarin s'exécute sont généralement beaucoup plus contraintes). Je m'attendrais à ce que ce type de problème soit détecté lors de l'examen de l'API pour l'inclusion dans .NET Standard, mais je me trompe peut-être.

Et les personnes qui sont déjà sur ASP.NET Core 2.1 sur .NET Framework, si cela fonctionne, pourquoi vouloir déménager?

• Soutien? (un support de 3 ans est incroyablement court)
• Un correctif de bogue présent uniquement dans la version 3.0? (Les versions LTS ne reçoivent des correctifs que pour les bogues et vulnérabilités critiques)
• Vous devez référencer une bibliothèque compatible uniquement avec la dernière version d'ASP.NET Core?

Il existe de nombreuses façons de migrer une application vers .NET Core, c'est-à-dire de séparer des parties des anciennes applications monolithiques et de les réimplémenter en tant que microservices, ce qui vous permet également de réduire le risque et de le répartir dans le temps

Oui, bien sûr, en théorie, c'est la façon idéale de gérer cela. Mais:

• Certaines applications dépendent de bibliothèques externes sur lesquelles vous n'avez aucun contrôle. Si la bibliothèque ne fonctionne pas sur .NET Core et que le fournisseur ne veut pas (ou ne peut pas) la porter, vous n'avez pas de chance.
• La migration vers .NET Core peut être coûteuse et longue. Si même les meilleures équipes de Microsoft ont du mal avec cela, pensez-vous vraiment que ce sera aussi facile pour une équipe moyenne? Nous devrons attendre la 3.0 pour voir Entity Framework 6 être enfin compatible avec .NET Standard.

N'interprétez pas mal ce que je dis: je suis tout à fait d'accord pour utiliser .NET Core pour les nouvelles applications. Mais le fait qu'ASP.NET Core soit compatible avec .NET Framework a aidé de nombreuses entreprises à passer à ASP.NET Core pour un coût raisonnable. Je suis convaincu que cela n'aurait jamais été aussi populaire sans ce chemin de migration «pas trop difficile».

Microsoft, serait-ce trop demander d'étendre le support 2.1? 2021 n'est pas assez long pour nous et nous n'avons pas assez de ressources / de temps pour effectuer cette conversion. Peut-être jusqu'en 2022 au moins? Une année supplémentaire nous donnerait vraiment la chance de faire les changements, même s'ils sont douloureux.

Gardez à l'esprit que bon nombre de nos fournisseurs tiers n'ont pas encore migré leurs bibliothèques vers la compatibilité .Net Core, ce qui est la principale raison de notre blocage.

Pour info https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434521855

Bien que je considère l'extension de LTS comme nécessaire, l'OMI déplaçant ASP.NET Core sur .NET FX dans le cycle de prise en charge de .NET FX devrait également entrer en considération. Pour les débutants, il est déroutant d'avoir différentes parties de .NET Framework sur différents cycles de support où le regrouper aurait plus de sens. Deuxièmement, le code de la version 2.1 est déjà écrit, publié et dépendait donc de beaucoup moins de ressources pour prendre en charge la version 2.1 que de le développer activement en tangente avec .NET Core 3.0. Si la même équipe gère les deux, je suppose également que la base de code active ASP.NET Core récente et plus familière, modulaire, sera plus facile à prendre en charge que la base de code ASP.NET classique complètement différente.

Lorsque MS a annoncé la fin de vie de Silverlight 5 en 2012, ils le supportent toujours jusqu'en octobre 2021 (bien qu'il ait été abandonné dans Chrome en 2015 et Firefox en 2017). C'est pour la technologie qui est complètement abandonnée, ce qui n'est pas le cas ici, en grande partie la même base de code, le même modèle de programmation, une équipe de développement active y travaille toujours, c'est uniquement le logiciel existant sur .NET Framework qui est abandonné.

Avant cette annonce, il y avait un message fort MS n'abandonnait jamais .NET Framework qu'il était idéal pour les charges de travail Windows uniquement (contrairement à .NET Core pour les charges de travail multiplateformes / hautes performances) et qu'ASP.NET Core était l'avenir modèle de programmation qui prendrait en charge à l'avenir .NET Framework et .NET Core avec .NET Standard comme solution pour le développement de bibliothèques ciblant plusieurs plates-formes.

Il est maintenant clair que .NET Core est l'avenir de tous les nouveaux projets, mais il s'agit de savoir comment traiter les investissements existants et les clients existants qui ont pris des décisions basées sur ces conseils jusqu'à présent. Comment les équipes de développement .NET existantes progressent-elles lorsqu'elles ont besoin de prendre en charge les systèmes existants? Elles vont être obligées de rester sur ASP.NET classique (où leurs compétences / connaissances existantes sont obsolètes de jour en jour) tout en changeant de contexte pour développer de nouvelles applications sur .NET Core.

Si j'étais obligé de maintenir des systèmes sur .NET Framework, je préférerais de beaucoup le développer sur le nouveau modèle de programmation ASP.NET avec accès à une base de connaissances / écosystème actif, puis être obligé de revenir à l'ancien ASP.NET indéfiniment, mais cela ne sera possible que si ASP.NET Core sur FX a le même niveau de prise en charge que WebForms.

MS a également l'opportunité de positionner ASP.NET Core sur FX comme un environnement de développement «stable» (c'est-à-dire fixé sur ASP.NET Core 2.1). Il n'a pas été facile d'être un développeur .NET au cours des dernières années depuis le lancement de .NET Core. Nous avons effectivement dû abandonner tous nos efforts pour essayer de porter vers .NET Core <1.x car il était difficile de suivre le flux constant de changements de rupture, ce n'est que jusqu'à .NET Core 2.x que nous avons pu pour le prendre en charge et migrer les applications existantes sur. De l'autre côté, les développeurs ASP.NET Framework existants ont vu leur plate-forme choisie stagner, puis remplacée par le nouveau modèle de programmation ASP.NET Core et par extension éroder leurs compétences / connaissances existantes. La fin de la prise en charge d'ASP.NET Core sur FX tue une stratégie de migration par étapes populaire vers .NET Core où ils risquent (sans secours d'urgence) de s'exécuter sur une plate-forme abandonnée à moins qu'ils ne soient en mesure de mettre à niveau l'ensemble de leur système vers .NET Core (un risque qui peuvent empêcher les tentatives de migration d'envisager), cela élimine également leur opportunité de pouvoir participer au futur modèle de développement ASP.NET Core s'ils ne sont pas en mesure de migrer leurs systèmes existants sur lesquels ils travaillent quotidiennement, ce qui seulement possible s'il bénéficie du même support que WebForms - ce qui, je l'espère, est toujours à l'étude.

Personne ne l'a mentionné: dans notre application principale asp.net, nous devons héberger des services WCF et c'est le seul problème pour migrer à partir du framework .net. Malheureusement, je ne vois aucune nouvelle concernant le support wcf côté serveur sur .net core 3.

@DamianEdwards @davidfowl @natemcmaster Nous sommes dans le même bateau. Mon entreprise a un certain nombre de produits qui fonctionnent sur ASP.Net Core sur le framework .Net Full, et nous les soutenons pendant beaucoup plus de 3 ans, en raison de la lenteur avec laquelle les industries que nous vendons évoluent. Étendre le LTS pour .net core 2.2 n'aurait aucun sens dans notre situation car nous aurions à porter nos applications de base ASP.net vers ASP.Net. C'est sûrement vaincre le point les gars! Souhaitez-vous simplement suggérer des demandes de soutien pour des périodes plus courtes? Malheureusement, c'est aussi quelque chose que nous n'avons pas de contrôle. Les industries dans lesquelles nous travaillons peuvent prendre un an simplement pour déployer notre nouveau logiciel.

Malheureusement, cela signifie que quiconque effectue encore des déploiements sur site ne peut pas prendre en charge son logiciel pendant plus de 3 ans. Dès que vous publiez une application ciblant .netcore 3.0 par exemple, vos clients ont 3 ans et sont alors contraints de se mettre à niveau. Certaines industries vont bien, d'autres certainement pas.

C'est le plus gros problème avec cela, et fait de .net core un non-go complet pour beaucoup de gens, j'imagine. En fait, je suis d'accord pour dire qu'en fin de compte, c'est la bonne direction à prendre, mais je suis certain que cela empêchera de nombreux endroits d'aller vers .net core.

J'aimerais vraiment une réponse de l'équipe .net à ce sujet.

@davidfowl https://github.com/aspnet/AspNetCore/issues/3753#issuecomment -434594997

Eh bien, cela force simplement vos bibliothèques à être mieux superposées 😉

Cet argument ne fonctionne-t-il pas en sens inverse?

Ce que je ne comprends pas, c'est ce qui vous empêche réellement de disposer d'une architecture de couches appropriée d'ASP.NET Core?
Donc, oui, certaines fonctionnalités d'exécution ne sont pas disponibles sur .Net Framework, telles que Span<T> , mais cela ne signifie pas qu'elle n'est pas du tout disponible. Il est disponible , il n'est tout simplement pas aussi performant que sur le noyau .Net. Nous pourrions nous en occuper.

Certaines implémentations de bas niveau pourraient être implémentées dans des variantes pour .net core spécifiquement et pour .net standard. Et je doute qu'il y ait beaucoup de place pour cela, car les API sont généralement disponibles sous forme de packages NuGet.
De nombreux auteurs de bibliothèques prennent en charge différentes implémentations pour différentes plates-formes, c'est ce qui a toujours été.

Pourriez-vous s'il vous plaît expliquer ce qui vous empêche exactement de prendre en charge .Net Framework / .Net Standard. Quelques exemples simples de ce qui ne peut pas être abstrait pour avoir des implémentations spécifiques à la plate-forme?

vous empêche de prendre en charge .Net Framework / .Net Standard. Quelques exemples simples de ce qui ne peut pas être abstrait pour avoir des implémentations spécifiques à la plate-forme?

Du haut de ma tête, des éléments nécessitant des changements d'exécution ou de cadre

• Pointeurs GC intérieurs; donc créer un Span sûr à partir d'une référence uniquement sans objet: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Implémentations d'interface par défaut
• Éléments de travail personnalisés de Threadpool
• Surcharges d'étendue sur les types de base: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsyncDisposable surcharges sur les types de base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.
• IAsyncEnumeratorsurcharges sur les types de base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.

Objets bonus

• Matériel intrinsèque (x86, x64, ARM)
• Analyse d'évasion (nouvelles allocations à empiler)
• Versions d'exécution côte à côte
• Correction des redirections de liaison et du contrôle de version

Je ne comprends pas pourquoi nous ne pouvons pas simplement avoir une version netstandard qui ne prend plus en charge netframework. Tout comme Windows Phone n'a pas de support netstandard au-delà de 1.2. Pourquoi ne pouvons-nous pas faire avancer le standard et permettre à des implémentations telles que netcore, mono, xamarin, etc. de le faire correspondre éventuellement ou jamais. C'est ensuite au créateur de la bibliothèque de décider quelle version Netstandard il souhaite implémenter afin de maximiser la couverture.

Cette modification fait en sorte que xamarin et mono ne peuvent plus utiliser aspnetcore. Cela fait que les fabricants de bibliothèques sont obligés de cibler à la fois netcore et netstandard ou, pire encore, abandonner netstandard tous ensemble et ne cibler que netcore.

Cela mènera finalement à la mort de netstandard.

vous empêche de prendre en charge .Net Framework / .Net Standard. Quelques exemples simples de ce qui ne peut pas être abstrait pour avoir des implémentations spécifiques à la plate-forme?

Du haut de ma tête, des éléments nécessitant des changements d'exécution ou de cadre

• Pointeurs GC intérieurs; donc créer un Span sûr à partir d'une référence uniquement sans objet: MemoryMarshal.CreateSpan<T>(ref T reference, int length)
• Utf8String s
• Implémentations d'interface par défaut
• Éléments de travail personnalisés de Threadpool
• Surcharges d'étendue sur les types de base: Stream, Sockets, TextReader / TextWriter, WebSockets
• IAsyncDisposable surcharges sur les types de base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.
• Surcharges IAsyncEnumerator sur les types de base: Stream, Sockets, TextReader / TextWriter, WebSockets, etc.

Objets bonus

• Matériel intrinsèque (x86, x64, ARM)
• Analyse d'évasion (nouvelles allocations à empiler)
• Versions d'exécution côte à côte
• Correction des redirections de liaison et du contrôle de version

Les éléments de cette première liste ressemblent à des éléments susceptibles d'être modifiés par Netstandard?

La plupart d'entre eux ne semblent pas impossibles à intégrer à d'autres environnements d'exécution, mais il semble que personne ne veuille réviser le CLR pour une nouvelle version afin d'apporter les implémentations d'interface par défaut à .NET Framework.

Dans le même temps, Microsoft ne semble pas vouloir pousser vers l'avant avec une version de .NET Standard qui est à jamais incompatible avec .NET Framework. Sinon, ce ne serait pas vraiment un problème - avancez simplement avec netstandard30 ou netstandard40 et supprimez le support du Framework; et que .NET Core cible l'une de ces nouvelles normes.

J'ai l'impression que ce fil, etc. est le résultat de Microsoft se peignant efficacement dans un coin.

Dans le même temps, Microsoft ne semble pas vouloir pousser vers l'avant avec une version de .NET Standard qui est à jamais incompatible avec .NET Framework.

Ce mensonge; .NET Standard 2.1 est en cours de finalisation et dispose de 3104 nouvelles API sur .NET Standard 2.0, y compris des surcharges Span sur les types de framework de base; ce qui peut le rendre incompatible avec .NET Framework.

.NET Standard progresse toujours.

Sinon, ce ne serait pas vraiment un problème - il suffit d'aller de l'avant avec netstandard30 ou netstandard40 et d'abandonner le support de Framework; et que .NET Core cible l'une de ces nouvelles normes.

Le problème est de rendre chaque runtime, et pas seulement le Framework incompatible avec l'un des standards les plus récents; et ensuite incompatible avec tous les standards après cela. Ce qui entre dans .NET Standard doit être accepté par les différents environnements d'exécution comme des éléments qui peuvent être implémentés.

Les divers GC de Mono et Unity prendront-ils bientôt en charge les pointeurs intérieurs? Sinon, les ajouter à .NET Standard les bloquera de ce standard .NET tout futur standard .NET jusqu'à ce que leurs GC soient modifiés pour les gérer. Toutefois; il vaut mieux ajouter des apis qu'ils peuvent implémenter maintenant et enregistrer ceux qu'ils ne peuvent pas pour une future norme.

Les apis ajoutés à Core sont-ils les bons apis pour être définitivement corrigés pour toujours et forcer chaque exécution? qui veut être compatible avec la prochaine norme, à mettre en œuvre?

Certaines des API Core 2.1 ont été modifiées entre l'aperçu 1 et l'aperçu 2 (en raison des commentaires sur l'utilisation); il est donc difficile de savoir quelles sont les API qui sont nouvelles dans Core X jusqu'à sa sortie, à quel point elles sont gravées dans la pierre. Ensuite, lesquels d'entre eux sont le jeu correct à ajouter à la norme pour tous les environnements d'exécution à implémenter (ou être laissés pour compte).

L'approche de .NET Standard est encore plus agressive que les standards de navigateur lorsque 2 navigateurs doivent implémenter la fonctionnalité avant qu'une norme ne soit acceptée.

Ce serait bien si un nouveau .NET Standard pouvait être livré en même temps que .NET Core et que tous les runtimes pourraient l'implémenter instantanément et ASP.NET Core pourrait alors utiliser tous les nouveaux API via .NET Standard; mais bien que beau comme idéal, ce n'est pas non plus pratique. Il existe même un certain nombre d'API approuvées qui n'ont pas été implémentées dans .NET Core

La question de base est de savoir si ASP.NET Core peut utiliser les API qui lui ont été demandées et être livrées dans la version .NET Core qui l'accompagne (car elles sont livrées simultanément); ou peut-il uniquement utiliser les API fournies dans la version précédente de .NET Core - qui ont donc une chance d'être dans la version .NET Standard pour ce .NET Core? (Comme cela ressemble à .NET, les versions Standard seront actuellement en retard dans la version apis 1 par rapport à .NET Core; en utilisant la taille d'échantillon de 1)

Si ASP.NET Core peut utiliser l'apis; puis les API font des tests d'utilisation et évaluent si elles sont de bonnes API; s'ils ne le sont pas, de meilleures apis peuvent être proposées. Si ASP.NET Core ne peut pas les utiliser, il est encore assez inconnu de savoir s'il s'agit de bons API lorsqu'ils deviennent des candidats .NET Standard.

personne ne veut réviser le CLR pour une nouvelle version afin d'apporter les implémentations d'interface par défaut à .NET Framework.

.NET Core en prenant en charge les charges de travail traditionnelles du .NET Framework (y compris WinForms et WPF) est essentiellement la révision du CLR; mais fait d'une manière plus durable et à l'épreuve du futur?

Ce mensonge; .NET Standard 2.1 est en cours de finalisation et dispose de 3104 nouvelles API sur .NET Standard 2.0, y compris les surcharges Span sur les types de framework de base; ce qui peut le rendre incompatible avec .NET Framework.

Y compris .NET Framework 4.8 et .NET Framework 4.9?

Il est toujours possible que les futures mises à jour du Framework obtiennent ces nouvelles API. Pour le moment, il semble gravé dans la pierre que .NET Framework n'obtiendra jamais DIM, par conséquent, toute interface avec une méthode DIM ne pourra jamais être portée vers .NET Framework.

.NET Core en prenant en charge les charges de travail traditionnelles du .NET Framework (y compris WinForms et WPF) est essentiellement la révision du CLR; mais fait d'une manière plus durable et à l'épreuve du futur?

Et pas à l'épreuve du recul. Autant que Microsoft a montré des choses comme Paint.Net fonctionnant sur .NET Core, je ne peux pas exécuter mes projets existants côté serveur sur .NET Core, et la plupart des gens non plus.

Ce serait bien si un nouveau .NET Standard pouvait être livré en même temps que .NET Core et que tous les runtimes pourraient l'implémenter instantanément et ASP.NET Core pourrait alors utiliser tous les nouveaux API via .NET Standard; mais bien que beau comme idéal, ce n'est pas non plus pratique.

Cela peut également ne pas être pratique, mais je pense que les gens seraient globalement un peu plus heureux s'il pouvait y avoir deux versions d'ASP.NET Core:

• Une version à la pointe de la technologie qui évolue rapidement, liée à .NET _Core_ et peut utiliser toute nouvelle API qu'elle désire.
• Une version LTS plus lente qui est liée à .NET _Standard_ et s'exécute dans plus d'endroits; qui finit par rattraper les anciennes constructions de pointe mais toujours à la traîne.

En l'associant à .NET Core, vous forcez un compromis dont tout le monde n'est pas satisfait. Je comprends le raisonnement derrière l'approche gotta-move-fast, mais il y a aussi une préoccupation légitime pour l'ensemble de l'écosystème .NET.

• Une version à la pointe de la technologie qui évolue rapidement, liée à .NET Core et peut utiliser toute nouvelle API qu'elle souhaite.
• Une version LTS plus lente qui est liée à .NET Standard et s'exécute dans plus d'endroits; qui finit par rattraper les anciennes constructions de pointe mais toujours à la traîne.

Donc, si ASP.NET Core 3.0 est sorti en tant que .NET Core 3.0 uniquement; mais à une date ultérieure, alors qu'il s'agissait d'un .NET Standard qui avait les apis; des packages pour ASP.NET Core 3.x ont été publiés qui étaient également .NET Standard (même si ASP.NET Core était passé à 4.0); cela répondrait-il à vos besoins?

@ yaakov-h

Une version LTS plus lente qui est liée à .NET Standard et s'exécute dans plus d'endroits; qui finit par rattraper les anciennes constructions de pointe mais toujours à la traîne.

Qu'est-ce que ça veut dire? Vous pouvez toujours utiliser ASP.NET Core 2.1 avec la prise en charge étendue mentionnée par

Vous pouvez toujours utiliser ASP.NET Core 2.1 avec la prise en charge étendue qui

Ne divisez pas la communauté s'il vous plaît !!
(basé sur le vote) Pensez-vous que 1/3 des développeurs restent dans asp.net core 2.1? ou attendez-vous à 2/3 de développeurs qui créent des packages nuget qui doivent maintenir 2 versions de leur bibliothèque?

@benaadams

Donc, si ASP.NET Core 3.0 est sorti en tant que .NET Core 3.0 uniquement; mais à une date ultérieure, alors qu'il s'agissait d'un .NET Standard qui avait les apis; des packages pour ASP.NET Core 3.x ont été publiés qui étaient également .NET Standard (même si ASP.NET Core était passé à 4.0); cela répondrait-il à vos besoins?

Précisément.

@davidfowl

Vous pouvez toujours utiliser ASP.NET Core 2.1 avec la prise en charge étendue mentionnée par

Il semble y avoir des messages contradictoires ici:

1. C'est bien de rester sur 2.1, l'ancienne version LTS
2. ASP.NET Core évolue si vite que nous ne pouvons même pas attendre un cycle de publication entre .NET Core et le standard .NET ultérieur.

Je pense que (2) cause beaucoup de confusion et de peur d'être laissé pour compte.

@ John0King

(basé sur le vote) Pensez-vous que 1/3 des développeurs restent dans asp.net core 2.1? ou attendez-vous à 2/3 de développeurs qui créent des packages nuget qui doivent maintenir 2 versions de leur bibliothèque?

J'attends des auteurs de bibliothèques qu'ils décident de la version minimale d'ASP.NET Core qu'ils souhaitent prendre en charge et la ciblent. C'est ce qu'ils font déjà aujourd'hui. Certaines bibliothèques prennent en charge ASP.NET Core 1.x et 2.x, d'autres ne prennent en charge que 2.x. Ce n’est pas différent.

@ yaakov-h

Je ne comprends pas très bien quels sont les messages contradictoires. La version 2.1 actuelle est LTS et fonctionne sur .NET Core et .NET Framework et est prise en charge pendant 3 ans. Ce n'est pas un nouveau message, c'est le même message que nous avons eu depuis le début.

ASP.NET Core évolue si vite que nous ne pouvons même pas attendre un cycle de publication entre .NET Core et le standard .NET ultérieur.

C'est une spéculation basée sur les commentaires faits ici. Officiellement, nous sommes liés au cycle de livraison de .NET Core et nous ajoutons et consommons déjà de nouvelles API à chaque version. ASP.NET Core fonctionnant sur .NET Framework n'a jamais été censé être une chose permanente (il est même appelé ASP.NET Core), il a toujours été conçu comme un tremplin. Nous devions simplement ajouter suffisamment d'API de base pour que les clients puissent raisonnablement écrire des applications pleinement fonctionnelles.

Une réponse à ce sujet de la part de l'équipe MS?

Malheureusement, cela signifie que quiconque effectue encore des déploiements sur site ne peut pas prendre en charge son logiciel pendant plus de 3 ans. Dès que vous publiez une application ciblant .netcore 3.0 par exemple, vos clients ont 3 ans et sont alors contraints de se mettre à niveau. Certaines industries vont bien, d'autres certainement pas.

C'est le plus gros problème avec cela, et fait de .net core un non-go complet pour beaucoup de gens, j'imagine. En fait, je suis d'accord pour dire qu'en fin de compte, c'est la bonne direction à prendre, mais je suis certain que cela empêchera de nombreux endroits d'aller vers .net core.

J'aimerais vraiment une réponse de l'équipe .net à ce sujet.

Malheureusement, cela signifie que quiconque effectue encore des déploiements sur site ne peut pas prendre en charge son logiciel pendant plus de 3 ans.

ce ne sont que des conneries, vous pouvez en fait simplement avoir une mise à niveau. le seul moment où cela ne fonctionne pas est dans un environnement embarqué, mais les logiciels embarqués posent bien plus de problèmes qu'une fenêtre de support de 3 ans.

@schmitch Je ne suis pas sûr de ce que tu veux dire? Évidemment, vous pouvez simplement mettre à niveau, mais pour certaines industries, la mise à niveau vers une nouvelle version de logiciel devient un projet massif qui peut prendre des années, en fonction des cycles de publication et de la progression technique (ou non) de ces industries.

@davidfowl

Je suppose que même si ce soutien était de 10 ans, il ne satisferait pas les gens qui se plaignent.

Je ne sais pas comment vous vous attendiez à ce que les gens le prennent, tous les effets de cette décision sont confrontés à la plate-forme vers laquelle ils ont été vendus pour se déplacer non seulement n'a pas d'avenir, mais leurs investissements existants basés sur le dernier modèle de programmation sont en cours d'exécution. une plate-forme non prise en charge (celle à compter de cette annonce) dans moins de 3 ans. D'autres qui ont pensé à une migration par étapes prudente vers .NET Core via la migration vers .NET Framework d'abord sont maintenant confrontés au risque qu'il n'y ait aucune possibilité de repli - il s'agit de l'exécuter sur un nouveau runtime ou un arrêt .NET Core.

Une plate-forme de développeur ne devrait pas être l'objectif en soi, car la valeur créée sur la plate-forme est exponentiellement plus grande que la valeur de la plate-forme elle-même. Des mouvements aveugles comme celui-ci donnent l'impression que l'efficacité maximale des ressources pour augmenter la vitesse de la plate-forme est plus importante que les investissements de l'écosystème créé sur celle-ci. L'encre sur les bits .NET Core 2.1 n'est même pas encore sèche, mais les systèmes existants (sur FX) sont déjà traités comme un passif (dans le but de fournir un support minimal) au lieu de l'actif et de la valeur qu'ils ajoutent à l'écosystème.

Comme cela a été mentionné, les systèmes d'entreprise peuvent évoluer à un rythme glacial, équilibrant souvent simultanément des équipes de développeurs, offrant des améliorations continues que nombre d'employés et de clients doivent utiliser pour en tirer un retour sur investissement constant. De nombreuses migrations doivent avoir lieu "en vol" avec une planification minutieuse et des tests rigoureux qui peuvent prendre des années - temps qu'ils préfèrent utiliser pour créer de la valeur, puis se démener pour quitter la plate-forme dont le support est retiré. Les grands systèmes de friches industrielles ne sont pas des produits comme les iPhones qui peuvent être facilement jetés et mis à niveau de manière transparente toutes les quelques années, plus les systèmes anciens et longs sont en développement, plus la valeur y est investie et plus il sera difficile d'en migrer, ce qui devient particulièrement difficile à absorber étant donné qu'il n'y a pas de valeur créée dans les migrations, cela nécessite des ressources, absorbe le coût d'opportunité, augmente les risques et le mieux qu'ils puissent espérer est une migration sans faille avec leurs systèmes existants fonctionnant exactement comme avant.

Quelle que soit la date d'expiration fixée pour le support FX, il y aura des systèmes existants en cours d'exécution qui se heurteront à des barrages routiers ou qui étaient autrement impossibles à migrer hors de celui-ci. Que devient alors le guide?

ASP.NET Core 2.1 est déjà développé, l'effort de faire fonctionner ASP.NET Core sur FX / .NET Core est un coût irrécupérable déjà investi. La décision doit donc être formulée comme une question de ressources MS pour maintenir une plate-forme déjà développée (après LTS) par rapport au montant cumulé des coûts, de la mauvaise volonté et de l'inertie générés pour abandonner une plate-forme populaire.

Je ne suis pas sûr de comprendre ce qu'on demande alors. Le cycle de vie de LTS n'a pas changé depuis la sortie de la version 2.1. Si vous avez écrit une application sur la version LTS, que ce soit .NET Core ou .NET Framework, cela prendrait 3 ans avant que vous ne soyez «non pris en charge». Je ne comprends pas très bien comment le tapis est tiré de dessous vous en termes de soutien, cela n'a pas changé. Vous devrez mettre à niveau pour obtenir les mises à jour de la plate-forme.

Maintenant, je comprends que la version 2.1 étant la dernière version LTS prise en charge sur .NET Framework signifie qu'il n'y a pas d'endroit où effectuer une mise à niveau, mais c'est là que la prise en charge étendue de LTS entre en jeu. Si l'application ne peut

Je ne suis pas sûr de comprendre ce qu'on demande alors.

Ce thread demande différents niveaux d'engagements de la part de MS allant de: continuer à le développer en tandem avec .NET Core, le développer sur un «train lent», sans abandonner ASP.NET Core 2.1 et maintenir le même niveau de support que WebForms, étendre LTS . Ma préférence serait de ne pas l'abandonner en tant qu'option d'hébergement pour ASP.NET Core (modifier: obv tout ce qui serait plus préférable) qui ne retiendrait pas .NET Core uniquement v3 + tout en fournissant beaucoup d'utilité pour .NET existant Investissements FX.

Maintenant, je comprends que 2.1 étant la dernière version LTS prise en charge sur .NET Framework signifie qu'il n'y a pas de place pour mettre à niveau vers

Ce qui signifie qu'il est devenu une plate-forme non prise en charge, tout le monde doit la traiter comme de la lave et se démener pour en sortir avant qu'elle n'atteigne sa fin EOL non prise en charge.

• Quiconque a pensé à l'utiliser comme plate-forme intermédiaire pour passer à .NET Core est devenu une option moins faisable car il court le risque d'être bloqué sur une plate-forme non prise en charge si la migration prend plus de temps que prévu ou s'il rencontre des obstacles si l'une des dépendances ils comptent sur ne peuvent pas fonctionner sur .NET Core.
• Quiconque est obligé d'utiliser les serveurs .NET Framework de l'infrastructure gérée existante de son entreprise ne peut pas participer à l'utilisation du nouveau modèle de développement et de l'écosystème et doit voir ses connaissances / compétences ASP.NET classiques existantes devenir moins précieuses chaque jour.
• Les équipes ne peuvent pas migrer leurs systèmes requis .NET Framework existants et nécessiteront un changement de contexte vers de nouveaux projets ASP.NET Core sur .NET Core.
• Aucune organisation ne souhaite être contrainte à une migration non planifiée car les conseils sur lesquels elle s'est appuyée pour fonder son budget, sa planification et ses décisions d'investissement ont changé.

Encore une fois, ce n'est pas un problème pour les projets nouveaux, pour les personnes qui peuvent ou prévoyaient de migrer vers .NET Core de toute façon ou pour toute personne qui n'a pas à maintenir les systèmes hérités, mais cela a un impact sur l'écosystème .NET FX existant et ASP.NET Core est devenu plus pauvre pour ne plus pouvoir envisager d'utiliser l'option populaire d'hébergement sur .NET FX.

Dans un monde parfait, tout le monde serait sur .NET Core mais il existe un montant considérable d'investissement dans .NET FX qui est dévalué avec cette décision.

Si l'application ne peut jamais passer à .NET Core même après ces 6 ans car les API sont manquantes,

Il y a beaucoup de gens qui ne peuvent ou ne veulent pas passer à .NET Core, ils veulent qu'il partage le même niveau de prise en charge que ASP.NET classique (ce que la messagerie actuelle suggère indéfiniment).

Les API manquantes ne sont pas la seule raison qui empêche la migration, par exemple, elles pourraient s'appuyer sur une dépendance où l'équipe de développement l'a créée n'existe plus, c'est un composant critique qui ne peut pas être modifié, il ne peut pas être refactorisé en toute sécurité (par exemple, aucun test), il est partagé avec d'autres systèmes .NET FX uniquement, il est maintenu par un autre service qui n'a pas de budget, de capacité à le modifier ou en raison de facteurs externes tels que l'infrastructure gérée par leur entreprise ne prend en charge que les serveurs .NET Framework.

Merci d'avoir tué .NET Standard avec ce genre de décisions.

Jusqu'à présent, nous avons ignoré .NET Core car il existe de nombreux assemblys tiers qui ne ciblent pas encore Core.

La plupart des fournisseurs qui sont prêts à prendre en charge Core le font à moitié, par exemple, Managed ODP.NET sans les API natives qui ne sont disponibles que sur .NET Framework.

Ensuite, vous arrivez avec ce genre de décisions.

Non, nous n'adopterons pas .NET Core plus rapidement simplement parce que Microsoft a trop de travail pour prendre en charge .NET Framework et qu'il n'est pas en mesure de fournir le standard .NET que vous avez poussé au départ.

@davidfowl Je peux vous donner 2 exemples de ce qui rend difficile la migration vers .NET Core - WCF (de nombreuses applications d'entreprise existantes l'utilisent, je crois que d'autres ont déjà soulevé ce problème), et le manque de bibliothèque Adomd dans .NET Core / NET Standard (pour la communication avec SSAS, également utilisé dans les applications d'entreprise, suivi dans SQL https://feedback.azure.com/forums/908035-sql-server/suggestions/35508349-adomd-core). Certains autres (winforms) devraient être corrigés avec le pack de compatibilité .net core 3 (yay!) - nous devons attendre et voir comment cela fonctionne vraiment.

@mythz

Ce thread demande différents niveaux d'engagements de la part de MS allant de: continuer à le développer en tandem avec .NET Core, le développer sur un «train lent», sans abandonner ASP.NET Core 2.1 et maintenir le même niveau de support que WebForms, étendre LTS . Ma préférence serait de ne pas l'abandonner en tant qu'option d'hébergement pour ASP.NET Core qui ne retiendrait pas .NET Core uniquement v3 + tout en fournissant beaucoup d'utilité pour les investissements .NET FX existants.

Eh bien, nous explorons actuellement l'extension de la prise en charge de LTS, mais nous n'envisageons pas pour toujours la prise en charge de .NET Framework de première classe pour ASP.NET Core (ce que vous demandez). Cette version d'ASP.NET Core que vous recherchez le même niveau de prise en charge que WebForms ne recevrait que des correctifs de sécurité et de fiabilité. Je peux vous garantir que, à mesure que les fonctionnalités apparaissent dans les nouvelles versions d'ASP.NET Core, le niveau de satisfaction de ceux qui utilisent ASP.NET Core 2.1 diminuera (du moins, c'est ce que mon instinct me dit) car ces changements seront toujours hors de atteindre.

Les API manquantes ne sont pas la seule raison qui empêche la migration, par exemple, elles pourraient s'appuyer sur une dépendance où l'équipe de développement l'a créée n'existe plus, c'est un composant critique qui ne peut pas être modifié, il ne peut pas être refactorisé en toute sécurité (par exemple, aucun test), il est partagé avec d'autres systèmes .NET FX uniquement, il est maintenu par un autre service qui n'a pas de budget, de capacité à le modifier ou en raison de facteurs externes tels que l'infrastructure gérée par leur entreprise ne prend en charge que les serveurs .NET Framework.

C'est très courant (même dans Microsoft) et c'est pourquoi nous avons ajouté cette possibilité de référencer les dll .NET Framework dans .NET Core 2.0, car il s'avère que la plupart des assemblys sont compatibles même s'ils n'ont pas été compilés pour .NET Core. Maintenant, il y a des choses qui ne fonctionneront jamais (comme AppDomains ...) mais je m'attends à ce que, à mesure que nous ajoutons plus de surface d'API, l'ensemble des bibliothèques qui ne fonctionnent pas seulement se réduira à un nombre insignifiant.

@pjmlp

Je ne vois pas comment cela tue .NET Standard. .NET Standard est bien plus grand que ASP.NET Core. Il s'agit de créer des bibliothèques partagées réutilisables (comme Microsoft.Extensions *) qui fonctionnent sur toute plate-forme .NET prise en charge.

Jusqu'à présent, nous avons ignoré .NET Core car il existe de nombreux assemblys tiers qui ne ciblent pas encore Core.

Lesquels? La prise en charge de ceux-ci est-elle en cours ou ces assemblys ne prendront-ils jamais en charge .NET Core?

La plupart des fournisseurs qui sont prêts à prendre en charge Core le font à moitié, par exemple, Managed ODP.NET sans les API natives qui ne sont disponibles que sur .NET Framework.

Je suis d'accord avec cela et j'ai vu des tonnes de versions paralysées de bibliothèques sur .NET Core (même avec certaines bibliothèques fournies par Microsoft) mais je dirais que les marées tournent autour de cela. Certaines des raisons à cela étaient dues au jeu d'API manquant initial qui existait sur .NET Core 1.0. Avec 2.0 et 2.1, nous avons vu un grand nombre de bibliothèques se porter plus facilement vers le noyau / standard sans trop de perte de fonctionnalités.

@voltcode Merci pour le retour concret! Nous nous attendons à ce que certains de ces types de problèmes de compatibilité disparaissent ou soient minimes au cours de la période pendant laquelle nous prenons en charge les projets .NET Core aujourd'hui (environ 3 ans).

@davidfowl

....

Jusqu'à présent, nous avons ignoré .NET Core car il existe de nombreux assemblys tiers qui ne ciblent pas encore Core.

Lesquels? La prise en charge de ceux-ci est-elle en cours ou ces assemblys ne prendront-ils jamais en charge .NET Core?

Dans notre cas, ODP.NET est le plus évident, car Oracle ne porte pas 100% des fonctionnalités du pilote dans Core.

La plupart des fournisseurs qui sont prêts à prendre en charge Core le font à moitié, par exemple, Managed ODP.NET sans les API natives qui ne sont disponibles que sur .NET Framework.

Je suis d'accord avec cela et j'ai vu des tonnes de versions paralysées de bibliothèques sur .NET Core (même avec certaines bibliothèques fournies par Microsoft) mais je dirais que les marées tournent autour de cela. Certaines des raisons à cela étaient dues au jeu d'API manquant initial qui existait sur .NET Core 1.0. Avec 2.0 et 2.1, nous avons vu un grand nombre de bibliothèques se porter plus facilement vers le noyau / standard sans trop de perte de fonctionnalités.

Ce n'est cependant pas ce que nos clients voient.

Juste pour que vous ayez une idée de la façon dont ce type de décisions affecte l'avenir de .NET, sur un projet récent, le client a payé l'effort de développement pour déplacer une application de .NET Framework vers Java pour un déploiement UNIX, car il n'était pas disposé à le faire pariez sur .NET Core et l'implémentation paralysée ODP.NET, tandis que le pilote JDBC offre une parité de fonctionnalités 1: 1 avec le pilote .NET Framework ODP.NET.

D'autres pourraient également choisir une autre pile alternative.

Il existe une tonne de dépendances qui ne peuvent pas et ne peuvent pas être portées dans votre application d'entreprise moyenne.

Ce problème est apparu au sommet de HN. Vous les gars (@MSFT) voudrez peut-être vérifier là aussi. Seulement 1h et déjà plus de 50 commentaires.

@davidfowl

Je ne vois pas comment cela tue .NET Standard. .NET Standard est bien plus grand que ASP.NET Core. Il s'agit de créer des bibliothèques partagées réutilisables (comme Microsoft.Extensions *) qui fonctionnent sur toute plate-forme .NET prise en charge.

Je ne comprends pas ce qu'est ASP.NET Core sinon une bibliothèque partagée réutilisable? Si la tendance des bibliothèques à être modernes et rapides consiste à abandonner le support .NET Standard, c'est un message délicat. Newtonsoft.Json devrait-il passer à .NET Core 3 uniquement s'il peut s'exécuter beaucoup plus rapidement? Devrait Autofac?

Je comprends les raisons de cela, mais je ne suis pas sûr que les arguments et l'évaluation aient beaucoup changé depuis la dernière fois que cela s'est produit! Je suppose que nous allons attendre et voir ...

Je vais jeter mon cas d'utilisation là-bas et donner une certaine perspective sur la façon dont les choses se présentent dans notre boutique en ce moment en ce qui concerne ceci:

AspNetCore a été incroyable pour notre pile en termes d'auto-hébergement (http.sys), d'une API Web et de contenu Web statique autour de divers services. Nous venons de Nancy, ce qui était solide, mais qui présentait également de nombreux défauts de notre point de vue, nous sommes donc passés à AspNetCore il y a environ un an. Aujourd'hui, nous exécutons chacune de nos bases de code sur 2.x. Dans de nombreux cas, nous serions parfaitement en mesure de passer à une cible .NET Core pure. Mais, il existe également de nombreux services que nous avons créés pour tirer parti d'AspNetCore qui reposent également sur des éléments tels que System.DirectoryServices et System.Drawing . Du point de vue de ces services, nous changerions la technologie d'hébergement Web avant de quitter .Net Framework. Malheureusement, en raison de la complexité de la gestion simultanée de 2 technologies d'hébergement Web différentes et de la taille de notre équipe, nous frapperions probablement également AspNetCore du reste de nos services en faveur de quelque chose de plus compatible entre les deux cibles.

Pour le dire brièvement - Cette décision nous forcera complètement à quitter AspNetCore à un moment donné dans le futur (probablement lorsque LTS expirera pour 2.x), pour ce que je ne sais pas pour le moment. Si cela se résume à cela, nous écrirons probablement notre propre solution interne pour remplacer AspNetCore, car nos cas d'utilisation en termes de nombre réel de fonctionnalités AspNetCore utilisées sont assez restreints (cela étant dit, les fonctionnalités que nous utilisons _do_ une valeur ajoutée énorme pour nous aujourd'hui).

D'autres pourraient également choisir une autre pile alternative.

C'est juste, mais les piles alternatives ont la même politique de support. Java est passé à un modèle LTS similaire (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Il existe une tonne de dépendances qui ne peuvent pas et ne peuvent pas être portées dans votre application d'entreprise moyenne.

@bencyoung

C'est un cadre, pas une bibliothèque. Il est composé d'un très grand ensemble de bibliothèques qui sont livrées ensemble.

Je ne comprends pas ce qu'est ASP.NET Core sinon une bibliothèque partagée réutilisable? Si la tendance des bibliothèques à être modernes et rapides consiste à abandonner le support .NET Standard, c'est un message délicat. Newtonsoft.Json devrait-il passer à .NET Core 3 uniquement s'il peut s'exécuter beaucoup plus rapidement? Devrait Autofac?

Je ne vois pas comment c'est compliqué. Je suis sûr à 97% que ces bibliothèques ne supprimeront pas les frameworks parce que leurs clients se plaindraient. La barre est extrêmement élevée pour supprimer les frameworks et c'est la même raison pour laquelle nous avons conservé Microsoft.Extensions. * Sur .NET Standard 2.0. Je conviens que ce serait flou si nous déplaçions tout là-bas, mais ce n'est pas ce qui se passe ici.

D'une certaine manière, cela ne fait que formaliser ce que la réalité est déjà sur .NET Core. Nous livrons ASP.NET Core avec .NET Core. Sur .NET Core, ASP.NET Core est un framework partagé, ce n'est pas seulement un ensemble de packages. Ces packages ne sont jamais expédiés séparément du produit global, de sorte que les avantages de référencer ces packages individuels sont faibles (la liste des packages est également petite).

@robkeimig

Mais, il existe également de nombreux services que nous avons créés pour tirer parti d'AspNetCore qui reposent également sur des éléments tels que System.DirectoryServices et System.Drawing

Ceux-ci existent dans le pack compact Windows sur .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Pour le dire brièvement - Cette décision nous forcera complètement à quitter AspNetCore à un moment donné dans le futur (probablement lorsque LTS expirera pour 2.x), pour ce que je ne sais pas pour le moment. Si cela se résume à cela, nous écrirons probablement notre propre solution interne pour remplacer AspNetCore, car nos cas d'utilisation en termes de nombre réel de fonctionnalités AspNetCore utilisées sont assez restreints (cela étant dit, les fonctionnalités que nous exploitons fournissent une valeur ajoutée énorme pour nous aujourd'hui).

Serait-ce également le cas si le soutien était prolongé?

De plus, nous devrons maintenant supprimer toutes les autres technologies non prises en charge (AppDomains, Remoting, etc.) d'abord, au lieu de pouvoir faire ce travail en parallèle ou à un stade ultérieur.

Pourquoi ne pouvez-vous pas d'abord migrer vers la version 2.1?

La principale raison pour laquelle j'hésiterais est que la limite de support de 3 ans signifie que vous ne pouvez pas rester leur. C'est un tremplin pour la migration à court terme, pas un point où vous pouvez avoir une plate-forme stable à long terme. Ce qui signifie que vous devez supporter toute la douleur de la migration vers l'avant en un seul morceau, car vous ne pouvez pas risquer d'aller à mi-chemin, interrompre la migration pour créer un certain nombre de nouvelles fonctionnalités hautement prioritaires, puis tenter de terminer la migration uniquement pour trouver un bloc dur et devez rétroporter toutes vos nouvelles fonctionnalités sur l'ancienne base de code.

La principale raison pour laquelle j'hésiterais est que la limite de support de 3 ans signifie que vous ne pouvez pas rester leur.

Bien sûr, c'est pourquoi nous proposons un support étendu comme @DamianEdwards l'a mentionné.

Juste pour montrer les conséquences de cette décision - qu'en est-il de Blazor? Arrêtera-t-il d'être basé sur, netstandard? Devrions-nous nous attendre à cela aussi? Blazor est annoncé comme la prochaine grande chose. Quoi d'autre de github.com/aspnet qui dépend actuellement de netstandard, l'abandonnera et passera au noyau net lors de la prochaine version majeure? Quels sont les plans pour d'autres choses, dans le contrôle MSFT mais en dehors du repo aspnet qui partageront le destin d'aspnetcore?

@davidfowl

D'autres pourraient également choisir une autre pile alternative.

C'est juste, mais les piles alternatives ont la même politique de support. Java est passé à un modèle LTS similaire (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Le petit détail que vous oubliez est que Java, et d'autres piles, sont toujours compatibles entre les versions contrairement à .NET Framework et .NET Core sans avoir besoin d'une norme qui n'est que partiellement implémentée dans les implémentations d'exécution.

Pour ce que cela vaut, je travaille actuellement sur le déploiement de la première application principale ASP.Net de mon entreprise. Nous avons un investissement très important dans le .NET Framework, donc utiliser ASP.Net Core sur .NET Framework par opposition à .NET Core était l'approche évidente.

Maintenant, je me demande si je nous prépare à beaucoup de douleur plus tard.

Il y a ici de nombreuses préoccupations interconnectées. Vous dites que le noyau ASP.Net n'a jamais été conçu pour s'exécuter uniquement sur le .NET Framework. Les messages de Microsoft sur ASP.Net Core dans le passé n'ont pas réussi à rendre cela très clair.

De même, de nombreux développeurs .NET sont habitués à l'idée que le .NET Framework est l'implémentation principale et que généralement les autres sont des sous-ensembles, sauf bien sûr pour les API spécifiques à l'environnement. Cela a changé avec .NET Core, mais de nombreuses personnes avaient généralement l'impression que le .NET Framework «complet» finirait par prendre en charge tout ce que fait presque .NET Core (à l'exception de l'outillage et de la compatibilité multiplateforme, évidemment), mais juste sur une échelle de temps plus lente, en attendant que les problèmes soient résolus avant de les inclure.

Récemment, il a été beaucoup suggéré que certaines fonctionnalités vraiment importantes pourraient ne jamais parvenir au .NET Framework. (par exemple, que les risques de compatibilité du Spanconsidéré comme trop sévère pour être implémenté dans .NET Framework 4.8 suggère qu'ils pourraient ne jamais être implémentés, car pourquoi ces risques seraient-ils inférieurs en 4.9 ?. Des préoccupations similaires entourent apparemment les méthodes d'interface par défaut.) C'est un changement de paradigme majeur dont de nombreux développeurs ne seront pas satisfaits!

Les messages de ce fil de discussion suggèrent que Microsoft commence à considérer le .NET Framework comme une fonctionnalité héritée, quelque chose qui attirera de moins en moins l'attention du développement au fil du temps, jusqu'à ce qu'il n'obtienne vraiment que des correctifs de sécurité.

Microsoft a toujours été horrible de savoir clairement ce qu'il développe activement, ce qu'il ne fait que maintenir avec de nouvelles fonctionnalités sporadiques et ce qu'il prévoit de fournir uniquement des correctifs de sécurité et de stabilité. Il me semble que le .NET Framework n'est pas seulement dans cette deuxième catégorie maintenant, mais est vraiment proche de la troisième catégorie.

C'est vraiment ennuyeux. .NET Core présente certains problèmes qui le rendent moins qu'optimal pour certaines applications d'entreprise. Bien sûr, l'utiliser sur des applications qui ont un développement continu continu pourrait être bien. Mais, à titre d'exemple, la plupart des entreprises ont également des applications qui sont déployées et ne sont touchées qu'une fois tous les quelques années. Cela fonctionne mal avec .NET Core. Ici, les entreprises doivent lutter avec des cycles de support courts pour la plupart des versions. Et comme Windows, il n'existe actuellement aucun mécanisme pour installer automatiquement les nouvelles versions de correctifs pour obtenir les mises à jour de sécurité, etc.

Les entreprises qui lancent de nouveaux projets se demandent donc quoi faire. Le .NET Framework, plus convivial pour l'entreprise, montre des signes assez clairs de dépréciation, et donc quelque chose de mieux évité pour un nouveau développement. D'autre part .NET Core existe mais est nettement moins convivial pour l'entreprise.

Donc, cela est essentiellement devenu une diatribe, mais j'espère que cela illustre mieux les préoccupations de nombreux développeurs.

@davidfowl

Mais, il existe également de nombreux services que nous avons créés pour tirer parti d'AspNetCore qui reposent également sur des éléments tels que System.DirectoryServices et System.Drawing

Ceux-ci existent dans le pack compact Windows sur .NET Core https://docs.microsoft.com/en-us/dotnet/core/porting/windows-compat-pack.

Je ne savais pas que le pack de compatibilité prenait en charge ce cas d'utilisation. Idéalement, nous aimerions tout faire avancer vers .NET Core, et cela semble être une très bonne réponse (que nous avons peut-être négligée au départ). Nous n'avons pas l'intention de déplacer l'hébergement de nos services vers Linux / OSX, donc ces éléments pourraient bien s'harmoniser pour nous.

Serait-ce également le cas si le soutien était prolongé?

En termes de support, j'ai le sentiment que le LTS de 2.x jusqu'en 2021 est raisonnable, compte tenu de toutes les autres contraintes liées à quelque chose d'aussi vaste.

Sur la base de ce que je comprends maintenant, nous nous sentirons probablement à l'aise de passer à AspNetCore 3.x une fois que nous aurons l'occasion de passer en revue et de convertir des projets .NET Framework en projets .NET Core (avec l'utilisation du pack de compatibilité si nécessaire).

Merci pour votre suivi.

J'ai écrit en .NET (principalement C #) pendant 15 ans dans des projets à haute pression. J'ai perdu tant d'années et de l'argent des clients en utilisant un cadre sur-conçu. J'ai adoré le concept de .NET Core. Pour moi, c'était la vitesse d'écriture des projets NodeJS mais dans l'incroyable écosystème .NET (y compris toute la graisse). Malheureusement, il a échoué sur cette promesse, c'est toujours (même avec cette nouvelle annonce) beaucoup trop compliqué pour une utilisation sanglante. Depuis 3 ans, je construis dans NodeJS, désolé les gars, ce n'est tout simplement pas comparable. Rendez-le plus simple et plus facile à utiliser et vous attirerez à nouveau la vaste communauté de développeurs.

Pour les projets avec des dépendances .NET Framework binaires compilées et difficiles (des éléments du fournisseur sans code source) qui peuvent s'exécuter dans les applications ASP.NET Core 2.1 ciblant .NET Framework déployées sur Windows, l'ajout du pack de compatibilité Windows au projet permettra de continuer à travailler sur Core 3.0 si les dépendances matérielles font référence aux types fournis par le pack?

Il existe un énorme écosystème de bibliothèques commerciales extrêmement matures qui ont malheureusement des dépendances sur System.Drawing, GDI et parfois le registre (!). Si ceux-ci ne fonctionnent que maintenant avec 2.1 et ne sont pris en charge que pendant trois ans, il s'agit d'un problème qui pourrait interrompre l'adoption de Core dans certaines entreprises.

.NET Core fait un cercle complet pour atteindre le point de départ.

Je suggérerais une autre approche: laisser .NET Framework incorporer les fonctionnalités utiles de .NET Core, puis éliminer complètement .NET Core en tant que branche expérimentale sans issue. Arrêter ainsi la segmentation et sauvegarder la technologie pour le plus grand bénéfice des clients. Approche quelque peu controversée, mais beaucoup plus saine du point de vue du produit.

@davidfowl

ASP.NET Core fonctionnant sur .NET Framework n'a jamais été censé être une chose permanente, il a toujours été conçu comme un tremplin

Ce n'est tout simplement pas vrai du tout. Le message sur ASP.NET Core a toujours été qu'il est pris en charge à la fois sur .NET Core et .NET Framework. Même les premières annonces de .NET Core mentionnent les deux plates-formes pour ASP.NET Core (à l'époque ASP.NET 5).

L'image très connue qui montre .NET Standard a également ASP.NET Core couvrant à la fois Core et le framework complet. Et la documentation officielle dit même: «Il n'est pas prévu de supprimer la prise en charge du ciblage de .NET Framework dans ASP.NET Core.»

Alors oui, il est évident que cette décision a changé maintenant , mais dire que c'était toujours comme ça est soit juste un mensonge, soit une très mauvaise communication faite par Microsoft au fil des ans .

ça s'appelle même ASP.NET Core

Oh allez. Après tout ce temps, des gens comme moi ont dû se battre pour séparer .NET Core et ASP.NET Core parce qu'ils ne sont

c'est là qu'intervient le support LTS étendu. Si l'application ne peut jamais passer à .NET Core même après ces 6 ans […]

D'où cela vient-il même maintenant? La dernière fois, le message était toujours «nous étudions une offre LTS« support étendu »» . Est-ce une chose réelle maintenant et nous obtenons 6 ans?

@pjmlp

Le petit détail que vous oubliez est que Java, et d'autres piles, sont toujours compatibles entre les versions contrairement à .NET Framework et .NET Core sans avoir besoin d'une norme qui n'est que partiellement implémentée dans les implémentations d'exécution.

C'est juste, mais je ne comprends pas ce que cela a à voir avec un meilleur soutien. L'affirmation a été faite que le passage à Java serait mieux en raison de bibliothèques moins paralysées (ce qui est un problème ponctuel) et d'un support d'entreprise (cycle de support plus long).

@KevinCathcart

Les messages de ce fil de discussion suggèrent que Microsoft commence à considérer le .NET Framework comme une fonctionnalité héritée, quelque chose qui attirera de moins en moins l'attention du développement au fil du temps, jusqu'à ce qu'il n'obtienne vraiment que des correctifs de sécurité.

Microsoft a toujours été horrible de savoir clairement ce qu'il développe activement, ce qu'il ne fait que maintenir avec de nouvelles fonctionnalités sporadiques et ce qu'il prévoit de fournir uniquement des correctifs de sécurité et de stabilité. Il me semble que le .NET Framework n'est pas seulement dans cette deuxième catégorie maintenant, mais est vraiment proche de la troisième catégorie.

Voir https://blogs.msdn.microsoft.com/dotnet/2018/10/04/update-on-net-core-3-0-and-net-framework-4-8/

Pour les projets avec des dépendances .NET Framework binaires compilées et difficiles (des éléments du fournisseur sans code source) qui peuvent s'exécuter dans les applications ASP.NET Core 2.1 ciblant .NET Framework déployées sur Windows, l'ajout du pack de compatibilité Windows au projet permettra de continuer à travailler sur Core 3.0 si les dépendances matérielles font référence aux types fournis par le pack?

Oui, c'est compatible binaire.

Il existe un énorme écosystème de bibliothèques commerciales extrêmement matures qui ont malheureusement des dépendances sur System.Drawing, GDI et parfois le registre (!). Si ceux-ci ne fonctionnent que maintenant avec 2.1 et ne sont pris en charge que pendant trois ans, c'est un problème qui pourrait arrêter l'adoption de Core dans certaines entreprises

Comme je l'ai mentionné à plusieurs reprises sur ce fil. Nous avons ajouté la possibilité de référencer directement les dépendances compilées avec .NET Framework sur les projets .NET Core.

@poke Vous avez raison sur le message, ce n'était pas du tout clair, mon erreur.

D'où cela vient-il même maintenant? La dernière fois, le message était toujours «nous étudions une offre LTS« support étendu »». Est-ce une chose réelle maintenant et nous obtenons 6 ans?

J'en ai composé 6, je ne sais pas à quel point le support sera étendu lorsque nous l'offrirons.

.NET Core allait toujours remplacer .NET Framework (à l'origine, il allait être .NET Framework 5), mais la réécriture était si ambitieuse qu'elle est maintenant utilisée pour prendre en charge les applications de bureau.

Wow, y a-t-il déjà beaucoup de commentaires hilarants ici. Il semble qu'il y ait beaucoup de rage nerd mal placée, entrecoupée de personnes qui ne lisent pas l'article.

Etre prêt

@edandersen avez-vous exécuté ApiPort sur ces dll externes? Il vous montrera s'ils utilisent des API qui ne sont pas disponibles sur .NET Core. S'il n'utilise que les API disponibles, cela ne devrait pas poser de problème, sinon, savoir quelles API sont manquantes facilite la discussion et la hiérarchisation des fonctionnalités.
Le pack de compatibilité Windows fournit déjà des fonctionnalités pour system.drawing et le registre. Avez-vous déjà essayé d'exécuter ces éléments sur .NET Core? System.Drawing fonctionne même sur * nix en utilisant le libgdiplus de mono. Cela nous permet d'utiliser ClosedXML sur des systèmes non Windows pour travailler avec des fichiers Excel.

La plus grande dépendance de .NET Framework pour les applications «récentes» de notre entreprise est la fonctionnalité WCF.
Les bibliothèques clientes .NET Core WCF s'améliorent. Je n'ai pas vérifié l'état actuel de leur fonctionnement avec certains services que nous consommons, mais dans le passé, nous ne pouvions pas parler à certains services. Mais la fonctionnalité manquante était déjà dans leur liste de problèmes. Les services simples fonctionnent bien en revanche!
D'un autre côté, il n'y a pas de remplacement «en baisse» pour l'hébergement de services SOAP dans .NET Core. Cela bloquerait la migration de certaines applications vers .NET Core (mais comme mentionné, ce n'est pas nécessaire).
Pour une application ASP.NET Core récente, nous avons créé une application Web proxy ASP.NET supplémentaire qui héberge simplement un service WCF, puis la transmet à l'application ASP.NET Core via HTTP / JSON. Pas très joli et ajoute de la complexité de déploiement mais cela permet quelques points d'intégration.

Je ne dis pas que je veux vraiment la capacité d'hébergement WCF dans .NET Core, étant donné que j'ai des maux de tête en la configurant. Une certaine option pour héberger les services SOAP et générer WSDL serait cependant cool. J'ai déjà vu quelques bibliothèques OSS essayer de le faire. Peut-être que cela suffira.

@ davidfowl

C'est juste, mais je ne comprends pas ce que cela a à voir avec un meilleur soutien. L'affirmation a été faite que le passage à Java serait mieux en raison de bibliothèques moins paralysées (ce qui est un problème ponctuel) et d'un support d'entreprise (cycle de support plus long).

Le fait est que bien que les versions Java LTS durent également trois ans, la compatibilité entre toutes les principales implémentations est dorée, ce que vous êtes prêt à jeter par la fenêtre ici.

L'ensemble de ces faux pas .NET Framework, .NET Core, Xamarin, .NET Standard commence à ressembler au bon vieux temps de WinDev vs DevTools, juste à l'intérieur des équipes .NET pour un changement.

Les clients sont donc naturellement prêts à passer à des plates-formes qui ne ressemblent pas à des équipes internes qui se battent pour les fonctionnalités de la feuille de route.

Ces décisions n'inspirent pas confiance.

Cela ressemble vraiment à une erreur de la part de l'équipe .NET, en particulier dans le contexte du climat actuel!

Pour ceux qui mentionnent Java, avez-vous regardé ce qui se passe là-bas récemment? Entre leur procès absolument insensé contre Google pour son utilisation dans Android et leurs dernières manigances de licences, le comportement d'Oracle semble toujours être celui d'une entreprise qui veut tuer un produit indésirable, plutôt que celle qui veut qu'il prospère!

C'est le moment idéal pour Microsoft de capitaliser sur cela avec un marketing puissant suggérant qu'il fait exactement le contraire, et que .NET est l'endroit idéal pour des options de développement saines, stables et sûres. Au lieu de cela, nous obtenons ... ceci. :désappointé:

@masonwheeler

Nous qui travaillons dans les deux environnements apprécions réellement le travail d'Oracle
a fait avec Java.

Ce sont ceux qui utilisent rarement Java en production, méprisent Oracle, qui
perdu dans les arguments de haine contre eux.

En ce qui concerne Android, je soutiens pleinement le procès, car Google
a réussi à bifurquer la plate-forme Java, réussissant ainsi là où Microsoft a échoué
avec J ++. Nous attendons toujours avec impatience le jour où tout JAR aléatoire dans Maven Central fonctionnera réellement sur Android.

Quant à .NET, je commence à en avoir assez des redémarrages continus de
comment nous sommes censés cibler les plates-formes Microsoft.

L'ensemble de WinRT, UAP, UWP, .NET Native abandonnant F #, XNA, Core 1.0 est parti
beaucoup de raisins aigres et cette décision récente n'améliore pas les choses
global.

.NET est ma plate-forme préférée, alors ne le gâchez pas encore plus.

@mythz

Maintenant, je comprends que 2.1 étant la dernière version LTS prise en charge sur .NET Framework signifie qu'il n'y a pas de place pour mettre à niveau vers

Ce qui signifie qu'il est devenu une plate-forme non prise en charge, tout le monde doit la traiter comme de la lave et se démener pour en sortir avant qu'elle n'atteigne sa fin EOL non prise en charge.

C'est l'un des points que je ne comprends pas vraiment dans toute la discussion. Que retirez-vous réellement du support LTS à part les correctifs de sécurité (qui pourraient être couverts par le support LTS étendu)?

Dans le support LTS traditionnel, il n'y a que deux choses à attendre:

• Correctifs de sécurité
• Corrections de bogues critiques

La plupart des anciens (correctifs de sécurité) seront corrigés via Windows Update (puisque vous ciblez .NET Framework). Ainsi, seuls les correctifs de sécurité et de bogues critiques restants sont ceux d'ASP.NET Core lui-même.

Disons qu'il sait déjà que le support se termine en 2018, je ne m'attendrais pas à ce que quelqu'un commence de nouveaux projets en 2020, il est donc (à mon humble avis) peu probable que vous trouviez un bogue critique après 2021 (ou 2026 ou combien de temps le support étendu est-il prévu. être).

Cela laisse juste les bogues de sécurité ouverts, ce qui est raisonnable à couvrir avec LTS.

Dans les réponses précédentes, j'ai vu mentionner TLS 1.4, etc., ils ne seraient de toute façon pas couverts dans un LTS car c'est une nouvelle fonctionnalité de toute façon, ce qui est identique même pour Java (Java 6 n'a que le support TLS 1.0 - TLS 1.1 si vous comptez dans le mises à jour non publiques uniquement disponibles pour les abonnés Oracle Extended Support).

• Quiconque a pensé à l'utiliser comme plate-forme intermédiaire pour passer à .NET Core est devenu une option moins faisable car il court le risque d'être bloqué sur une plate-forme non prise en charge si la migration prend plus de temps que prévu ou s'il rencontre des obstacles si l'une des dépendances ils comptent sur ne peuvent pas fonctionner sur .NET Core.
  Mais quelles API sont celles qui manquent que vous pouvez désormais utiliser avec ASP.NET Core sur .NET Framework, mais pas sur ASP.NET Core sur les packages de compatibilité .NET Framework +?

Je pense que c'est le point le plus critique ici, d'identifier ceux-ci et d'expédier les API manquantes avec les futurs packages de compatibilité ou de les ajouter à .NET Core, ce qui permet de référencer les bibliothèques .NET Framework même lorsque vous ciblez .NET Core.

Depuis .NET Core, vous pouvez référencer (et utiliser) n'importe quelle bibliothèque .NET Framework dans un projet .NET Core tant qu'elle n'utilise que les API disponibles dans .NET Standard ou .NET Core .

Cela ne nécessite pas que l'auteur de la bibliothèque mette à jour ses bibliothèques pour cibler netstandard / netcoreapp.

Peut-être que cela aiderait si Microsoft étendait la page Web / bibliothèque NuGet par une fonctionnalité / un lien à côté de chaque package nuget sur nuget.org qui affiche un rapport si cette bibliothèque utilise des API incompatibles non disponibles dans des versions spécifiques de .NET Core?

Par exemple

'Company.Example.MyLib` afficherait

• .NET Core 2.1: support partiel (rapport détaillé) - où le rapport détaillé montrerait Apis qui fonctionne et ce qui ne fonctionne pas
• .NET Core 3.0 :; entièrement pris en charge

Cela devrait être possible en exécutant l'analyseur de portabilité .NET? Un bonus serait, s'il ajoute une liste d'API publiques qui peuvent être appelées en toute sécurité (en analysant le code IL et voir quelles autres API son appel pour s'assurer qu'elles sont sûres ou non)?

Cela permettrait au moins aux développeurs de déterminer plus facilement si une bibliothèque spécifique dont ils ont besoin pour leur projet peut s'exécuter sur .NET Core ou pas même si elle ne l'appelle pas explicitement?

Pour le moment, c'est un peu pénible de comprendre que si les API sont prises en charge ou non, vous avez besoin de la bibliothèque, exécutez l'analyseur localement dessus. De nombreux développeurs ne savent peut-être pas qu'ils peuvent utiliser certaines des bibliothèques qui ne prennent pas officiellement en charge netstandard.

@davidfowl @terrajobst Serait-ce un ajout réalisable à NuGet? Pour faciliter et accélérer la découverte des bibliothèques .NET Framework compatibles avec -NET Core?

• Quiconque est obligé d'utiliser les serveurs .NET Framework de l'infrastructure gérée existante de son entreprise ne peut pas participer à l'utilisation du nouveau modèle de développement et de l'écosystème et doit voir ses connaissances / compétences ASP.NET classiques existantes devenir moins précieuses chaque jour.

Ce n'est guère un argument pour ou contre le support de .NET Framework ou non. Les personnes qui sont bloquées sur des dépendances héritées et ne peuvent pas migrer vers .NET Core (avec le pack de compatibilité ou avec les bibliothèques .NET Framework) ne pourront pas faire ni après. Comment cela changerait-il quelque chose?

Néanmoins, certaines parties des applications monolithiques peuvent être séparées et déplacer progressivement des parties de l'application héritée vers une nouvelle, mais c'est une autre histoire.

• Aucune organisation ne souhaite être contrainte à une migration non planifiée car les conseils sur lesquels elle s'est appuyée pour fonder son budget, sa planification et ses décisions d'investissement ont changé.

Si les avantages l'emportent sur les investissements, pourquoi pas? c'est-à-dire s'il y a des fonctionnalités uniques qui vous donnent une grande valeur en retour ou une énorme augmentation des performances.

Sinon, restez sur l'ancien système. Le développement logiciel a toujours été comme ça. Il existe encore des sociétés exécutant des logiciels développés dans Fortune et Cobol.

Il y a beaucoup de gens qui ne peuvent ou ne veulent pas passer à .NET Core, ils veulent qu'il partage le même niveau de prise en charge que ASP.NET classique (ce que la messagerie actuelle suggère indéfiniment).

Les API manquantes ne sont pas la seule raison qui empêche la migration, par exemple, elles pourraient s'appuyer sur une dépendance où l'équipe de développement l'a créée n'existe plus, c'est un composant critique qui ne peut pas être modifié, il ne peut pas être refactorisé en toute sécurité (par exemple, aucun test), il est partagé avec d'autres systèmes .NET FX uniquement, il est maintenu par un autre service qui n'a pas de budget, de capacité à le modifier ou en raison de facteurs externes tels que l'infrastructure gérée par leur entreprise ne prend en charge que les serveurs .NET Framework.

Oui mais quelles dépendances? Des exemples concrets seraient nécessaires pour identifier les API utilisées par ces dépendances externes. Cette API pourrait être ajoutée à .NET Core 3.0 ou à une future version de .NET Core.

Cela permet d'utiliser cette bibliothèque .NET Framework dans des projets .NET Core. Le seul problème est lorsque les bibliothèques .NET Framework utilisent des API qui ne sont pas disponibles dans .NET Standard ou .NET Core. Mais pour résoudre ce problème, des commentaires sont nécessaires pour identifier les bibliothèques.

@pjmlp

@davidfowl

D'autres pourraient également choisir une autre pile alternative.

C'est juste, mais les piles alternatives ont la même politique de support. Java est passé à un modèle LTS similaire (https://www.oracle.com/technetwork/java/javase/eol-135779.html).

Le petit détail que vous oubliez est que Java, et d'autres piles, sont toujours compatibles entre les versions contrairement à .NET Framework et .NET Core sans avoir besoin d'une norme qui n'est que partiellement implémentée dans les implémentations d'exécution.

Ce n'est pas tout à fait vrai pour les éditions Java ultérieures non plus. Java 9 a ajouté la première étape pour modulariser le runtime, ce qui est un changement radical . Dans la version 9, cela a été désactivé par défaut, mais dans les versions futures, l'indicateur sera activé par défaut (ou ne pouvant pas le désactiver), ce qui crée des modifications radicales dans les applications héritées.

Par exemple, pour les nombreuses bibliothèques qui utilisent des API internes grâce à une certaine réflexion, la magie peut et va rompre avec ce changement. Et beaucoup de ces bibliothèques, comme dans le monde .NET, ne sont plus maintenues, donc des mises à jour ne sont pas à prévoir.

@ TsengSR

Malgré les changements de rupture introduits dans Java 9, 100% de tous les frameworks Java pertinents fonctionnent sur Java 9, 10 et 11, ce qui n'est certainement pas le cas dans .NET Framework, UWP et Core.

Imaginez que même il existe deux frameworks d'interface graphique multiplateformes officiels, alors que nous n'avons toujours pas de feuille de route officielle pour Core!

@pjmlp

@ TsengSR

Malgré les changements de rupture introduits dans Java 9, 100% de tous les frameworks Java pertinents fonctionnent sur Java 9, 10 et 11, ce qui n'est certainement pas le cas dans .NET Framework, UWP et Core.

Imaginez que même il existe deux frameworks d'interface graphique multiplateformes officiels, alors que nous n'avons toujours pas de feuille de route officielle pour Core!

Désolé, c'est complètement absurde.

Les modules internes de Java 9, qui empêchent de refléter dans ces modules à moins que --add-opens soit appelé (et iirc c'était toujours censé être une solution temporaire afin que les gens puissent continuer à exécuter leur application héritée et supprimer quelques versions plus tard).

Au cas où vous auriez manqué le drame et le shitstrom lorsque Java 9 était sur le point d'être réalisé, voici la réponse:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

Pour aider l'ensemble de l'écosystème à migrer vers la plate-forme Java modulaire à un
rythme plus détendu Je propose par la présente d'autoriser un accès réflexif illégal
à partir du code sur le chemin de classe par défaut dans JDK 9, et de l'interdire dansune version future.

Autre chose, Java EE 9, déprécié, JAX-WS a été déprécié et doit être supprimé dans Java EE 11. Cela pourrait être considéré à peu près comme l'équivalent de WCF. Tout élément applicable qui l'utilise ne peut pas non plus être porté vers une version plus récente sans le remplacer par quelque chose d'autre, qui est un processus de migration. Pas plus ou moins différent que la migration d'ASP.NET Core sur .NET Framework vers ASP.NET Core sur .NET Core (ou d'ASP.NET vers ASP.NET Core @ .NET core)

https://www.oracle.com/corporate/features/understanding-java-9-modules.html

Meilleure intégrité de la plate-forme: avant Java 9, il était possible d'utiliser de nombreuses classes de la plate-forme qui n'étaient pas destinées à être utilisées par les classes d'une application. Avec une forte encapsulation, ces API internes sont vraiment encapsulées et cachées des applications utilisant la plate-forme. Cela peut rendre problématique la migration du code hérité vers Java 9 modulaire si votre code dépend d'API internes.

Toute application qui utilisait ces API internes (y compris tout dans l'espace sun.* noms

@TsengSR

Les modules internes de Java 9, qui empêchent de refléter dans ces modules à moins que --add-opens soit appelé (et iirc c'était toujours censé être une solution temporaire afin que les gens puissent continuer à exécuter leur application héritée et supprimer quelques versions plus tard).

Ou vous pouvez utiliser le mode classpath et ignorer le désordre qu'est les modules. Ce mode restera dans un avenir prévisible. Et si vous entrez dans des modules, vous pouvez déclarer explicitement les dépendances dans les packages d'autres modules.

Autre chose, Java EE 9, déprécié, JAX-WS a été déprécié et doit être supprimé dans Java EE 11. Cela pourrait être considéré à peu près comme l'équivalent de WCF.

Tout J2EE a été abandonné et supprimé dans Java 11, qui est déjà sorti. Mais J2EE ne définit que les interfaces, pas l'implémentation. Pour continuer à utiliser J2EE, ce que je fais, il vous suffit de changer de dépendances. Toutes les implémentations étaient de toute façon séparées et fonctionnent correctement dans Java 11.

Toute application qui utilisait ces API internes (y compris l'espace de noms all in sun. * Que certaines des anciennes bibliothèques utilisaient - ou utilisait à l'époque lorsque Java 9 était sur le point de sortir) ou utilise une bibliothèque tierce qui dépend de ces API ou une autre bibliothèque peut être soumise à ce changement radical.

Cela a toujours été le cas. C'étaient des API non documentées. Personne n'aurait dû les utiliser et ils auraient pu être modifiés ou supprimés à tout moment. La plupart des API internes couramment utilisées (ab) ont été laissées pour ne pas interrompre les programmes existants, afin qu'ils puissent migrer vers les API appropriées à l'avenir.

Certaines API sont obsolètes, mais nous parlons d'API spécifiques et non de l'intégralité de l'écosystème JRE ou Java. Le travail nécessaire pour passer de ces API à des API plus récentes, officielles et documentées est généralement minime.

Et Java a toujours été plus disposé à rompre la rétrocompatibilité que .NET. Par exemple, en Java, il est désormais illégal de déclarer un type nommé var car il est réservé pour l'inférence locale. En Java, il est illégal de nommer une variable _ car elle est réservée pour une utilisation en tant que joker / joker. C # a pris la décision exactement opposée dans les deux cas, au nom de la préservation de la compatibilité descendante.

Ne vous méprenez pas, Java est son propre désordre. Entre les modules, la prise en charge de Java 8 touche à sa fin et Oracle devient gourmand avec les licences JRE, il existe une énorme opportunité pour Microsoft de convertir les gens. Mais il est très peu probable que cela se produise si Microsoft veut diffuser des messages contradictoires concernant le support futur et l'évolution de leurs plates-formes.

@TsengSR

C'est l'un des points que je ne comprends pas vraiment dans toute la discussion. Que retirez-vous réellement du support LTS à part les correctifs de sécurité (qui pourraient être couverts par le support LTS étendu)?

Il y a une horloge sur cette LTS qui va se terminer sans aucun endroit

Je ne sais pas quelle serait la métaphore la plus proche de cette décision dans Java Land, forçant peut-être les systèmes existants à migrer vers GraalVM, beaucoup de choses fonctionneront, certaines ne fonctionneront pas, plus le système est grand, moins il est sûr de pouvoir prédire la compatibilité / problèmes jusqu'à ce qu'une migration soit physiquement tentée.

Je conviens que beaucoup a été fait pour rendre les migrations vers .NET Core possibles, mais il y aura toujours un certain nombre de facteurs externes (inc en dehors du contrôle de MS) qui vont empêcher les migrations et cette décision ne fera que prendre migrations moins probables qu'avant cette annonce ASP.Core / FX était une voie de migration populaire, mais il ne sera plus prudent de recommander une stratégie de migration globale incluant la migration vers une future plate-forme non prise en charge, ce qui évitera de nombreuses migrations de se produire, ce qui a pour effet de laisser plus de systèmes / développeurs existants sur ASP.NET classique stagné.

La plupart des anciens (correctifs de sécurité) seront corrigés via Windows Update (puisque vous ciblez .NET Framework). Ainsi, seuls les correctifs de sécurité et de bogues critiques restants sont ceux d'ASP.NET Core lui-même.

Les organisations ne veulent pas baser leur entreprise sur une plate-forme partiellement prise en charge dans l'espoir que de futurs bogues ou problèmes de sécurité ne se produiront que dans les bibliothèques réservées au support. Cela irait très loin si ASP.Core / FX était couvert par le même niveau de support que le reste de .NET Framework où toutes les vulnérabilités de sécurité futures seront résolues.

Actuellement, seul MS sera en mesure de patcher et de publier des packages ASP.Core NuGet mis à jour, avec l'arborescence des dépendances d'interconnexion étant OSS n'aidera pas beaucoup ici à moins que les PR 2.1 qu'ils reçoivent (post LTS) soient examinés, acceptés et libéré.

En fin de compte, après que tous les détails ont été discutés, la question ultime qui compte toujours est:

Pouvons-nous continuer à exécuter nos systèmes existants sur ASP.Core / FX?

Techniquement, cela sera possible, mais sans l'assurance que les futurs bogues critiques / vulnérabilités de sécurité seront résolus, la recommandation est devenue NON, laissant l'écosystème externe affecté absorbant la douleur de cette décision.

Si ASP.NET Core doit être uniquement .NET Core, que devrions-nous penser de l'ensemble de .NET Standard?

Si Microsoft lui-même ne parie pas dessus pour des raisons (sans aucun doute valables), pourquoi le devrions-nous?

Y aura-t-il des bibliothèques .NET Core de première classe et de pointe uniquement et des bibliothèques .NET Standard «plus simples» et moins avancées?

Cela semble tuer le lecteur pour améliorer les plates-formes non .NET-Core.

J'espère que quelqu'un pourra me montrer que je me trompe et apaiser mes inquiétudes.

Salut,
Je vois l'intérêt d'aller de l'avant et j'adore ça, mais je vois 3 problèmes principaux à propos de cette décision:
1) netstandard sera un citoyen de deuxième classe si personne dans Microsoft ne construit quelque chose de difficile avec lui, si vous ne faites pas de dogfood, comment pouvez-vous demander à d'autres développeurs de le faire? Aujourd'hui, les auteurs de bibliothèques doivent travailler très dur, le support ne s'améliorera pas si les personnes internes n'utilisent pas le standard.
2) il est utile d'exécuter aspnet core dans d'autres runtimes.
3) il y a une valeur dans un logiciel fonctionnant dans d'anciens environnements d'exécution (avec une dépendance qui ne sera jamais touchée) qui ne devrait pas être écartée à la légère.

Ensuite, il y a la communication: je pense que tout le monde aimerait juste un runtime .net qui fonctionne partout, mais c'est une utopie pour un avenir prévisible et netstandard a été créé comme substitut. De mon point de vue, tout projet qui ne cible pas netstandard mais une plateforme est un pas qui ne va pas dans le sens de cette vision.
Il est clair que le framework .net est en mode maintenance, .netcore prendra sa place (laissant un cadavre derrière) et mono fonctionnera sur les appareils, une histoire et CoreRT ne cherchent pas à avancer.

Avec netcore 3.0, vous faites deux choses à la fois: prendre en charge les charges de travail de bureau et «dire au ppl de sauter tout de suite pour rester pertinent». Je pense que cela nécessitera un acte de foi de la part des développeurs et c'est beaucoup trop optimiste car tout le monde sait que de nombreux projets ne seront pas migrés en raison de certaines dépendances manquantes, qui seront probablement ajoutées dans les futures versions 3.1 / 3.2 dans 1-2 ans ( très proche des 3 années LTS de 2.1). En attendant, les développeurs qui veulent être pertinents sont bloqués pour utiliser les bits 3.0 en raison de dépendances sur lesquelles ils n'ont aucun contrôle.

Sera-t-il possible de reporter cette décision après que les gens l'auront testée et en verront les implications réelles?
Est-il possible d'avoir aspnet core compilé à la fois sur netstandard et netcoreapp comme vous prescrivez aux auteurs de bibliothèques de le faire? Il est normal d'avoir une performance dégradée fonctionnant sur le framework .net 😄

Roslyn fonctionne maintenant sur .NETStandard 2.0 -> https://github.com/dotnet/roslyn/pull/30914

Cela compte certainement comme quelque chose de difficile!

@davidfowl

Je crois que cela va commencer à limiter sévèrement les options pour le développement futur des systèmes .Net Framework qui ne peuvent pas migrer pour diverses raisons, car la communauté transfère ses efforts vers ASP.Net Core.

Par exemple, Identity Server est déjà passé à ASP.Net Core et le récent article sur l' avenir de SignalR a déclaré sans surprise que ASP.Net Core SignalR sera le futur objectif de l'effort de développement, avec ASP.Net SignalR étant en mode maintenance - ce qui au moment indiqué, il prendra en charge .Net Framework et .Net Core et je pense que c'est une tendance que nous continuerons à voir.

Je sais que le support LTS pour ASP.NET Core était déjà fixé à 3 ans, mais pour le déploiement sur site, un cycle de vie plus long est nécessaire car nous devons fournir un support dans ce sens (4 ans) à nos clients.
Pendant cette période, nous devons être en mesure de publier des correctifs qui incluent des correctifs de sécurité sans aucune modification majeure de l'application. Il s'agit de rester en phase avec les processus de contrôle des modifications de nos clients qui nécessiteraient des tests d'acceptation des utilisateurs approfondis de leur part pour des changements plus importants et afin que nous n'ayons pas à effectuer de changements majeurs tels que la migration vers une version plus récente sur les versions qui sont en mode maintenance. .

Y a-t-il une chance que la politique LTS change? quelque chose comme la stratégie d'Ubuntu d'une version LTS tous les 2 ans avec 5 ans de support - bien que j'en demande 6 afin de permettre à la version actuelle d'avoir plus de 3 ans de support pendant que le travail de migration vers la nouvelle version est entrepris.

Je comprends que le support étendu a été mentionné, mais je suppose que c'est quelque chose que chacun de nos clients devrait acheter, ce qui, je ne pense pas, serait acceptable si leur installation initiale (après le développement, le processus de vente, UAT, etc.) l'a au mieux 2 ans d'accompagnement.

Aussi, curieux de savoir comment traiter la bibliothèque .netstandard en .netcore 3.0 fois.
Le slogan de .netstandard est "Une bibliothèque pour les gouverner tous".
Avant cela, il semble que cela signifie tout.
Après cela, il semble que cela signifie un peu.

Juste pour montrer les conséquences de cette décision - qu'en est-il de Blazor? Arrêtera-t-il d'être basé sur, netstandard? Devrions-nous nous attendre à cela aussi?

Quelqu'un peut-il clarifier cela?

Est-ce donc la recommandation pour les bibliothèques comme Newtonsoft.Json (qui peuvent bénéficier de hautes performances) de passer à .NET Core plutôt que .NET Standard? Je ne vois pas beaucoup de distinction entre ce type de bibliothèque et ASP.NET Core. Nous intégrons les services REST dans des applications plus volumineuses - dont certaines peuvent facilement passer à .NET Core et d'autres non.

Dans ma compréhension, la recommandation pour les bibliothèques est de cibler à la fois .NET Core 3 et .NET Standard 2.x si vous souhaitez bénéficier des avantages des nouvelles API mais ne voulez pas perdre d'audience.

Dans ma compréhension, la recommandation pour les bibliothèques est de cibler à la fois .NET Core 3 et .NET Standard 2.x si vous souhaitez bénéficier des avantages des nouvelles API mais ne voulez pas perdre d'audience.

Je pensais que la route à suivre était la norme partout , et actuellement, nous sommes juste dans une transition. Mais avec un mouvement comme celui-ci, d'autres suivront (ou devront) suivre et nous revenons au multi-ciblage.

.NET Framework et .NET Core remplissent le même rôle, donc je pense qu'il est à peu près prévu qu'ASP.NET Core ne fonctionnera pas un jour sur .NET Framework, que ce soit maintenant ou plus tard.

Cependant, je vois un gros problème en ne fonctionnant pas sur .NET Standard X . Pour être honnête, je n'ai pas besoin du noyau asp.net pour fonctionner sur xamarin ou unity, mais c'est bien de pouvoir dire que c'est possible - c'est juste un autre ensemble de bibliothèques qui fonctionne sur la plate-forme .NET. En rompant, nous obtenons une intégration plus étroite entre .NET Core et ASP.NET Core et j'ai peur que par .NET Core 4.5 nous condamnons Microsoft.AspNetCore et @davidfowl à partir de DNX 2.0.

D'un autre côté .NET Standard n'est certainement pas un endroit pour expérimenter et il est difficile de faire entrer les choses correctement, alors pouvons-nous peut-être obtenir un compromis? Serait-il possible d'avoir ASP.NET Core ciblant actuellement uniquement .NET Core, mais des versions LTS ciblant .NET Standard? Si une API ne parvient pas à .NET Standard, cela vaut-il vraiment la peine de l'utiliser?

Nous pourrions également voir cela de la manière dont vous avez probablement l'intention de:

• .NET Core est pour console / web / bureau tiers (API standard + web spécifique)
• Unity est pour les jeux (API standard + spécifique au jeu)
• Xamarin est pour les appareils / bureau (API standard + appareil / bureau spécifique)

Mais qui fait avancer .NET Standard? Comme vous l'avez dit auparavant, les ressources sont limitées, donc sans avoir vraiment besoin de pousser les choses (ce qui, dans ma proposition, tomberait sur l'équipe principale de .net core / asp.net en ayant besoin de modifications pour publier LTS), j'ai peur. NET Standard deviendra rapidement obsolète.

Pour ceux qui ne font pas attention, il semble que .NET Standard 2.1 vient de supprimer la prise en charge de .NET Framework.

Étant donné que de nombreux ajouts d'API dans .NET Standard 2.1 nécessitent des modifications d'exécution pour être significatifs, .NET Framework 4.8 restera sur .NET Standard 2.0 plutôt que d'implémenter .NET Standard 2.1. .NET Core 3.0 ainsi que les versions à venir de Xamarin, Mono et Unity seront mis à jour pour implémenter .NET Standard 2.1.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Même si cela me fait mal de voir le .Net Framework obtenir Silverlight, ce qui m'importe par rapport à ASP.NET Core, c'est qu'il devrait cibler .NET Standard .

En tant que ce qui est probablement l'une des applications de référence les plus importantes de l'écosystème Core / Standard, je crois qu'ASP.NET Core a la responsabilité d'être un champion de .Net Standard et de toutes les bonnes choses qu'il représente.

Je pense qu'il est raisonnable pour ASP.NET Core de demander des modifications à la norme qui sont ensuite implémentées dans .NET Core.

De la même manière que Span etc _est_ disponible dans .Net Framework via un package nuget, je pense qu'il est raisonnable que si ASP.NET Core a besoin / veut dépendre de quelque chose qui n'est pas encore dans le .Net Standard, cette dépendance devrait être incluse via un package nuget.

Enfin, j'espère (contre toute preuve du contraire), qu'il y aura un .Net Framework 5.0 qui ciblera .Net Standard 3.0+ et sera une installation côte à côte avec 4.x.

Enfin, j'espère (contre toute preuve du contraire), qu'il y aura un .Net Framework 5.0 qui ciblera .Net Standard 3.0+ et sera une installation côte à côte avec 4.x.

Oui, exactement. C'est ce que je dis depuis des années maintenant: l'architecture CLR 2.0 nous a bien servi pendant longtemps, mais cela commence à être long dans la dent, et il est temps pour une mise à niveau fondamentale du même type que Generics. Il peut être quelque peu douloureux d'apporter les modifications nécessaires, mais elles sont nécessaires; la mise à jour avec de nouvelles fonctionnalités plus puissantes est nécessaire de la même manière que les génériques étaient nécessaires, et le remettre à plus tard ne fera qu'aggraver cette douleur, pas la diminuer, quand elle se produira enfin.

C'est exactement ce qu'est .NET Core, et ce fil est la douleur temporaire ressentie.

@terrajobst a dit que cela n'arriverait pas: voir le fil: https://twitter.com/terrajobst/status/1059525279431815168?s=19

@gulbanana
Oui, sauf deux choses.

1. Core n'est pas une mise à niveau de Framework; c'est un concept parallèle. Il y a tellement de choses vraiment fondamentales qu'il ne peut pas faire, dont beaucoup, comme AppDomains, on nous dit qu'il est peu probable que cela se produise. Pour l'amour du ciel, nous n'avons même pas encore de Reflection.Emit ! Compte tenu du fait que cela est courant dans les compilateurs et les outils de génération de code, vous penseriez que cela aurait été littéralement l'une des premières priorités, et pourtant nous sommes ici 4 ans plus tard et cela ne fonctionne pas! Cela rend très difficile de prendre au sérieux la notion de «Core comme remplacement / mise à niveau de .Net Framework».
2. Core ne met pas radicalement à jour le runtime, style CLR 2.0. Plus à "Quelles propositions linguistiques bénéficieraient des changements du CLR?" nous avons une excellente liste de la communauté des fonctionnalités manquantes que les gens considèrent comme importantes, que le CLR ne peut pas prendre en charge (ou du moins ne peut pas prendre en charge sans des kludges massifs et laids pour contourner les limitations du CLR,) généralement en raison de fonctionnalités manquantes dans le système de typage. Combien de propositions sur ce sujet sont même prises au sérieux par l'équipe de base? Et combien d'entre eux ont été écartés d'emblée parce que les personnes qui exécutent le projet ne veulent pas avoir à mettre à niveau le runtime? Nous recevons des DIM et ... autre chose? Rien du tout?

Donc non, .NET Core n'est pas un .NET Framework mis à niveau qui effectue les mises à jour CLR indispensables, car il ne s'agit pas d'un .NET Framework mis à niveau et l'équipe de projet fait tout ce qu'elle peut pour éviter de mettre à jour le CLR dans la mesure du possible. C'est littéralement le contraire de cela.

Pour l'amour du ciel, nous n'avons toujours pas de réflexion qui fonctionne. Compte tenu du fait que cela est courant dans les compilateurs et les outils de génération de code, vous penseriez que cela aurait été littéralement l'une des premières priorités, et pourtant nous voici 4 ans plus tard et cela ne fonctionne pas! Cela rend très difficile de prendre au sérieux la notion de «Core comme remplacement / mise à niveau de .Net Framework».

Ce serait formidable de comprendre ce qui ne fonctionne pas. ASP.NET Core et EF utilisent l'émission de réflexion à plusieurs endroits, je ne suis donc pas conscient des grandes lacunes. Pouvez-vous élaborer ici?

Il existe depuis au moins 2.0 .. iirc même 1.0 avait DefineDynamicAssembly, mais peut-être pas toute la suite de trucs d'émission.

J'ai également du mal à prendre au sérieux l'idée d'éviter de mettre à jour le CLR. Avez-vous vu le volume de travail accompli? https://github.com/dotnet/coreclr/commits/master
Il existe des fonctionnalités de langage prévues pour C # 8 qui ne fonctionneront que sur .NET Core en raison des modifications CLR. Beaucoup de ces objections semblent simplement être d'anciennes informations (ce qui est assez juste, car les plans de Microsoft ont parfois changé rapidement ...)

@davidfowl

Ce serait formidable de comprendre ce qui ne fonctionne pas. ASP.NET Core et EF utilisent l'émission de réflexion à plusieurs endroits, je ne suis donc pas conscient des grandes lacunes. Pouvez-vous élaborer ici?

Certes, cela fait quelques mois que j'ai vérifié, donc cela a peut-être changé récemment, mais pour autant que je sache, il est possible de créer un nouvel assemblage en mémoire, mais pas de le sauvegarder sur disque pour des raisons obscures impliquant la génération de PDB, ce qui rend Core inutile aux responsables du compilateur comme moi.

Cela a-t-il été corrigé? Je serais ravi d'apprendre qu'il a ...

@gulbanna

J'ai également du mal à prendre au sérieux l'idée d'éviter de mettre à jour le CLR

Ce que j'ai dit, c'est qu'ils évitent de mettre à niveau radicalement le CLR de la même manière que la mise à jour 2.0 (génériques).

Plus précisément, ils semblent éviter activement toute modification qui ajouterait de nouveaux types fondamentaux de types au système de types (formes, métaclasses, DU, etc.) ou de nouvelles instructions IL au jeu d'instructions.

@masonwheeler

Certes, cela fait quelques mois que j'ai vérifié, donc cela a peut-être changé récemment, mais pour autant que je sache, il est possible de créer un nouvel assemblage en mémoire, mais pas de le sauvegarder sur le disque

En regardant https://github.com/dotnet/corefx/issues/4491 (où vous avez commenté dans le passé), je pense que la situation est toujours la même. Bien que je pense que manquer une fonctionnalité spécifique (même si c'est important) est assez différent de "nous n'avons même pas encore de Reflection.Emit ".

ce qui rend Core inutile aux responsables du compilateur comme moi

Comment Reflection.Emit est-il jamais utile pour un rédacteur de compilateur? Je pensais que c'était limité à la production d'assemblys pour le framework actuel, donc il ne pouvait pas du tout être utilisé pour créer par exemple des assemblys .Net Standard, ce qui, je pense, serait une limitation significative pour n'importe quel compilateur.

Ce que j'ai dit, c'est qu'ils évitent de mettre à niveau radicalement le CLR de la même manière que la mise à jour 2.0 (génériques).

Je pense qu'il y a eu une certaine inertie pour ne pas changer le CLR, bien qu'il y ait aussi de très bonnes raisons à cela, surtout si l'on considère que ces changements sont les plus utiles et les moins douloureux lorsqu'une plate-forme est jeune.

Je pense que DIM est un signe que cela pourrait changer, mais je ne m'attendais toujours pas à de nouvelles instructions IL lorsque les intrinsèques JIT peuvent souvent fonctionner aussi bien, ou à de nouveaux types de types lorsqu'ils peuvent être raisonnablement encodés dans le système de types existant.

@svick

Bien que je pense que manquer une fonctionnalité spécifique (même si c'est important) est assez différent de "nous n'avons même pas encore de Reflection.Emit fonctionnel".

Si vous aviez un éditeur de texte qui pouvait vous permettre de taper des fichiers texte sans les enregistrer, ne diriez-vous pas que cela ne fonctionne pas?

Comment Reflection.Emit est-il jamais utile pour un rédacteur de compilateur?

Cela a très bien fonctionné jusqu'à présent. Et pour autant que je sache, c'est le seul backend de compilateur disponible qui vous permet à la fois de générer de nouveaux assemblys et de les enregistrer ou de générer de nouveaux assemblys en mémoire et de les exécuter.

je ne m'attendais toujours pas à de nouvelles instructions IL alors que les intrinsèques JIT peuvent souvent fonctionner aussi bien

Bien sûr, mais qu'en est-il des cas où ils ne le feront pas?

ou de nouveaux types de types lorsqu'ils peuvent être raisonnablement codés dans le système de types existant.

Avez-vous vu la proposition d'implémenter les formes dans le système de typage existant? Il n'y a rien de raisonnable à ce sujet; c'est un gros, laid kludge du début à la fin. (Rien contre les gens qui l'ont inventé; cela doit en quelque sorte l'être, étant donné les limitations avec lesquelles il travaille.) Et bonne chance pour implémenter des métaclasses sans support au niveau CLR!

Nous avons besoin d'un CLR mis à jour pour développer des fonctionnalités de niveau supérieur de manière efficace, et personne ne travaille réellement pour y parvenir sur Core.

Quelqu'un de l'équipe .net peut-il préciser quelle est sa recommandation pour les déploiements sur site? Est-ce juste "utiliser asp.net régulier"? Je parle spécifiquement des commentaires de @ Edward84

Cela affecte-t-il les bibliothèques de support Microsoft.Extensions.* ? Plus précisément Microsoft.Extensions.Logging et Microsoft.Extensions.Configuration .

Nous avons une grande base de code qui partage une API de base commune. Certains d'entre eux sont WinForms, certains sont ASP.NET classique, certains WCF, etc. Et les applications les plus récentes sont .NET Core (pas actuellement, mais finalement lorsque nous avons porté nos bibliothèques de base au standard .NET)

Nous avons choisi de baser notre API principale de journalisation et de configuration sur les abstractions des bibliothèques mentionnées ci-dessus.

Je me demande donc s'ils peuvent être utilisés en toute sécurité dans une API .NET Standard référencée à la fois par .NET Core et .NET Framework (4.7.2+) ou peuvent-ils également commencer à utiliser uniquement les fonctionnalités .NET Core?

@mvestergaard Comme mentionné dans l'annonce elle -

Les packages

Et dans le commentaire de @benaadams dans ce fil :

Toutes les bibliothèques ne migrent pas uniquement vers .NET Core (par exemple, Microsoft.Extensions.* restent en tant que .NET Standard)

@mvestergaard, comme nous l'avons déjà mentionné, nous examinons notre politique LTS pour déterminer si des éléments tels qu'une assistance étendue, des périodes plus longues, une période de «mode maintenance», etc. sont utiles et à quoi ils ressembleraient. Nous travaillons également pour voir si nous pouvons rendre le calendrier des nouveaux trains LTS plus prévisible (un modèle que nous voyons et admirons vraiment d'autres piles qui ont un modèle LTS).

Le plus gros problème que j'ai avec cela est de ne pas pouvoir utiliser les packages matures qui ne peuvent être utilisés que pour cibler .NET Framework ou ceux qui n'étaient tout simplement pas disponibles en dehors de .NET Framework, comme ceux qui nécessitaient System.Drawing et GDI +.

Il semble que ce dernier scénario sera pris en charge dans .NET Core 3.0, mais AFAICT nous manquera toujours d'utiliser les bibliothèques stables et matures qui ne peuvent être utilisées que sur .NET Framework.

Un exemple de cela est Entity Framework . Nous devrons passer à l' EF Core immature qui semble être loin de gérer tous les scénarios complexes que l'EF complet pourrait et qui revient à l'évaluation du client en mémoire derrière votre dos pour masquer ce problème qui cause les performances problèmes .

Un exemple de cela est Entity Framework. Nous devrons passer à l'EF Core immature qui semble être loin de gérer tous les scénarios complexes que l'EF complet pourrait ...

EF6 sera pris en charge dans .NET Core 3.0, comme expliqué par @DamianEdwards cette semaine, ASP.NET Community Standup - 6 novembre 2018 - Fonctionnalités ASP.NET Core 3.0 à 19:06

@benaadams c'est une excellente nouvelle! assez obscur pour un si gros problème! :) bon travail pour trouver ça. J'ai trouvé une autre mention ici .

@SaebAmini : Vous pouvez utiliser System. S'appuyant sur .NET Core. Voir System.Drawing.Common et Scott Hanselmans Blogpost: https://www.hanselman.com/blog/HowDoYouUseSystemDrawingInNETCore.aspx ,

Et avant que CoreCompat.System.Drawing existait, en tant que portage de System.Drawing de Mono.

Existe-t-il une fonctionnalité manquante pour votre cas d'utilisation lors de l'exécution sur .NET Core?

@TsengSR mon scénario spécifique qui nous a fait cibler le .NET Framework était:

1. La nécessité d'utiliser le package Microsoft Solver Foundation, uniquement disponible dans .NET Framework.
2. Un package de génération d'image de code-barres qui a utilisé System.Drawing.
3. La nécessité d'utiliser EF6.

Il y a environ un an.

@SaebAmini : comme mentionné précédemment, la prise en charge d'EF6 est fournie dans .NET Core 3.0, System.Drawing est déjà là (et avant cela, le package CoreCompat existait et a peut-être fonctionné dans votre cas) et pour le package Microsoft Solver Foundation, après exécution de l'analyseur d'API de portabilité:

Voir Comment utiliser l'analyseur de portabilité

https://gist.github.com/TsengSR/f61c03c5f2d63dbe78d6b8c1eed08831 (téléchargez-le et ouvrez le HTML, je n'ai pas trouvé d'autre endroit pour le mettre).

Il montre une compatibilité de 97,93% avec les extensions de plate-forme .NET Core 2.0 + (qui a été publié il y a environ un an) et il répertorie les API incompatibles, qui sont principalement liées à System.Web qui était obsolète et System.ServiceModel / System.Data.Linq .

Maintenant, je n'ai pas utilisé ce package auparavant, et je ne sais pas pourquoi un solveur aurait besoin d'accéder à System.Web et HttpContext ou au System.ServiceModel , mais si Vous n'avez besoin d'aucune de ces thèses (et vous savez que votre cas d'utilisation n'appelle pas ces API), les chances sont assez élevées que vous puissiez l'utiliser sur les extensions de plate-forme .NET Core 2.0 / 2.1 + ou sur .NET Core 3.0 s'il ne cible pas spécifiquement le surnom cible netstandard ou netcoreapp20 .

Donc, techniquement, les chances étaient bonnes que vous ayez pu migrer votre application vers les extensions de plate-forme .NET Core 2.0 + il y a un an, si EF Core 2.0 aurait pu couvrir les besoins de vos applications (bien sûr, cela nécessite un travail de migration et des mises à jour pour fonctionner. avec EF Core 2.0).

Oui, il faut un peu plus de travail pour analyser les bibliothèques en question ou la fonctionnalité du framework de remplacement (EF6 -> EF Core 2.0 / 2.1), mais c'est loin d'être impossible. Je ne pense pas que les gens peuvent ou devraient s'attendre à porter tout leur code 1: 1 vers ASP.NET Core sans apporter de modifications du tout (en dehors d'ASP.NET Core lui-même).

Je souhaite juste qu'il soit plus évident d'afficher la compatibilité des API, comme avec un "badge" (compatible .NET Core 3.0) et / ou un rapport détaillé de compatibilité des API quelque part sur la page nuget pour le rendre plus évident que d'avoir à télécharger le package puis exécutez-le via l'analyseur de package.

Je pense que cette annonce aurait été mieux reçue si elle soulignait à quel point .NET Core est devenu plus compatible. Il existe deux facteurs permettant de déplacer ASP.NET Core hors de .NET Framework:
1) Réduire le besoin de .NET Framework, rendre les anciens deps disponibles et améliorer l'interopérabilité, etc.
2) Augmenter les avantages de .NET Core, les fonctionnalités et les performances et réduire la charge de maintenance

Le facteur 2 occupe une place importante dans l'esprit des personnes qui doivent réellement créer ASP.NET! Cependant, il y a peu d'avantages du point de vue de l'utilisateur. Les gens ont quelque chose qui fonctionne et leur priorité absolue est que cela continue de fonctionner. La bonne nouvelle est que dans la plupart des cas, ce sera le cas.

Je suis d'accord avec @gulbanana. .NET Core est désormais beaucoup plus compatible avec .NET Framework. En fait, j'ai pu lancer de très grosses applications .NET Framework simplement en renommant .exe en .dll et en ajoutant des .DLL manquants au chemin de recherche.

Les progrès sur les outils de ligne de commande dotnet sont impressionnants. Surtout l'ajout d'outils globaux .NET Core. Ils facilitent le développement.

La compilation AOT avec crossgen est géniale. Je peux continuer encore et encore.

tl / dr .NET Core est vraiment impressionnant de nos jours.

Que manque-t-il:

• La stratégie actuelle de communication client fait défaut. Les clients sont très déçus d'apprendre que leur plate-forme .NET préférée est fragmentée par Microsoft. Vous devriez être plus clair ici. Par exemple, ce serait une bien meilleure approche pour annoncer directement l'implémentation .NET singulière, hautement compatible, rapide et à l'épreuve du futur auprès des gens. Comme .NET Core, le futur de .NET, va résoudre la plupart de vos problèmes, la productivité de la fusée céleste, la créativité, ouvrir de nouvelles niches de marché, etc.
• Encore plus de stratégies de compatibilité prêtes à l'emploi
• Interface utilisateur graphique. Je veux dire que les outils de ligne de commande dotnet sont excellents, mais actuellement, nous devons utiliser des éditeurs de texte et une console supplémentaires pour travailler sur presque tous les projets au format .NET SDK. L'interface utilisateur de Visual Studio fait défaut à cet égard. Cela pose de gros obstacles à de nombreuses personnes qui ont l'habitude de simplement pointer et cliquer. Cela devrait également être amélioré
• Prise en charge LTS

@TsengSR Merci pour votre compagnon de réponse détaillé, super info! à l'époque, l'utilisation du package de codes à barres ne fonctionnait pas car le projet ne compilerait tout simplement pas en se plaignant de différentes cibles. Je devrais peut-être essayer de nouveau. (sauf si vous vouliez le recompiler nous-mêmes et en hériter un peu)

Pas vraiment préoccupé par l'effort si c'est raisonnable. Ma principale préoccupation était de rester haut et sec sans option, EF étant le principal bloqueur et cela ne se produira apparemment pas. C'est bien de voir que ça a été bien pensé. Bien que je sois d'accord avec @gulbanana , ils peuvent être mieux annoncés.

Il y a beaucoup de problèmes confondus ici. Mon 2 centimes personnel est que laisser .NET Framework derrière n'est pas si grave. Ce qui est préoccupant cependant, c'est l'absence totale de soutien apparent pour les efforts de normalisation (.NET Standard). Bien sûr, vous ne voulez probablement pourrait arriver, j'aimerais pouvoir dire "Ouais, dès que SuperNetRuntime prend en charge .NET Standard 2.2, nous pouvons exécuter ASP.NET Core 3 dessus" ...

Existe-t-il une chance d'au moins «rassembler» toutes les modifications nécessaires dans .NET Core 3 pour ASP.NET Core 3 et de les transmettre au groupe de travail .NET Standard sous forme de suggestions?

Bonjour, les packages publiés pour .NetStandard 2.0 ou .NetCore 2.0 continueront-ils à fonctionner avec .NetCore 3.0. Par exemple: Oracle.ManagedDataAccess.Core target .NetCore 2.0

S'il y a compatibilité descendante, alors passer à .NetCore 3.0 est approprié mais s'il n'y a pas de support pour les anciennes versions, alors c'est vraiment inutile à moins que tout le jeu ne rattrape.

.NetFramework a une histoire de compatibilité même si vous pouvez utiliser .NetFramework 2.0 dans les dernières versions, donc quelque chose doit être maintenu pour .NetCore également au moins 2.0 à 3.0, etc.

Merci

Bonjour, les packages publiés pour .NetStandard 2.0 ou .NetCore 2.0 continueront-ils à fonctionner avec .NetCore 3.0. Par exemple: Oracle.ManagedDataAccess.Core target .NetCore 2.0

Oui, .NET Core 3.0 maintient la compatibilité descendante et peut donc utiliser les bibliothèques .NetStandard 1.0 -> .NetStandard 2.1 et .NetCore 1.0 -> .NetCore 2.2

@benaadams alors c'est bien. Est-ce que .net framework dll fonctionnera également s'ils n'utilisent aucune API manquante?

Merci

Est-ce que .net framework dll fonctionnera également s'ils n'utilisent aucune API manquante?

Oui, bien qu'il soit plus sûr d'utiliser une bibliothèque .NET Standard car vous savez qui fonctionnera sur .NET Core (et sur Mono, Xamarin, Unity, UWP)

En outre, l'utilisation du pack de compatibilité Windows ajoute 20 000 API supplémentaires en plus de .NET Standard 2.0 pour rapprocher .NET Core de .NET Framework (ce que vous pouvez faire avec .NET Core 2.1); et .NET Core 3.0 est le plus compatible à ce jour avec EF6 (cross-plat), et sous Windows: WinForms, WPF, COM Interop, etc.

Salut les gens,
Afin de donner aux clients un tremplin raisonnable sur leur chemin vers la migration des applications vers ASP.NET Core sur .NET Core, nous allons étendre la prise en charge et la maintenance d'ASP.NET Core 2.1.x sur .NET Framework pour correspondre à la prise en charge actuelle politique pour les autres frameworks ASP.NET basés sur des packages , par exemple MVC 5.x, Web API 2.x, SignalR 2.x. Cela signifie effectivement que les packages liés à ASP.NET Core 2.1.x (liste détaillée finale à déterminer) seront pris en charge indéfiniment, au-delà de la période LTS de 3 ans pour l'ensemble du train .NET Core 2.1.

Excellente nouvelle. Merci d'écouter vos clients.

Il nous faudra beaucoup de temps pour porter notre ancienne application MVC car nous sommes sur MVC depuis CTP3 et avons à peu près tous les points d'extension utilisés. Cela couvre nos préoccupations.

@DamianEdwards C'est une excellente nouvelle! Je me demande juste cependant, est-ce corrigé à 2.1.x ou est-ce que cela sera mis à jour vers 2.2.x si cela finit par devenir une version LTS? Il y a eu beaucoup d'efforts dans la version 2.2 et il n'est même pas encore sorti. Et comme il continue avec la compatibilité netstandard et fonctionne bien sur le framework complet, ce serait un peu un gaspillage de l'ignorer complètement pour le support étendu.

@poke pendant que je comprends votre inquiétude, nous devons tracer une ligne quelque part, et dans ce cas, nous pensons qu'il vaut mieux garder la version alignée sur le LTS qui la précède. C'est le compromis que les clients doivent décider eux-mêmes lorsqu'ils choisissent entre un train LTS ou un train actuel. Les nouvelles fonctionnalités ne viennent pas à LTS car elles concernent la stabilité. Les commentaires concernaient un soutien à plus long terme et nous avons déjà un train pour cela, il s'agit donc d'une extension du train. 2.2 ne deviendra pas LTS.

@DamianEdwards Oui, je comprends cela, merci pour votre réponse. Je demandais simplement parce que le dernier commentaire à ce sujet était que cela n'a pas encore été décidé , donc je voulais juste savoir si ce support étendu serait reporté si 2.2 devenait LTS.

Et je pense qu'il est suffisamment important de le souligner pour que les gens ne mettent pas à niveau leurs applications de cadre vers la version 2.2 s'ils doivent compter sur ce support étendu. Sinon, ils devront à nouveau déclasser.

Les nouvelles fonctionnalités ne viennent pas à LTS car elles concernent la stabilité.

Cela ne correspond cependant pas vraiment aux décisions précédentes de LTS.

@poussée

Cela ne correspond cependant pas vraiment aux décisions précédentes de LTS.

Cela m'a dérouté. De quelle manière? Faites-vous référence au fait que 1.1 a été ajouté au train 1.x LTS? Si c'est le cas, c'était une anomalie de notre premier train de versions qui ne sera pas répétée. À l'avenir, notre intention est d'être plus cohérent avec quelles versions deviennent LTS par rapport à Current (c'est-à-dire où puis-je obtenir la stabilité par rapport aux fonctionnalités).

@DamianEdwards Je

@poke OK. Eh bien, jusqu'à présent, nous avons eu 4 versions (1.0, 1.1, 2.0, 2.1) avec la 5e à venir (2.2). Parmi ceux-ci, seuls 1.0 et 2.0 étaient initialement destinés à être LTS, mais en raison d'un certain nombre de facteurs (principalement liés au fait que nous sommes vraiment nouveaux dans l'ingénierie de cette façon 😉), nous nous sommes retrouvés avec 1.0, 1.1 et 2.1 étant les trains LTS. 2.0 et 2.2 sont (étaient, seront) les versions actuelles. À ce stade, 3.0 sera presque certainement Actuel également (ce qui amènera 2,2 à entrer dans la période de «grâce» actuelle de 3 mois) avant que 3.1 ne devienne le LTS du train 3.x. Notre espoir est qu'après cela, le modèle et la cadence seront plus cohérents (nous aimerions ça), mais jusqu'à présent, notre boule de cristal nous a échoué.

@DamianEdwards Merci pour les informations! 😄 (Btw. Je n'essayais pas d'argumenter à ce sujet, j'étais juste curieux;))

Un problème plus important pour nous est les nouvelles API REST hébergées en cours par des applications héritées qui ne sont pas susceptibles de quitter .NET Framework de sitôt. Au moins, nous savons qu'il ne faut pas progresser au-delà des bibliothèques de prise en charge de .NET Standard 2 et d'ASP.NET Core 2.1 maintenant! C'est bien que la période LTS soit prolongée

Salut à tous, une petite question: qu'en est-il de ceux d'entre nous qui consomment des packages natifs sous la forme de C ++ / CLI? Cela va-t-il être pris en charge dans .Net Core de sitôt, ou sommes-nous orphelins à moins que nous ne procédions à une refonte massive pour utiliser P / Invoke?

@lokitoth - ce serait une bonne question pour les https://github.com/dotnet/core car c'est plus général que juste ASP.NET Core.

@lokitoth oui, cela sera pris en charge, voir https://github.com/dotnet/coreclr/issues/18013

oO Comment ai-je manqué ça?

D'accord, alors je n'ai aucun problème avec ça.

@ danroth27 Pouvez-vous nous parler de l'impact de ce problème pour Client-Side-Blazor?

@Slkebe Je ne m'attends à aucun impact. Les applications Blazor côté client sont indépendantes de l'environnement d'exécution ou de la plate-forme que vous décidez d'exécuter sur le serveur.

@ danroth27 D'après ce que je comprends, Blazor côté client peut fonctionner en mono car les packages Microsoft.AspNetCore.* dépendants ciblent netstandard.
Est-ce que je manque quelque chose? Blazor doit continuer à cibler Microsoft.AspNetCore.* 2.1.X?

@Slkebe Les bibliothèques Blazor côté client dépendent uniquement des composants qui continueront à cibler .NET Standard (comme Microsoft.Extensions. * Et ses amis). Les parties côté serveur de Blazor qui dépendent d'ASP.NET Core cibleront .NET Core comme décrit dans ce problème.

https://blogs.msdn.microsoft.com/dotnet/2018/11/05/announcing-net-standard-2-1/

Quelle est la décision maintenant? Cibler sur la norme .net 2.1?

@ John0King Il n'y a pas de nouvelle décision.

Ce sont des bananes! BANANES

je comprends votre point de vue.

Toutes mes excuses si cela a déjà été soulevé, mais qu'en est-il des cas d'utilisation où je veux simplement utiliser Kestrel + un middleware dans le cadre d'une application non ASP.NET? Dois-je extraire l'intégralité de l'arborescence 3.0 (ce qui n'est pas idéal, car mon cas d'utilisation implique la définition d'un SDK personnalisé pour les consommateurs), ou ce cas d'utilisation n'est-il pas pris en charge sur 3.x?

Actuellement, je développe une application ASP.NET Core exécutée sur .NET Framework, en raison des bibliothèques incluses. J'utilise ASP.NET Core en raison de ses capacités d'authentification multiple. Je me sens berné et complètement verrouillé.

J'utilise ASP.NET Core en raison de ses capacités d'authentification multiple.

@FlorianGrimm Quoi de particulier? Microsoft.Owin a fourni une fonctionnalité d'authentification similaire pour ASP.NET 4.

Il s'agit d'une application hybride à un code source (.exe) s'exécutant sur site et Azure, utilisant actuellement Windows auth, aad, auth de base et anonyme.

@FlorianGrimm Quelles dépendances de bibliothèque vous empêchent d'utiliser .NET Core?

Microsoft.Office.Project.Schema, Microsoft.SqlServer.TransactSql.ScriptDom et Microsoft.SharePointOnline.CSOM.

J'espère que l'équipe SharePoint terminera
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/16585795-support-net-core-with-csom
et je trouve d'autres options que ilspy.

De toute façon, j'aime ASP.NET Core et j'espère que les autres équipes Microsoft fourniront plus d'assemblys .NET Core.

Nous clôturons périodiquement les questions de «discussion» qui n'ont pas été mises à jour depuis longtemps.

Nous nous excusons si cela cause des inconvénients. Nous vous demandons que si vous rencontrez toujours un problème, veuillez enregistrer un nouveau problème avec des informations mises à jour et nous enquêterons.