Aspnetcore: Les nouveaux packages ASP.NET Core 2.0 ne peuvent plus être utilisés sur .NET Desktop

Ce serait un changement extrêmement étrange et mauvais à faire. J'ai écrit beaucoup de code de base asp.net netfx uniquement et je ne veux pas voir cet investissement gaspillé. Plus généralement, les clients .NET devront pouvoir interopérer entre ASP.NET Core et le code Desktop dans un avenir prévisible - imaginez des applications Web qui utilisent Active Directory ou l'automatisation Office COM, ou qui effectuent des vignettes à l'aide de System.Drawing bibliothèque ou partagez du code avec une application WPF. C'est trivial de penser à beaucoup de scénarios comme celui-ci et j'espère que nous avons simplement mal compris ce qui se passe.

Nous sommes actuellement sur AspNetCore 1.1.1 - c'est-à-dire la branche de support "actuelle". Si nous ne pouvons pas passer à la version 2.0 en raison de dépendances à Net4XX, cela signifie-t-il que nous ne serons plus pris en charge lorsque la version 2.0+3 mois tombera ?

Nous utilisons une combinaison de WPF et ASP.NET Core et ciblons dans les deux cas le framework complet.
Donc je suppose qu'il n'y aura pas de 2.0 dans un avenir prévisible ?

Mais le framework complet 4.6.1 prendra-t-il en charge le netstandard 2 ? est-ce que je manque quelque chose? (https://docs.microsoft.com/en-us/dotnet/articles/standard/library)

n'est-ce pas que l'outillage actuel n'est pas mis à jour ?

ce serait tout à fait correct et on s'attend à ce que le noyau asp.net s'exécute sur le net standard 2. la chose alarmante est cette perspective de passer au net core app2.0, ce qui impliquerait de ne plus pouvoir utiliser le code hérité à l'intérieur d'asp.net sites Web principaux

oh, c'est un problème .. Je suppose cependant que c'est un peu atténué par les shims compat dans netcore2 qui vous permettent de référencer d'anciens assemblages, mais cela signifie quand même porter tous les projets sur le nouveau système de projet et beaucoup d'autres travaux ..

Ce serait bien d'entendre les équipes raisonner là-dessus

oh, donc vous pensez que les projets netcoreapp2.0 pourront simplement référencer les libs netfx grâce à l'unification de type ? cela expliquerait beaucoup de choses. ma question, si oui, est de savoir combien de code fonctionnera réellement lorsqu'il sera exécuté sur Windows mais sur le noyau CLR ..

Wow. Cela serait totalement bloquant pour nous et garantirait essentiellement que nous ne pourrions jamais mettre à jour ces packages dans un avenir prévisible. Nous pourrions même avoir besoin de migrer notre projet MvcCore vers Mvc, car nous ne pouvons actuellement pas contourner le ciblage de net462+.

Je suis également extrêmement curieux à ce sujet. J'espère vraiment cela dans une étape intermédiaire (et de courte durée) ou une grosse erreur de communication. Ce serait certainement un obstacle à l'adoption pour la plupart de nos applications également.

Tout déplacer vers Core est tout simplement trop pour une grande base de code existante (sans arrêter dev pour le faire), passer aux nouvelles classes ASP.NET (HttpRequest, contrôleurs, etc.) car une étape intermédiaire doit se produire pour nos projets principaux.

Peut-être que @DamianEdwards ou @davidfowl peuvent commenter les plans ici ? J'ai aussi du mal à trouver un raisonnement supplémentaire.

Je peux voir pourquoi c'est initialement un moment WTF effrayant. Laissez-moi vous expliquer parce que c'est moins bizarre qu'il n'y paraît.

• Vous avez dit que les clients .NET vont devoir interagir. Entièrement d'accord.
  
  
  
  • Nous pouvons partager des bibliothèques netstandard entre ASP.NET Core 2.0 et PARTOUT.
  
  
  • Nous pouvons même référencer de nombreux assemblys net461 + à partir d'ASP.NET Core 2.0 en raison de typeforwarding et netstandard20
  
  
• Vous avez dit que les WebApps pourraient avoir besoin d'utiliser :
  
  
  
  • AD - Totalement, c'est une lacune SI vous souhaitez appeler LDAP directement. Vous pouvez certainement vous authentifier contre Windows Auth MAINTENANT. Nous prévoyons d'avoir spécifiquement l'espace de noms DirectoryServices pour Core 2.0 vers l'été
  
  
  • Dessin - Totalement, c'est une lacune. Nous prévoyons de l'avoir pour Core 2.0 vers l'été. Jusqu'à cela, ces options netstandard existent également ImageSharp, ImageResizer, Mono options, etc.
  
  
  • COM Automation - Cela n'a jamais été possible sous Core 2.0, mais vous pouvez certainement PInvoke si vous voulez vous faire du mal. Vous pouvez également utiliser une WebAPI locale vers un processus net461+ si vous voulez vraiment vous faire du mal.
  
  
  • Partage de code avec les applications du PAM - OUI. Tout à fait possible avec netstandard2.0.
  
  
• C'est un changement bizarre à faire.
  
  
  
  • Ça en a envie mais…
  
  

Pensez-y de cette façon. WPF n'est pas netstandard2.0, il sait qu'il est sur net461+ et c'est OK. Il est optimisé, mais il peut référencer des bibliothèques netstandard. ASP.NET Core 2.0 est optimisé pour Core 2.0 mais il peut référencer des bibliothèques partagées. Xamarin est pareil.

.NET Core est côte à côte et évolue rapidement. C'est BEAUCOUP plus rapide que .NET (Full) Framework peut se déplacer, ce qui est bien. En construisant ASP.NET Core 2.0 sur .NET Core 2.0 (qui, rappelez-vous, est un SUPERSET de .NET Standard), cela signifie que les choses peuvent être construites plus rapidement que NetFx ou même Netstandard.

NetCore > Net Standard > NetFx en matière de vitesse de développement et d'innovation.

Le fait est que si vous effectuez un nouveau travail, netstandard20. Si vous avez des bibliothèques net461 + plus anciennes, la plupart d'entre elles peuvent être référencées sous ASP.NET Core 2.0.

ASP.NET Core 1.1 qui s'exécute sur .NET Framework sera entièrement pris en charge pendant un an après la sortie de la version 2.0. Cette charge de travail est entièrement prise en charge au moins jusqu'en juillet 2018.

Les grandes lacunes restantes manquantes dans .NET Core 2 sont System.DirectoryServices et System.Drawing. Nous travaillons pour avoir un pack de compatibilité Windows qui activerait les deux sur .NET Core sous Windows cet été.

Ce dont nous avons besoin de vous tous, c'est d'une liste/compréhension claire de POURQUOI vous pensez avoir besoin d'ASP.NET Core 2.0 pour fonctionner sur net461+.

Je pensais que .NET Standard 2.0 était une question de compatibilité et d'interopérabilité qui comble le fossé entre .NET Core et .NET fx que tout le monde attend - cela semble tuer cela.

Pour une raison quelconque, de nombreux clients auront des dépendances nécessitant .NET 4.x, qu'il s'agisse de dépendances externes personnalisées, de composants commerciaux, de dépendances de bibliothèques héritées, etc.

Est-il prévu que les clients ne puissent pas créer d'applications ASP.NET Core 2.0 s'exécutant sur Desktop CLR afin de pouvoir référencer leurs deps .NET 4.x existants ?

@shanselman Merci pour la réponse - beaucoup de bons exemples là-dedans.

Un suivi sur les bibliothèques :
Toutes les bibliothèques d'abstraction resteront-elles compilées de manière croisée ? Par exemple, si j'utilise HttpRequest , le maintien d'une version 1.x et 2.x sur la version d'ASP.NET Core que vous utilisez (qui correspond désormais proprement à un TFM au moins) serait quelque chose Je préférerais éviter... alors j'espère que les abstractions resteront sur netstandard . C'est le plan général ?

Nous maintenons déjà plusieurs variantes pour les choses qui dépendent d'ASP.NET/MVC parce que System.Web 's HttpRequest est totalement différent, donc c'est une autre bibliothèque entièrement (par exemple MiniProfiler vs . MiniProfiler.AspNetCore ). Je veux juste m'assurer que nous gardons à l'esprit le nombre de variantes que nous chargeons de maintenir pour tous les auteurs de bibliothèques si leurs dépendances s'éloignent de netstandard ... et j'espère juste éviter ce mal de tête tous ensemble.

Je suis très heureux que cela ne semble pas aussi grave qu'il n'y paraît, merci pour les précisions détaillées.

J'ai deux questions/préoccupations :

• Il semble que la consommation de bibliothèques .NET Framework à partir d'ASP.NET Core devrait avoir un minimum de friction. C'est génial! Qu'en est-il de l'inverse ? Il existe probablement des bibliothèques et des applications .NET Framework ou netstandard qui intègrent des parties ou des composants de Mvc et d'autres bibliothèques ASP.NET Core prenant en charge (je le sais parce que j'en ai quelques-unes). Ceux-ci vont casser, n'est-ce pas ? Existe-t-il des conseils pour contourner ce scénario ? Si les bibliothèques netstandard ne peuvent plus utiliser les bibliothèques ASP.NET Core, cela semble être un gros problème pour les scénarios ASP.NET Core intégrés.

• D'un point de vue non technique, il semble que cela causera beaucoup de confusion. En dehors des gens qui sont actifs sur GitHub, qui suivent sur Twitter, etc., il y a déjà beaucoup de confusion autour des différentes plates-formes, etc. Je vois des développeurs qui n'ont suivi qu'en partie ou qui se lèvent à l'instant pour accélérer la frustration lorsqu'ils vont utiliser ASP.NET Core (peut-être en suivant un didacticiel obsolète) et ne peuvent pas le faire fonctionner sur leurs plates-formes .NET Framework. Je ne sais pas quoi, le cas échéant, peut être fait à ce sujet.

Nous pouvons même référencer de nombreux assemblys net461 + à partir d'ASP.NET Core 2.0 en raison de typeforwarding et netstandard20

Malheureusement, cela ne signifie pas qu'une bibliothèque compilée et conçue pour le framework complet fonctionnera sur .NET Core (le risque est élevé que les choses explosent au moment de l'exécution !).

La plupart des "anciennes" API réintroduites dans .NET Core 2.0 sont des stubs qui ne fonctionneront jamais (fonctionnellement). Sans oublier qu'il manque encore de nombreuses API, et même des zones entières qui ont été délibérément exclues de .NET Core (IdentityModel, serveur WCF, remoting, support AppDomain complet, etc.)

Essayer de convaincre les gens qu'ils peuvent migrer "en toute sécurité" leurs applications ASP.NET Core 1.0 avec .NET Desktop vers ASP.NET Core 2.0 avec .NET Core est - IMHO - un mensonge.

.NET Core est côte à côte et évolue rapidement. C'est BEAUCOUP plus rapide que .NET (Full) Framework peut se déplacer, ce qui est bien. En construisant ASP.NET Core 2.0 sur .NET Core 2.0 (qui, rappelez-vous, est un SUPERSET de .NET Standard), cela signifie que les choses peuvent être construites plus rapidement que NetFx ou même Netstandard.

Je ne crois pas que ce soit ce que (la plupart) des gens recherchent. Beaucoup de gens n'ont pas besoin de bibliothèques rapides, ils ont besoin d'éléments stables qui peuvent s'intégrer avec élégance dans leurs anciens éléments sans prendre le risque de tout casser.

@daveaglick

• Correct en ce sens qu'il n'y a pas de possibilité implicite de référencer netcoreapp2.0 partir de net461 ou même netstandard2.0 . Le pont va dans un sens. Vous pouvez toujours contourner ce problème en spécifiant des TFM pour le repli du paquet, mais il s'agit évidemment d'une trappe d'évacuation, pas d'un scénario pris en charge (bien que cela suffira à débloquer de nombreuses personnes). C'est une quantité de travail non négligeable pour nous de prendre en charge les sous-systèmes d'ASP.NET Core en dehors de la plus grande pile (ce que le ciblage netstandard implique).
• Le potentiel de confusion va dans les deux sens. Par exemple, nous avons eu beaucoup de commentaires sur le fait que "ASP.NET Core" peut s'exécuter sur .NET Framework (qui n'est pas .NET Core) est déroutant. Cette modification fait effectivement d'ASP.NET Core une partie de la pile .NET Core, ce qui signifie que si vous utilisez ASP.NET Core, vous utilisez .NET Core.

@shanselman BTW, vous n'avez pas dit pourquoi la compilation croisée n'était pas une option. Les composants ASP.NET Core qui pourraient bénéficier des API netcoreapp2.0 uniquement pourraient avoir à la fois des TFM net46 / netstandard1.x / netstandard2.0 et netcoreapp2.0 et faire le nouveau truc cool/rapide .NET Core uniquement.

@NickCraver actuellement le plan n'inclut pas de quitter les packages *.Abstractions ciblant netstandard . La séparation n'est tout simplement pas aussi propre que cela à tous les niveaux. Cependant, pour les besoins de quelqu'un qui tente une migration comme ce que vous suggérez, l'utilisation de la solution de secours de la cible du package devrait vous y amener de toute façon (mais je vous ai peut-être mal compris).

De plus, vous indiquez que la division TFM propre est correcte et constitue un avantage de ce plan, en ce sens qu'un seul package peut désormais cibler ASP.NET Core 1.x et 2.0+ simultanément en utilisant le TFM comme pivot.

J'ai joué avec l'idée des "applications mixtes". Par exemple, une application WPF exposant une API Web ou un serveur offrant à la fois une API REST et des points de terminaison WCF (cela peut être pour la compatibilité avec des clients antérieurs). Ces scénarios sont rendus impossibles avec ce changement et rendent ASP.NET Core uniquement adapté aux nouvelles applications plutôt que d'être "juste une bibliothèque".

@PinpointTownes comme l'a déclaré @shanselman , nous sommes très intéressés par les exigences spécifiques et les bloqueurs que les clients ont en ce qui concerne la nécessité de continuer à cibler directement .NET Framework. Notre travail avec les clients de ce bateau jusqu'à présent a indiqué que System.DirectoryServices et System.Drawing et les bloqueurs n°1 et 2 et nous avons un plan pour y remédier. Au-delà de cela, nous examinons les commentaires et nous évaluerons.

La compilation croisée est une surcharge qui doit être équilibrée avec les besoins des clients et des produits. C'est pourquoi nous souhaitons obtenir ces commentaires afin de pouvoir définir plus concrètement à quoi ressemble le paysage pour nos clients et pour nous alors que nous continuons à faire évoluer ASP.NET Core.

@DamianEdwards Merci pour les précisions supplémentaires. Les bibliothèques netstandard -> ASP.NET Core sont un gros problème pour moi. J'intègre Kestrel (qui semble également migrer vers netcoreapp) dans plusieurs bibliothèques netstandard. J'intègre également Razor à plusieurs endroits, et je sais que vous travaillez sur la nouvelle version plus modulaire, mais si cela ne cible que netcoreapp aussi, ça fera mal. Il existe également des tonnes de bibliothèques qui font "partie" d'ASP.NET Core mais qui ont beaucoup d'utilité en dehors de celui-ci.

En d'autres termes, je suis beaucoup plus préoccupé par la suppression de la possibilité pour les bibliothèques netstandard de consommer des packages ASP.NET Core que par l'inverse. Il semble que cela supprime toute une classe de cas d'utilisation.

@daveaglick Razor lui-même (le moteur) continuera à cibler netstandard . Encore une fois, la prise en charge de sous-systèmes particuliers d'un grand graphe complexe (comme ASP.NET Core 2.0) sur différentes plateformes a un coût. Pour des choses comme l'intégration, il existe d'autres options (intégration de sources, copie, etc.), mais bien sûr, elles comportent leurs propres compromis.

Je vous entends certainement sur les différentes classes de cas d'utilisation, nous avons en effet différents groupes de clients à prendre en compte lors de la conception et de l'expédition d'une pile comme la nôtre.

Je partage les préoccupations de @daveaglick ici : ASP.NET Core voulant utiliser les dernières API est tout à fait compréhensible, mais pour tout le reste en aval, exiger la même chose devient un peu plus compliqué. Vous n'avez pas le choix après 1.0 de stable ou de mise à niveau, vous êtes sur le train le plus rapide disponible avec netcoreapp2.0 et c'est le seul choix. Si tous les bits (même les abstractions de base) ne peuvent pas être consommés sans que les utilisateurs consomment netcoreapp2.0 , cela signifie qu'il n'y a effectivement pas netstandard2.0 pour toute cette gamme de bibliothèques ... et tout le monde cela dépend d'eux.

Je fais bouger la pile d'applications de base, mais je ne suis pas nécessairement d'accord avec les abstractions en particulier. L'un des points majeurs des abstractions était d'éviter le couplage étroit comme celui-ci, du moins de mon point de vue en tant que consommateur. Je serais très curieux de voir des exemples où netstandard2.0 n'a pas les API nécessaires pour eux, mais netcoreapp2.0 en a - existe-t-il des exemples ? Est-ce principalement autour de nouveaux types dans les paramètres de méthode ? Je ne doute pas qu'il y ait un raisonnement suffisant, je suis juste très curieux - voir des exemples aiderait à montrer le coût de maintenance pour lequel nous n'avons pas autant d'informations quotidiennes.

Le cas Kestrel est plus compliqué, mais je vois certainement les arguments pour l'avoir sur le dernier ensemble d'API. J'imagine que de nouvelles API seront continuellement créées pour Kestrel compte tenu du travail qu'elle entraîne.

@PinpointTownes comme l'a déclaré @shanselman , nous sommes très intéressés par les exigences spécifiques et les bloqueurs que les clients ont en ce qui concerne la nécessité de continuer à cibler directement .NET Framework.

En tant que consultant, j'ai aidé un groupe de clients à déplacer leurs applications vers ASP.NET Core et j'ai souvent dû cibler .NET Desktop pour pouvoir utiliser des bibliothèques tierces (source fermée) en fonction d' IdentityModel / WCF ou en s'appuyant sur AppDomain Support.

Ne pas avoir ces éléments dans ASP.NET Core 2.0 serait un obstacle majeur pour eux.

Il existe également des bibliothèques qui ne fonctionneraient pas sur .NET Core même si les API étaient présentes, car elles seraient fonctionnellement différentes. Voici un cas concret que j'ai vu plusieurs fois :

Sur .NET Core, RSA.Create() renvoie une instance RSACng sous Windows, mais sur .NET Desktop, une instance RSACryptoServiceProvider est renvoyée. Pourtant, de nombreuses bibliothèques - y compris le BLC lui-même - essaient de convertir RSA en RSACryptoServiceProvider , ce qui échouera toujours sur .NET Core, car RSACng ne peut pas être converti en RSACryptoServiceProvider .

@NickCraver quelles abstractions en particulier ? Le problème avec le déplacement uniquement des abstractions est que vous finirez ensuite par vouloir tout ce qui s'appuie également sur ces abstractions (à moins que vous ne disiez littéralement que vous n'avez besoin que de Microsoft.AspNetCore.Http.Abstractions et rien d'autre)

@davidfowl Oui, uniquement les abstractions : par exemple, HTTP, Hosting, HTML et Logging. Il semble que Microsoft.Extensions.* soient couverts par les commentaires précédents, dont la plupart. Ce sont ceux avec qui je suis en contact aujourd'hui.

Pour un exemple concret : le Middleware MiniProfiler ne répond que sur des abstractions ( lien )

Si vous utilisez MVC et autres en plus, eh bien vous êtes de toute façon sur netcoreapp2.0 , et c'est ce que c'est (et IMO, c'est très bien). Mais actuellement, j'ai la liberté de diviser logiquement les API là où elles sont partagées et de le faire facilement car ce sont des abstractions. Je suis vraiment fan de la scission actuelle, s'il vous plaît, ne la verrouillez pas inutilement.

Il h. En tant que consultant, j'ai certainement entendu le "Quoi ? ASP.NET Core s'exécute sur le bureau .NET Framework !?" question plusieurs fois. Le fait que "ASP.NET Core" ait littéralement ".NET Core" dans le nom est vraiment regrettable.

Quoi qu'il en soit... Tout comme j'étais fan de la suppression d'API obsolètes/héritées/cassées lorsque .NET Core a démarré (un "nouveau départ"), je suis également fan de ce changement afin d'obtenir un framework plus rapide et plus léger. avec plus de fonctionnalités et un taux d'innovation plus élevé.

Cela dit, je suis également sympathique à tous les développeurs qui ne peuvent pas, pour une raison quelconque, migrer tout leur code vers .NET Core avant juin de l'année prochaine.

Cela inclut mon client actuel, qui possède une bibliothèque/un cadre hérité incroyablement volumineux, ciblant .NET Framework, consommé par plusieurs projets ASP.NET Core actuellement développés en parallèle. Au moment où ces systèmes entreront en production, il y aura peu ou pas de temps pour a) tout porter sur .NET Core, ou b) tout déplacer vers le framework ASP.NET complet, avant que ASP.NET Core 1.x ne soit plus pris en charge.

Un an de support est-il vraiment suffisant ici ? J'imagine qu'il existe d'autres cas similaires...

@khellang comme indiqué précédemment, ils pourront continuer à référencer les bibliothèques/frameworks ciblant .NET Framework, et cela fonctionnera très bien en supposant que les API qu'ils appellent font partie de la fermeture de netstandard2.0 . Savez-vous s'ils comptent sur des choses en dehors de cet espace ? C'est ce sur quoi nous aimerions vraiment avoir des commentaires afin que nous puissions évaluer la priorité du portage de ces API (comme System.DirectoryServices et System.Drawing ).

Ainsi, l'hébergement d'une API Web (par exemple, une couche de communication) ou même des sockets de base asp.net à venir va devenir impossible pour un service Windows actuel ou une application de bureau WPF ? (avec les versions prises en charge).

J'imagine qu'il y aura une liste à venir de choses qui étaient netstandard1.x qui sont maintenant netcoreapp2.0

J'ai parcouru les dépôts et il semble que les éléments spécifiques à MVC soient netcoreapp2.0 mais HttpAbstractions, Logging, Configuration, etc. sont toujours netstandard Ou y a-t-il d'autres changements à venir ?

@NickCraver Je vois que vous utilisez des extensions mais que vous utilisez toujours System.Web. Prévoyez-vous de caler Microsoft.AspNetCore.Http.HttpContext avec System.Web.HttpContext ? Avez-vous une idée de la quantité d'API dont vous avez besoin ?

Si vous utilisez MVC et autres en plus, eh bien vous êtes de toute façon sur netcoreapp2.0, et c'est ce que c'est (et IMO, c'est très bien). Mais actuellement, j'ai la liberté de diviser logiquement les API là où elles sont partagées et de le faire facilement car ce sont des abstractions. Je suis vraiment fan de la scission actuelle, s'il vous plaît, ne la verrouillez pas inutilement.

Je ne parle pas de MVC, je parle simplement d'autres assistants qui exposent plus de fonctionnalités en plus des abstractions sous-jacentes. La grande valeur du modèle "abstractions" que nous avons choisi est que d'autres choses peuvent être construites dessus, pas tellement les abstractions elles-mêmes. Mon instinct me dit que si nous créons les abstractions ASP.NET netstandard, nous devrons également créer tous les middleware netstandard.

Les services Windows @dasMulli fonctionneront une fois que nous aurons porté l'API (il existe également des bibliothèques open source qui prennent en charge les services Windows sur .NET Core).

Application de bureau WPF ? (avec les versions prises en charge).

Oui. Ce ne sera plus la valeur par défaut. Nous ne le prendrons plus en charge immédiatement avec .NET Core 2.0.

@davidfowl Je ne suis pas sûr que vous ayez regardé les bonnes pièces ici:

mais utilisez toujours System.Web

...pas dans les mêmes bibliothèques, à cause de cette scission. Pour obtenir une surcharge minimale et non un chargement de dépendances pour les consommateurs, il y a MiniProfiler pour ASP.NET MVC < 6 (System.Web) et MiniProfiler.AspNetCore / MiniProfiler.AspNetCore.Mvc (beaucoup de NuGet ).

Je pense que vous parlez de System.Web vestige qui était sur MiniProfiler.Shared - J'attendais de les nettoyer jusqu'à ce que le problème NuGet soit résolu hier soir sur les assemblages de framework. Je l'ai juste enlevé pour clarifier les choses.

@DamianEdwards Je ne suis pas à 100% sur la fermeture de netstandard2.0 , mais je serais heureux (avec leur permission) de faire un analyseur de portabilité et de partager les résultats. L'analyseur de portabilité est-il toujours d'actualité et à jour ?

ASP.Net Core devient rapidement le nouveau Python 3* ; seulement pire. Cela me semble être un pas dans la mauvaise direction. Cela signifie simplement qu'une tonne de scénarios obligera les développeurs à maintenir (et à écrire du nouveau) code sur les "anciennes plates-formes" pendant de nombreuses années au lieu de se déplacer. "Développement plus rapide" ne semble pas être un très bon argument si tout cela signifie que vous arrivez à un endroit pire/inadapté "Plus vite".

* J'aime Python 3, mais cela fait presque une décennie et la communauté Python est toujours fracturée

Juste pour être clair - y a-t-il un bloqueur technique (trucs de fantaisie) ou est-ce juste pour économiser le coût du maintien de la compatibilité à l'avenir ?
Je pense que la plupart d'entre nous savaient que ce mouvement arriverait, mais personne ne s'y attendait si tôt. - ce serait bien de garder le support net* pour au moins une version (par exemple 2.0, pas 2.1).

@shanselman Je vois vos points et je suis même d'accord personnellement, mais _beaucoup_ de gens ne vont pas le voir de cette façon.

Le problème principal n'est pas d'appeler les assemblages net46 à partir du noyau, les cales de compatibilité s'en occupent dans la plupart des cas. Le problème est le code net46 existant et le code asp.net core 1.* fonctionnant sur 46. Comme quelqu'un l'a mentionné, le but de netstandard était de permettre au code, y compris asp.net, de s'exécuter partout, cela va ressembler à une étape loin de cela et peut-être même un échec de cette vision pour certaines personnes.

Je ne pense pas que le problème soit que les gens ne veulent pas passer au net core. Le problème est que les organisations, les gestionnaires, les CTO et autres doivent être convaincus que le rapport coût/bénéfice en vaut la peine. Non seulement le portage prend suffisamment de temps pour ronger les livraisons, mais il introduit également des risques de régressions, etc.

en d'autres termes, ce ne sont pas toujours des raisons techniques qui empêchent les gens de se déplacer. Je dirais même que c'est rare, _techniquement_ presque n'importe quel projet peut faire le saut. Mais motiver ce bon de livraison, c'est ça le problème. Cela peut être une vente très difficile, celle que j'ai dû faire plusieurs fois. Dans ces cas, être capable de dire "mais vous pouvez exécuter sur un framework complet" a été un moyen de conduire ce mouvement

Si tu veux te faire du mal

C'est exactement ça. Les développeurs et la direction de Net46 ne le verront pas comme ça, ils le verront comme _vous_, Microsoft, voulez leur faire du mal afin de suivre la dernière version. "Eh bien, ne bougez pas alors", pourrait-on dire, mais avec le support d'asp.net core 1.x aussi court soit-il, ils doivent en quelque sorte le faire, du moins du point de vue des gestionnaires qui doivent être tenus responsables si un bogue provoque des temps d'arrêt ou des pertes d'informations. (même si le cadre n'est pas responsable)

Beaucoup de développeurs qui ont vraiment poussé pour asp.net core 1.1 vont également se sentir trahis qu'ils ne pourront plus passer à 2.0 sans core. Cela peut être justifié ou non, mais je vous dis simplement que beaucoup de gens vont ressentir cela, ce seront eux qui devront répondre à leurs collègues les plus conservateurs.

Est-ce que tout cela a de l'importance? Est-ce que asp.net core2/dotnet core2 "mourra" à cause de cela ? Non, mais cela ralentira l'adoption et fracturera l'écosystème et c'est vraiment triste à mon avis. Je veux que les gens puissent utiliser tous ces trucs formidables qui arrivent dans la version 2.0 et couper la compilation croisée au standard du net aura un impact sur cela. Certes, la plupart des gens qui traînent dans ces dépôts n'auront pas de problème, c'est Joe et Jane dev et plus encore, leur manager qui est le problème.

@DamianEdwards
Je suis d'accord que cela a été une source de confusion, j'ai dû l'expliquer plusieurs fois, mais le résultat a toujours été de transformer un développeur déçu en un développeur excité parce qu'ils pensaient qu'ils n'étaient pas en mesure d'utiliser les nouveaux trucs sympas mais il s'est avéré qu'ils le pouvaient.

Pour résumer, je suis sûr que cette décision n'a pas été prise à la légère, mais si vous devez le faire, je pense que vous devez faire très attention à la messagerie. Vous devez montrer que la migration vers le noyau asp.net, en particulier à partir de 1. x sur net46 est _super_ simple et super raffiné. L'histoire pour référencer d'autres bibliothèques netstandard de net46 à la fois comme références de projet et autrement doit être solide comme le roc. Je pense que vous devez montrer/adresser cela explicitement pour éviter que les gens ne paniquent

@khellang pagine @terrajobst pour la question de l'analyseur de portabilité.

@khellang

Oui, nous venons de mettre à jour le VSIX pour 2017, mais j'utilise simplement la version en ligne de commande d' ici .

@NickCraver Bien sûr, vous pouvez écrire un middleware qui cible netstandard, à quoi cela vous sert-il en tant qu'auteur de bibliothèque si ASP.NET Core prend en charge netcoreapp2.0.

@aL3891 super résumé ! Un gros problème que nous avons à l'avenir est de savoir comment nous tirons parti des nouvelles API pour les choses qui sont également dans le netstandard. .NET Core recevra de nouvelles API dont nous avons besoin pour implémenter de nouvelles fonctionnalités (une qui me vient à l'esprit est la prise en charge SSLStream ALPN pour la prise en charge HTTP2 dans Kestrel). Vous pourriez donc dire que nous restons sur netstandard et utilisons constamment la version la plus élevée (que .NET Framework ne prend pas encore en charge), mais nous serions alors dans le même bateau.

Un gros problème que nous avons à l'avenir est de savoir comment nous tirons parti des nouvelles API pour les choses qui sont également dans le netstandard. .NET Core obtiendra de nouvelles API dont nous avons besoin pour implémenter de nouvelles fonctionnalités (une qui me vient à l'esprit est la prise en charge SSLStream ALPN pour la prise en charge HTTP2 dans Kestrel).

Selon https://github.com/dotnet/corefx/issues/4721 , la prise en charge ALPN pour SslStream ne sera pas prête pour .NET Core 2.0. En supposant que cela soit finalement mis en œuvre quelques mois plus tard, cela signifie-t-il que l'on pourra l'utiliser pour cibler le netcoreapp2.0 TFM ? Dans ce cas, que se passera-t-il si je décide de publier une bibliothèque basée sur netcoreapp2.0 qui utilise de nouvelles API qui ne faisaient pas partie de la forme netcoreapp2.0 initiale si mes utilisateurs utilisent un runtime .NET Core plus ancien ? Va-t-il planter ? Ou est-ce que netcoreapp2.x sera aligné avec netstandard1.x , dont le contrat ne peut pas être modifié sans incrémenter la version TFM ?

@davidfowl pour d'autres implémentations de n'importe quel élément de la pile et des tests. Et parce qu'avec la façon dont les abstractions sont (ne nécessitant pas MVC) comme une répartition décente entre 2 bibliothèques au lieu de "supposez que tout le monde a MVC et veut toutes les dépendances".

Si les abstractions ne sont pas réellement des abstractions et sont si étroitement couplées à ASP.NET Core lui-même, pourquoi ne supprimons-nous pas simplement ces packages ? C'est une question honnête, car cela rendrait la vie plus facile et plus claire si c'est l'objectif global de la relation. J'essaie de comprendre l'intérêt d'avoir des abstractions en tant que packages séparés si elles sont effectivement liées à une implémentation/utilisation simple. Je dirais que personne en dehors de Microsoft ne veut ou n'a les ressources à consacrer à un serveur Web concurrent netcoreapp2.x (heureux d'être corrigé là-bas !).

Pouvez-vous préciser quel serait l'intérêt des abstractions dans un monde netcoreapp2.x ? Ou s'il est prévu de simplement les déprécier dans la version 2.0 ?

Selon dotnet/corefx#4721, la prise en charge ALPN pour SslStream ne sera pas prête pour .NET Core 2.0. En supposant que cela soit finalement mis en œuvre quelques mois plus tard, cela signifie-t-il que l'on pourra l'utiliser pour cibler le TFM netcoreapp2.0 ? Dans ce cas, que se passera-t-il si je décide de publier une bibliothèque basée sur netcoreapp2.0 qui utilise de nouvelles API qui ne faisaient pas partie de la forme initiale de netcoreapp2.0 si mes utilisateurs utilisent un runtime .NET Core plus ancien ? Va-t-il planter ? Ou netcoreapp2.x sera-t-il aligné avec netstandard1.x, dont le contrat ne peut pas être modifié sans incrémenter la version TFM ?

ASP.NET version x s'alignera simplement sur .NET Core version x. Le TFM sera mis à jour pour s'aligner sur chaque version de .NET Core. C'est un produit unique qui peut enfin être traité comme tel. C'est l'une des simplifications majeures que nous faisons comme @DamianEdwards le mentionne ci-dessus. Nous ne briserons pas les gens qui construisent des bibliothèques en ajoutant de nouvelles API dans le noyau sans changer le TFM.

@NickCraver

pour d'autres implémentations de n'importe quel élément de la pile et des tests.

Quelles autres implémentations ? Existe-t-il d'autres éléments de la pile qui implémentent ASP.NET Core.

Si les abstractions ne sont pas réellement des abstractions et sont si étroitement couplées à ASP.NET Core lui-même, pourquoi ne supprimons-nous pas simplement ces packages ? C'est une question honnête, car cela rendrait la vie plus facile et plus claire si c'est l'objectif global de la relation. J'essaie de comprendre l'intérêt d'avoir des abstractions en tant que packages séparés si elles sont effectivement liées à une implémentation/utilisation simple. Je dirais que personne en dehors de Microsoft ne veut ou n'a les ressources à consacrer à un serveur Web netcoreapp2.x concurrent (heureux d'être corrigé là-bas!).

Pouvez-vous préciser quel serait l'intérêt des abstractions dans un monde netcoreapp2.x ? Ou s'il est prévu de simplement les déprécier dans la version 2.0 ?

Nous pourrions tout mettre dans un seul assemblage, mais la refactorisation nous offre une flexibilité future que nous n'aurions pas autrement si nous faisions cela. Cela ouvre même la possibilité d'avoir d'autres implémentations et ne l'exclut pas vraiment à long terme.

En termes simples, les abstractions visent à réduire le nombre de dépendances, et non à assurer la portabilité de la plate-forme.

Nous ne briserons pas les gens qui construisent des bibliothèques en ajoutant de nouvelles API dans le noyau sans changer le TFM.

Vous avez dit que vous vouliez opter pour netcoreapp2.0 - uniquement car il se déplaçait plus rapidement - par rapport à .NET Desktop et par extension, .NET Standard - mais quel est l'intérêt de cibler netcoreapp2.0 au lieu de netstandard2.0 si vous ne pouvez pas bénéficier des nouvelles API .NET Core sans changer le TFM ? (par exemple netcoreapp2.1 )

Vous avez dit que vous vouliez opter pour netcoreapp2.0 uniquement car il se déplaçait plus rapidement - par rapport à .NET Desktop et par extension, .NET Standard - mais quel est l'intérêt de cibler netcoreapp2.0 au lieu de netstandard2.0 si vous le pouvez Vous ne bénéficiez pas des nouvelles API .NET Core sans changer le TFM ? (par exemple netcoreapp2.1)

Désolé, je me suis mal exprimé, je veux dire netcoreapp2.x pas netcoreapp2.0 .

D'accord, je suis totalement confus, maintenant.

Désolé, je me suis mal exprimé, je veux dire netcoreapp2.x pas netcoreapp2.0.

Je ne suis pas sûr de comprendre. Voulez-vous dire qu'il y aura une équivalence entre les packages ASP.NET Core 2.1 et le netcoreapp2.1 TFM ?

Voulez-vous dire qu'il y aura une équivalence entre les packages ASP.NET Core 2.1 et le netcoreapp2.1 TFM ?

Ouais. Pensez aux 2 comme un dans le même. Voir https://github.com/aspnet/Home/issues/2022#issuecomment -299544884

Alors qu'est-ce qui vous empêche d'adopter un modèle similaire, mais avec netstandard ? Ce serait la meilleure approche, à mon humble avis : de nouvelles API pourraient être adoptées via de nouveaux TFM et les personnes qui ont besoin de prendre en charge .NET Desktop pourraient toujours exécuter leurs applications ASP.NET Core sur le framework complet.

ASP.NET Core 2.1/.NET Core 2.1/.NET Desktop 4.7.1 -> netstandard2.1
ASP.NET Core 2.2/.NET Core 2.2/.NET Desktop 4.8 -> netstandard2.2 .

@PinpointTownes parce que .NET Framework sur le bureau ne peut pas être livré assez rapidement, c'est le nœud de la plupart des problèmes de version avec Core. C'est un problème difficile dans une immense chaîne.

.NET Standard ne se déplacera pas à la même vitesse que .NET Core. Nulle part près de lui en réalité. Un déplacement dans .NET Standard laisse essentiellement toutes les plates-formes derrière, jusqu'à ce qu'elles rattrapent leur retard, et .NET Framework est à la fois le plus lent et le plus volumineux.

Jeton de point, bien que je ne sois pas sûr de la vitesse à laquelle .NET Framework est censé être expédié (par exemple, les nouvelles API ECDSA ont été portées de CoreFX à NetFX en moins d'un an, ce qui semble être un délai raisonnable pour ces composants cryptographiques sensibles ).

La compilation croisée est une surcharge qui doit être équilibrée avec les besoins des clients et des produits.

Quand vous aurez une minute, j'aimerais en savoir plus sur la nature exacte de la surcharge causée par la compilation croisée. Merci.

Ce dont nous avons besoin de vous tous, c'est d'une liste/compréhension claire de POURQUOI vous pensez avoir besoin d'ASP.NET Core 2.0 pour fonctionner sur net461+. Soyez précis afin que nous puissions combler ces lacunes et permettre à chacun de réussir.

Pour le moment, nous avons besoin de la version complète des bibliothèques clientes WCF - car les versions netstandard / netcore (https://github.com/dotnet/wcf) ne sont pas près d'être terminées.

Quand vous aurez une minute, j'aimerais en savoir plus sur la nature exacte de la surcharge causée par la compilation croisée. Merci.

Il y aura un moment dans un avenir très proche où nous ne pourrons littéralement pas polyfiller des fonctionnalités telles que la prise en charge ALPN pour SSLStream. De plus, nous n'avons même pas commencé à nous dégourdir les jambes et à ajouter des API dans .NET Core, jusqu'à présent, nous nous sommes embourbés dans le portage des choses vers .NET Standard et .NET Core 2.0 (tout l'objectif de .NET Standard 2.0) . Nous allons ajouter de nouvelles API et enfin les consommer dans ASP.NET Core le jour 1.

Pour le moment, nous avons besoin de la version complète des bibliothèques clientes WCF - car les versions netstandard / netcore (https://github.com/dotnet/wcf) ne sont pas près d'être terminées.

@ctolkien C'est un problème et c'est la raison pour laquelle nous avons porté le client WCF en premier lieu. Savez-vous ce qui vous bloque ? C'est une bonne occasion de nous aider à prioriser.

@davidfowl https://github.com/dotnet/wcf/issues/8

Il y en a peut-être plus, ce n'était que le premier obstacle que nous avons rencontré avant de passer au cadre complet wcf.

Il y aura un moment dans un avenir très proche où nous ne pourrons littéralement pas polyfiller des fonctionnalités telles que la prise en charge ALPN pour SSLStream.

Comment est-ce un problème? AFAICT, personne ici n'a jamais dit que les versions .NET Desktop et .NET Core d'ASP.NET Core devaient prendre en charge exactement le même ensemble de fonctionnalités. Si une fonctionnalité n'est pas disponible sur .NET Desktop en raison d'API manquantes (par exemple HTTP 2/0), pourquoi ne pas la rendre .NET Core uniquement et lancer un PlatformNotSupportedException indiquant au développeur que la fonctionnalité qu'il recherche est indisponible?
Ce serait bien mieux que de rendre tous les packages ASP.NET Core uniquement .NET Core, même s'il est peu probable que la plupart d'entre eux utilisent de nouvelles API BCL.

@davidfowl Je suppose que l'une des principales craintes est que les choses ne soient pas corrigées dans, disons, netcoreapp2.3 , elles le sont dans netcoreapp2.4 . Si ASP.NET Core se concentre sur le train le plus rapide, combien de temps avec chaque version mineure obtenez-vous l'amour ? Si nous devons constamment mettre à niveau, alors chaque consommateur doit constamment mettre à niveau.

C'est très bien pour obtenir le meilleur et le plus récent, mais ce n'est pas le meilleur pour la plupart des entreprises. Nous devons donc soit maintenir de nombreuses versions (chaque version mineure) avec nos bibliothèques pour chaque consommateur d'ASP.NET Core (pour ne pas dépendre de la dernière et suivre le rythme), soit faire glisser les utilisateurs vers la dernière version pour suivre le rythme. Ce n'est pas convivial pour des choses comme l'environnement validé.

À moins que les abstractions n'aient besoin de tourner aussi vite (des exemples ?), Il serait préférable de les déconnecter. De cette façon, vous n'entraînez pas l'ensemble de l'écosystème avec chaque mise à niveau. Je suppose que je suis plus inquiet non pas qu'ils soient sur netcoreapp , mais qu'ils soient continuellement mis à jour et que tout soit étroitement lié.

Si les abstractions maintiennent chaque version mineure et déplacent la douleur (pour être franc) de votre côté, je suis beaucoup moins inquiet. Pouvez-vous les gars élaborer sur les intentions avec des révisions ici?

@PinpointTownes :

pourquoi ne pas le rendre .NET Core uniquement et lancer une exception PlatformNotSupportedException indiquant au développeur que la fonctionnalité qu'il recherche n'est pas disponible ?
Ce serait bien mieux que de rendre tous les packages ASP.NET Core uniquement .NET Core, même s'il est peu probable que la plupart d'entre eux utilisent de nouvelles API BCL.

Noooooooon, s'il te plait non. C'est un échec d'exécution et un comportement très indésirable . Nous voulons avoir autant d'assurances au moment de la compilation que nos bibliothèques fonctionneront que possible. Il y a eu de nombreux débats à ce sujet, ce n'est tout simplement pas une bonne voie. PlatformNotSupported doit être évité autant qu'il est humainement possible.

C'est un échec d'exécution et un comportement très indésirable.

C'est exactement ce qui se passera avec l'approche "apportez vos assemblys .NET Desktop sur .NET Core" si vos assemblys tentent d'utiliser une API non prise en charge, sauf que vous obtiendrez un MissingMemberException au lieu d'un PlatformNotSupportedException .

Avec mon approche, vous pourriez au moins définir une meilleure histoire d'outillage avec des choses comme les analyseurs Roslyn qui pourraient déterminer au moment de la compilation si les API que vous utilisez sont prises en charge ou non.

Et BTW, jeter un PlatformNotSupported serait vraiment un cas de coin. Avec la compilation croisée, la meilleure option serait simplement d'exclure les API non supportées du contrat public.

@PinpointTownes Je pensais aussi de cette façon, mais la réalité est que de nouvelles plates-formes sont livrées et ce n'est tout simplement pas si simple. Après en avoir discuté plusieurs fois, mon esprit a beaucoup changé sur la façon de faire la compatibilité ici. Aller avec la direction netcoreapp permet d'envoyer des correctifs dans des versions mineures. Dans l'autre sens, vous devez attendre que .NET Desktop envoie les correctifs, ce qui... bonne chance. C'est un véhicule très lent pour les résolutions.

AFAICT, personne ici n'a jamais dit que les versions .NET Desktop et .NET Core d'ASP.NET Core devaient prendre en charge exactement le même ensemble de fonctionnalités. Si une fonctionnalité n'est pas disponible sur .NET Desktop en raison d'API manquantes (par exemple HTTP 2/0), pourquoi ne pas la rendre .NET Core uniquement

La première moitié est ce qu'est netstandard . Se différencier en netcoreapp est exactement ce qu'ils font ici. Sans les exceptions intentionnelles. C'est un vrai contrat sur cette route.

Vous voulez aller dans le sens de ce qui peut être corrigé et amélioré plus rapidement lorsque des lacunes sont impliquées, et non l'inverse. Les exceptions "PlatformNotSupported" peuvent être corrigées dans la bibliothèque demain, au lieu d'attendre que la plate-forme soit révisée dans 3 mois. .NET Core peut les prendre en charge plus rapidement car le code réel est livré avec , et non séparément en tant que redirecteurs la plupart du temps.

[@PinpointTownes] Si une fonctionnalité n'est pas disponible sur .NET Desktop en raison d'API manquantes (par exemple HTTP 2/0), pourquoi ne pas la rendre .NET Core uniquement et lancer un PlatformNotSupportedException indiquant au développeur que la fonctionnalité qu'il recherche n'est pas disponible ?

Nous devons équilibrer la simplicité de la surface et de la portée de l'API avec la productivité des développeurs. Jusqu'à présent, nous avons principalement utilisé PlatformNotSupportedException afin de fournir une surface d'API compatible avec le passé. Nous n'avons pas l'intention d'utiliser PlatformNotSupportedException comme moyen de fournir des ensembles de fonctionnalités disjoints à l'avenir. Au lieu de cela, nous abandonnerons la prise en charge des versions des plates-formes .NET qui ne disposent pas des fonctionnalités ou fournirons la fonctionnalité en tant que package NuGet indépendant qui lui-même n'est pas pris en charge partout.

Aller dans le sens netcoreapp permet d'envoyer des correctifs dans des versions mineures.

En quoi est-ce différent de l'approche 1.0 ? @davidfowl a déclaré que les nouvelles API nécessiteraient de nouveaux TFM, ce qui signifie que vous devrez désactiver LTS pour obtenir des correctifs reposant sur les nouvelles API .NET Core. Pas vraiment une situation idéale.

Se différencier de netcoreapp est exactement ce qu'ils font ici.

La différenciation est tout à fait acceptable et je suis tout à fait d'accord que .NET Core devrait être la cible préférée pour ASP.NET Core. Mais cela n'implique pas d'abandonner complètement .NET Desktop, en particulier lorsqu'il existe des alternatives telles que la compilation croisée.

Nous devons équilibrer la simplicité de la surface et de la portée de l'API avec la productivité des développeurs.

Sûr. Mais vous devez également équilibrer cela avec le fait que les bibliothèques héritées - développées pour .NET Desktop et utilisant des fonctionnalités non disponibles sur .NET Core - devraient fonctionner correctement dans ASP.NET Core 2.0, tout comme dans la version 1.0.

Au lieu de cela, nous abandonnerons la prise en charge des versions des plates-formes .NET qui ne disposent pas des fonctionnalités ou fournirons la fonctionnalité en tant que package NuGet indépendant qui lui-même n'est pas pris en charge partout.

C'est tout à fait correct en théorie. Mais la chose est que la plate-forme qui manque actuellement de fonctionnalités importantes est .NET Core, pas .NET Desktop. Cela changera probablement dans quelques années, mais ce qui est sûr, c'est que les gens trouveront toujours des fonctionnalités manquantes dans .NET Core 2.0.

Peut-être vaut-il la peine d'avoir un référentiel forward-port dans dotnet où les gens peuvent faire des demandes d'api pour des éléments spécifiques qu'ils considèrent comme manquants de .NET Core à partir de .NET Framework ?

Ensuite, les commentaires, les révisions et les conseils peuvent être effectués en dehors du bruit quotidien des dépôts de code ? Ou un dépôt général d'examen/spécification d'API (un peu comme csharplang vs roslyn)

Ce sera également un bon choix pour: "J'ai un problème de conversion et j'ai besoin de rechercher un problème lié à X api" Alors que corefx est très bruyant pour cela.

[@benaadams] Cela pourrait-il valoir la peine d'avoir un dépôt de port de transfert dans dotnet où les gens peuvent faire des demandes d'api pour des éléments spécifiques qu'ils considèrent comme manquants de .NET Core à partir de .NET Framework ?

Je dirais que ce sont simplement des problèmes dans CoreFx. En outre, notre promesse est généralement la suivante : si le type est partagé entre .NET Framework et .NET Core, nous avons l'intention de porter les membres nouvellement ajoutés vers .NET Framework. Dans de très rares cas, cela pourrait ne pas être possible, mais l'enjeu est qu'ils sont automatiquement pris en compte.

[@benaadams] Ou une révision générale de l'API/dépôt de spécifications

Pas sûr que ça en vaille la peine. Les révisions des API sont déjà un peu lourdes ; les extraire vers un autre repo semble amplifier cela. Je préférerais que nous continuions à rationaliser CoreFx afin que l'ajout de nouvelles API soit aussi simple que de le faire dans, disons, ASP.NET.

comme indiqué précédemment, ils pourront continuer à référencer les bibliothèques/frameworks ciblant .NET Framework, et cela fonctionnera très bien en supposant que les API qu'ils appellent font partie de la fermeture de netstandard2.0

@DamianEdwards Qu'en est-il des API non incluses dans la fermeture de netstandard2.0 ? La plupart des bibliothèques tierces sont des sources fermées. Comment puis-je savoir que chaque cas marginal se trouve dans la fermeture de netstandard2.0 ?
Comme @PinpointTownes l'a laissé entendre, c'est un peu comme jouer à la roulette russe.

L'outillage @MJomaa aidera ici, mais évidemment la seule façon de savoir avec certitude est de l'exécuter réellement. Ce n'est en fait pas différent d'une bibliothèque .NET Standard exécutée sur un framework pris en charge par .NET Standard. Les API existantes ne remplacent pas la nécessité de tester ces bibliothèques. Cela ne veut pas dire que les implémentations netstandard ne visent pas à être compatibles, mais ce sont des bords, par exemple https://github.com/dotnet/standard/blob/cc9f646354fc68a13707a82323d4032b8dbfda52/netstandard/src/ApiCompatBaseline.net461.txt

Ce sont des API qui existent dans NS 2.0 mais pas dans .NET Framework 4.6.1.

Je suis devenu très nerveux à propos de ce changement, mais après avoir lu le fil, cela semble bien en théorie. Nous avons 5 applications ASP.NET Core dont 4 sur le framework complet, mais c'était surtout nous qui étions défensifs qu'autre chose et qui prenions le chemin de la moindre résistance.

Je pense qu'une sorte d'outil intégré à VS comme l'analyseur de portabilité .NET Core pourrait aider les développeurs qui ne sont pas à jour sur Twitter/GitHub et ne savent même pas que cette extension existe. La fenêtre contextuelle "suggérer une extension" me vient à l'esprit, mais je ne sais pas quelle action une personne prendrait pour déclencher cela. Essayer d'ajouter une bibliothèque net46x à une application ASP.NET Core 2+ peut-être ?

Les choses que Microsoft ne peut pas contrôler comme le support tiers avec Telerik, Syncfusion, etc. seront également un bloqueur potentiel en fonction de ce qu'ils font.

La messagerie dans ce fil GitHub doit sortir dans un article de blog dès que possible avec une FAQ ou quelque chose du genre. J'ai l'impression d'être resté au courant de tout, et je n'étais toujours pas sûr à 100% si cela signifiait que nous pouvions référencer les bibliothèques net46x ou non. Je n'étais clairement pas le seul à être confus non plus.

Pour faire écho à ce que d'autres ont dit. J'ai parlé avec au moins 10 développeurs qui ne savaient pas qu'ASP.NET Core pouvait fonctionner sur un framework complet. J'ai eu la même expérience que @ aL3891, même si les développeurs étaient vraiment heureux de pouvoir exécuter ASP.NET Core sur un framework complet et leurs bibliothèques internes fonctionneraient tout simplement. Encore une fois - la messagerie sur .NET Core 2.0 ayant une grande majorité de cas d'utilisation sera très, très importante. La question d'avoir au moins une solution Windows uniquement pour System.DirectoryServices en cours sera également importante. Beaucoup de développeurs NET à qui je parle haussent les épaules lorsqu'ils entendent que .NET Core est multiplateforme et se soucient davantage du fonctionnement de leur code existant que de x-plat/perf.

Les gars, c'est une sorte de poubelle :(
Nous avons construit sur ASP.NET Core en raison de la possibilité de l'utiliser avec netfx, et nous avons construit des choses qui devaient durer 5 à 10 ans, pas pour 1 an de support maximum. C'est ce que le nom ASP.NET signifie dans les affaires et c'est pourquoi les grandes organisations lentes le choisissent plutôt que les frameworks du mois. Passons aux cas d'utilisation concrets.

Je travaille dans un groupe d'outillage qui construit des bibliothèques et des applications métier à usage interne à une entreprise et à vendre à des clients « entreprises ». Principalement des organisations gouvernementales dans notre cas, mais je suis sûr que vous entendrez la même chose du secteur privé. Nous avons des frameworks internes qui encodent des modèles commerciaux dans des abstractions communes - pensez à "IDatabaseConnection", "IEntityProvider", "IWizardFlow", "ICodeGenerator" - et construisez des interfaces RAD au-dessus de ces backends enfichables.

Dans notre pile, ASP.NET Core est un "plugin" - c'est une destination HTTP, utilisée comme abstraction de magasin de données et pour héberger des services, etc. C'est aussi un "frontend" - de toute évidence, un tas d'applications LOB sont des sites Web, et c'est un excellent nouveau cadre pour les applications Web. Nous avons donc des exigences d'interopérabilité bidirectionnelle - un code AN-C qui fait référence à d'autres composants aléatoires et un autre code aléatoire qui fait référence à AN-C.

Nous sommes totalement fans de Core CLR et de la portabilité, et nous avons porté un tas de nos composants sur un netstandard cible ou multicible. Jusqu'à présent, nous avons une application hébergée sur Linux et espérons en avoir d'autres à venir. Cependant, il n'y a aucun moyen que tout soit porté de sitôt ! Nous avons un code toujours vivant et activement développé qui s'appuie sur

• Authentification NTLM (y compris des scénarios avancés autour des jetons et des SPN)
• System.Drawing comme ci-dessus (ride intéressante ici : nous avons besoin d'anciens formats d'image comme TIFF, que les nouvelles bibliothèques OSS ne prennent pas en charge)
• Connexion aux apis WCF/SOAP - encore des tonnes et des tonnes de ceux-ci là-bas
• API de chiffrement Windows (y compris RSACng, ECDSA et CSP pour les jetons PKI)
• WPF guis - nos clients ne passeront pas bientôt à Windows 10 et même s'ils le font, ils ne voudront pas d'applications Store
• Interopérabilité Microsoft Office (en particulier Access et Excel) pour l'importation et l'exportation de données
• Extensibilité de Visual Studio
• Plugins tiers comme le fournisseur Oracle ADO.NET

Certaines de ces technologies ne seront jamais prises en charge par Core CLR. Mais ce sont de vraies technologies, qui sont à la base du développement de nouvelles applications - nous avons besoin d'une version de .NET qui a accès à tout cela. À l'heure actuelle, notre position est gérable : nous isolons les dépendances "héritées" (en réalité : spécifiques à la plate-forme) dans leurs propres composants qui sont spécifiques à net461. Des applications professionnelles spécifiques dépendent alors de netfx si elles ont besoin de ces fonctionnalités, et pas autrement. J'envisage un avenir où cela sera rare pour les nouvelles applications... mais il est difficile d'imaginer que ce soit jamais 0 %.

Vous avez fait tout ce travail sur csproj et le SDK parce que l'interopérabilité est importante. ASP.NET Core est la carotte, la raison de vouloir interop. Je ne pense pas qu'il soit logique de l'enlever. Et non, "vous pouvez charger vos références dans une direction, mais elles échoueront probablement à l'exécution" n'est pas l'interopérabilité.

@gulbanana Pouvez-vous décrire les parties du système qui utilisent ASP.NET Core pourquoi elles doivent être dans le même processus que .NET Framework. J'apprécie la liste (plugings Visual Studio, office interop, etc.), mais êtes-vous intégré ASP.NET Core dans tous ces endroits aujourd'hui (je n'ai pas une bonne image de la description ci-dessus) ?

De plus, qu'utilisiez-vous avant l'existence d'ASP.NET Core ? Ou est-ce juste une nouvelle entreprise qui n'a jamais utilisé ASP.NET mais a pris un pari de 5 à 10 ans sur ASP.NET Core sur .NET Framework ? Avez-vous regardé Katana?

OK, voici quelques études de cas spécifiques. Je dirai d'emblée que je suis sûr que beaucoup d'entre eux pourraient être gérés en exécutant le travail spécifique au bureau dans un processus séparé, bien que cela semble être un énorme problème de transformer un tas d'implémentations d'interface en RPC. Ce n'est pas comme si nous pouvions simplement utiliser la communication à distance ou la sérialisation binaire entre les CLR de base et de bureau, non plus.

NTLM/DA

À des fins d'authentification unique, nous avons des applications qui reposent sur le navigateur qui transmet les informations de connexion Windows à IIS, qui les transmet à un site Web ASP.NET Core. Une partie du processus d'authentification consiste ensuite à rechercher des informations, par exemple si l'utilisateur appartient à un groupe AD particulier. J'aimerais vraiment en savoir plus sur le "pack de support Windows" et savoir s'il est destiné à couvrir des choses comme celle-ci.

System.Drawing

Ceci est utilisé dans une application Web qui crée des vignettes et des modifications d'image de base (rotation, superposition de filigrane). La plupart des images utilisées remontent à l'époque des dinosaures, il y a donc des choses comme TIFF là-dedans. Il s'agit de données conservées par un ministère gouvernemental concernant des listes de propriétés particulières et la gestion des terres. Dans ce cas, l'application était initialement ASP.NET MVC et a été mise à niveau/réécrite via MVC 2, 4, 5 et maintenant Core.

VSIX

Il s'agit d'intégrer AN-C dans netfx au lieu de l'inverse. Nous avons des extensions Visual Studio pour la génération de code qui exécutent des "modèles" pour divers scénarios RAD. Certains de ces modèles ont été créés pour le développement Web et font référence aux types AN-C au moment de la conception (ils sont créés à l'aide du préprocesseur/d'exécution T4).

Crypto

Celui-ci doit vraiment être en cours, je pense - nous avons des scénarios de licence où le code est très sensible à la sécurité. D'une manière générale, il décrypte et vérifie les fichiers de licence par rapport à l'environnement dans lequel le code s'exécute - il s'agit d'une bibliothèque commune utilisée dans le backend des applications Web ainsi que des applications de bureau. Finalement, .NET Core semble susceptible d'obtenir suffisamment de support cryptographique pour que celui-ci puisse être porté, mais ce n'est pas le cas aujourd'hui. Par exemple, l'une des options que nous avons aujourd'hui est la prise en charge des jetons Fortinet/ePass2003 PKI, où leur middleware ne prend définitivement pas en charge Core (et il n'y a pas de délai pour le faire).

Oracle ADO.NET

L'utilisation d'Entity Framework 6 avec un backend Oracle n'a pas besoin d'être in-proc, mais il serait certainement gênant pour nos sites Web d'ajouter un niveau supplémentaire juste pour accéder à une base de données !

Interopérabilité WPF

Nous utilisons Microsoft.Extensions.Logging dans toutes nos applications de bureau ces jours-ci - les abstractions de journalisation elles-mêmes devront être in-proc, même si les implémentations ne le sont pas.

Quant à ce que nous utilisions avant ASP.NET Core - ASP.NET MVC ! On pourrait y retourner mais ce serait vraiment dommage de renoncer à tous les avantages.

En tant qu'architecte, c'est mon bordel de ne pas avoir cherché à savoir si "ASP.NET Core s'exécute sur un framework complet" persisterait au-delà de la première version. Honnêtement, il ne m'est jamais venu à l'esprit que ce ne serait pas le cas. Je n'imaginais tout simplement pas la possibilité que dès 2018, il n'y ait par exemple aucune version prise en charge qui puisse charger des documents Office ...

Une chose sur laquelle je ne suis pas clair est l'endroit où ASP.NET Core est utilisé dans chacun de ces scénarios que vous mentionnez.

NTLM/DA

Celui-ci a du sens et j'aimerais comprendre à quelles API cela finit par mapper. Est-ce juste System.DirectoryServices ? Celui-ci est activement travaillé (vous pouvez le voir dans corefx).

System.Drawing

C'est une lacune connue que nous cherchons à combler. Je n'ai pas encore de réponses ici et je ne suggérerai pas de réécrire à l'aide d'ImageSharp (bien que ce soit une option). Il faudra régler ce problème.

VSIX

Où est le noyau ASP.NET ici ? Fonctionne-t-il à l'intérieur d'une extension de studio visuel ?

Crypto

Y a-t-il un problème de corefx pour celui-ci ? Pourquoi ne serait-il pas simplement porté ? Contrairement à .NET Framework, les versions de .NET Core sont découplées du système d'exploitation, il est donc possible que cela se produise plus tôt que tard si cela est jugé important. (Avis de non-responsabilité : je n'en sais pas assez sur la cryptographie pour comprendre les implications de cette multiplateforme).

Oracle ADO.NET

Où ASP.NET Core entre-t-il ici ? Êtes-vous simplement en train de dire que le fournisseur Oracle n'a pas encore été porté sur .NET Core ?

Nous utilisons Microsoft.Extensions.Logging dans toutes nos applications de bureau ces jours-ci - les abstractions de journalisation elles-mêmes devront être in-proc, même si les implémentations ne le sont pas.

Microsoft.Extensions.* restera netstandard donc vous y êtes couvert.

Pourquoi pas d'annonce/discussion ?
J'aime ce que fait l'équipe aspnet/.net core, mais j'ai les mêmes craintes que @jhurdlow.

Heureux d'entendre parler de MEL Sur les autres points-

NTLM

Voici une classe qui est utilisée dans la plupart de nos applications. Il fait une utilisation assez triviale de l'API, des choses qui, espérons-le, pourraient être portées en théorie (mais ne l'ont pas été).
https://gist.github.com/gulbanana/70fe791735ee884169e2eee354a32ad2

VSIX

Les modèles de codegen spécifiques au noyau asp.net utilisent le système d'action/routage (IFileProvider, etc.) pour découvrir les contrôleurs et les vues, etc. et remplir notre échafaudage. Nous n'hébergeons pas d'hébergeur ASP.NET dans Visual Studio, nous nous contentons d'introspecter les applications ASP.NET.

Crypto

Je soupçonne que les algorithmes que nous utilisons seront portés, mais ils ne l'ont pas encore été. Tout cela aurait l'air très différent si la prémisse était, par exemple, une annonce d'un plan à long terme pour abandonner le support pour asp.net-core-on-netfx et une discussion sur le moment où cela pourrait être possible !

Oracle

Oui, cela serait résolu si un port Oracle se produisait (en supposant qu'il soit complet, etc.).

Un autre cas d'utilisation :
L'une de nos applications importe des données héritées d'une application Access. À l'heure actuelle, ce processus d'importation s'exécute sur un serveur dans un site Web principal asp.net. Il utilise l'interopérabilité COM pour charger acedao.dll partir du redistribuable du moteur accdb/jet, lit les tables dans nos abstractions d'entité, puis les enregistre dans une base de données SQL plus moderne.

C'est un autre cas de "pourrait être hors procédure, mais pourquoi devrait-il l'être". Nous utiliserions essentiellement AN-C comme interface vers un site Web WebAPI 2 ou quelque chose du genre, auquel cas nous sommes revenus à cette dépendance du passé :(

Dans l'ensemble, notre objectif est de déplacer la grande majorité de ce que nous faisons vers .NET Core. Nous aimerions autant d'interopérabilité que possible aussi longtemps que possible pendant que nous déplaçons les choses...

WTF !!! 😨
Êtes-vous en train de dire qu'ASP.NET Core 2 ne ciblera plus Full .NET framework 4.x !!!
Nous venons de démarrer un projet il y a 1 mois avec ASP.NET Core 1.1 et nous avons ciblé .NET 4.6 car nous référençons certaines Full .NET Lib. Et nous allions passer à ASP.NET Core 2. Mais ce que j'entends dans ce post... 😞
Écoutez, nous avons choisi ASP.NET Core en raison de ses avantages (DI, API fusionnée et MVC, ... puissant), alors, s'il vous plaît, donnez un changement mec.

Nous venons de démarrer un projet il y a 1 mois avec ASP.NET Core 1.1 et nous avons ciblé .NET 4.6 car nous référençons certains Full .NET Lib

A quoi servent ces bibliothèques ? Avez-vous lu la réponse initiale de @shanselman https://github.com/aspnet/Home/issues/2022#issuecomment -299536123 ? Il est possible de référencer certaines bibliothèques .NET Framework dans .NET Core 2.0 (en supposant qu'elles restent dans le sous-ensemble d'API).

A quoi servent ces bibliothèques ? Avez-vous lu la réponse initiale #2022 (commentaire) de @shanselman ? Il est possible de référencer certaines bibliothèques .NET Framework dans .NET Core 2.0 (en supposant qu'elles restent dans le sous-ensemble d'API).

@davidfowl oui j'ai lu le commentaire de @shanselman , nous utilisons des bibliothèques créées par la société, certaines de ces bibliothèques utilisent WCF, toutes ces bibliothèques sont stables, elles ciblent .NET 3.5 et nous ne pouvons pas les toucher.

Cela va être une situation très courante. J'aimerais savoir si des informations ont été recueillies (télémétrie?) Sur le nombre d'utilisateurs d'ASP.NET Core sur .NET Core vs .NET Framework jusqu'à présent.

Je ne suis personnellement pas émotif à ce sujet, mais quelques observations:

• la plupart des clients que j'ai aujourd'hui utilisent la combinaison de framework asp.net core 1.x/full parce qu'ils ont peur de se lancer dans les nouveautés
• D'après les numéros de téléchargement du package nuget, l'adoption du noyau asp.net n'est pas géniale. Avec ce déménagement, il sera encore un peu plus difficile de vendre quelque chose qui ne se vend pas bien en ce moment.
• c'est formidable que vous ayez identifié les éléments LDAP comme étant une lacune (je pense que je n'ai jamais vu personne au cours des 10 dernières années utiliser ces bibliothèques, mais c'est peut-être juste moi). Le plus gros problème sera les bibliothèques tierces. Ce seront les vraies raisons pour lesquelles les gens ne passeront pas au noyau .net

Toute cette situation est encore une fois un autre bon exemple de MS qui prend une décision sans préavis. Ce n'est que parce que certaines personnes suivent les check-ins que ce fil existe ici.

Je me trompe peut-être, mais je pensais que .NET Core était désormais sous la gouvernance du DNF - donc ces décisions ne sont plus purement internes à MS.

Le truc LDAP/AD est certainement une raison pour laquelle je dois rester au top de net462 en ce moment. J'aimerais aller complètement, BAM -> NetCore complètement, mais c'est un inconvénient.

J'utilise également XML-RPC.net dans l'un de mes projets. Il utilise de sérieux Reflection.Emit, et je ne sais pas si NetCore 2 le supportera complètement. Je vais devoir essayer l'analyseur de portabilité pour voir avec certitude, cependant.

Je trouve toute cette situation un peu décourageante avec la rapidité et la facilité avec lesquelles une décision importante comme celle-ci qui affecte l'avenir de .NET peut se produire sans aucune transparence, à la dernière minute, encore une fois. Beaucoup d'énergie a été investie dans la vente de l'écosystème .NET existant lors de la migration vers ASP.NET Core, la messagerie (d'après ce que j'ai compris) étant que .NET Standard 2.0 se concentrera sur la compatibilité et sera la version qui comblera l'écart avec .NET v4.x pour enfin produire une plate-forme .NET solide et stable sur laquelle l'écosystème peut enfin compter. Personnellement, je ne crois pas que .NET Core décollera vraiment avant la sortie de .NET Standard 2.0, car je prévoyais qu'il s'agirait de la "terre stable promise" que nous attendons tous - maintenant je n'ai aucune idée de ce que ".NET Standard 2.0" signifie ce qu'il va couvrir exactement et quelles bibliothèques sont prévues pour être .NET Core uniquement.

Comme il n'y a pas eu d'annonce officielle préalable, de demande de commentaires, de sondage ou de justification, cette décision "semble" avoir été prise sans aucune implication de la communauté ni analyse d'impact sur l'écosystème .NET existant et fragmentera probablement l'ensemble de l'écosystème pour de nombreuses personnes. les années à venir. La suppression de la prise en charge de .NET v4.x supprime un chemin de migration fluide pour de nombreuses entreprises afin de pouvoir migrer leurs bases de code existantes vers le nouveau modèle de développement d'ASP.NET. Cela ne les encouragera pas à passer plus rapidement à .NET Core, cela les empêchera même d'essayer, provoquant une fragmentation massive qui fracturera l'écosystème .NET en deux. Je ne vois pas en quoi cela finira par être différent de Python 2/3 qui a été irrémédiablement endommagé par la fragmentation dont il n'a toujours pas pu se remettre depuis près d'une décennie.

La plupart des bases de code .NET existantes sont des friches industrielles développées en coulisses par des développeurs .NET "de matière noire", dont la plupart n'auront aucune idée que cette décision a été prise étant donné que .NET Core 1.1 prend en charge .NET v4.x et la messagerie pour .NET Standard 2.0 était la promesse d'une meilleure compatibilité. Je m'attends à un contrecoup massif une fois que la nouvelle et l'impact de cette décision arriveront enfin à la maison. De nombreux développeurs qui ont vendu l'adoption de .NET Core en interne au sein de leur organisation vont se sentir trahis étant donné qu'ils ont effectivement migré vers une plate-forme sans issue (s'ils ne peuvent pas migrer complètement vers .NET Core pour une raison quelconque ) une dure réalité à laquelle ils devront faire face juste après avoir réussi la décision monumentale de convaincre les parties prenantes de leur organisation d'approuver les ressources nécessaires à leur migration actuelle.

La plupart des organisations doivent migrer leurs bases de code existantes "en vol" où elles doivent déployer en continu leurs systèmes existants tout en migrant leur base de code "en parallèle" qui voudront se déployer d'abord sur .NET v4.x, puis une fois que tout s'est stabilisé et que tous les problèmes ont été résolus, ils peuvent alors planifier une migration complète vers .NET Core à partir de là.

Cette décision est également prise dans le contexte d'années de modifications radicales d'ASP.NET qui, selon l'OMI, ont érodé la confiance que .NET est une plate-forme stable sur laquelle les organisations peuvent compter. J'adore le nouveau modèle de développement de .NET Core, mais pour l'OMI, ce dont nous avons le plus besoin, c'est d'une plate-forme stable sur laquelle nous pouvons compter et que le reste de l'écosystème peut rattraper. .NET Core est toujours dans une étrange vallée, avec des outils immatures, des dépendances incompatibles, des problèmes d'exécution, une documentation obsolète, etc. Je n'ai pas vu .NET aussi instable depuis les premiers jours de sa première publication.

Pourquoi ne pas lancer un sondage sur ce que les développeurs .NET veulent de plus ? c'est-à-dire une plate-forme polie solide et stable ou une plate-forme "rapide" qui offre de nouvelles fonctionnalités plus rapidement ? Je comprends que cela nécessiterait beaucoup moins d'efforts de ne pas avoir à se soucier des fonctionnalités de rétroportage vers .NET v4.x, mais il serait inestimable d'avoir une version d'ASP.NET Core qui se concentre principalement sur la fourniture d'une plate-forme compatible stable avec de longs prise en charge de terme qui peut s'exécuter sur .NET v4.x ou .NET Core.

Ce navire a-t-il navigué ou existe-t-il une option pour conserver ASP.NET Core 2.0 tel quel ? c'est-à-dire avec la plupart des bibliothèques et des abstractions couvertes par .NET Standard 2.0, puis dans la prochaine version d'ASP.NET Core 3.0 annoncent que la prochaine plate-forme sera uniquement .NET Core ? Cela permettra aux organisations de continuer à aller de l'avant et d'adopter ASP.NET Core 2.0 et permettra au reste de l'écosystème de rattraper son retard, avec des outils et des bibliothèques stables et bien pris en charge, tout en ayant une séparation nette d'où .NET Core seule plate-forme/ les fonctionnalités commencent.

Il est possible de référencer certaines bibliothèques .NET Framework dans .NET Core 2.0 (en supposant qu'elles restent dans le sous-ensemble d'API).

Cela respire l'incertitude, très peu de gens voudront risquer leur réputation, la santé et la stabilité de leurs systèmes et tenter une migration complète vers .NET Core lorsqu'il existe une incertitude sur laquelle de leurs dépendances pourra et ne pourra pas s'exécuter sur .NET Core, ce qui signifie que plus de personnes restent sur .NET v4.x dans un avenir prévisible.

Je ne sais pas vraiment comment cela se déroulera finalement et quel sera le véritable impact de cette décision sur l'ensemble de l'écosystème .NET, mais le fait que des décisions importantes comme celle-ci avec un large impact puissent se produire sans aucune implication de la communauté externe est préoccupant.

J'aimerais que vous soyez un peu moins déterminés à diviser votre base d'utilisateurs.

Mon point de vue lors de la création d'une bibliothèque est de la rendre le plus facile à utiliser possible, pour le plus grand nombre de personnes possible, dans le plus d'endroits possibles. C'est une douleur dans le cou (recherchez les directives de compilateur #if dans Newtonsoft.Json et vous obtenez plus de 1300 résultats) mais "ça marche" est un argument de vente puissant.

Pourquoi ne pas lancer un sondage sur ce que les développeurs .NET veulent de plus ? c'est-à-dire une plate-forme polie solide et stable ou une plate-forme "rapide" qui offre de nouvelles fonctionnalités plus rapidement ? Je comprends que cela nécessiterait beaucoup moins d'efforts de ne pas avoir à se soucier des fonctionnalités de rétroportage vers .NET v4.x, mais il serait inestimable d'avoir une version d'ASP.NET Core qui se concentre principalement sur la fourniture d'une plate-forme compatible stable avec de longs prise en charge de terme qui peut s'exécuter sur .NET v4.x ou .NET Core.

Véritable question, ASP.NET Core 1.x prend actuellement en charge .NET Framework et .NET Core. Disons qu'il s'agissait de la plate-forme stable que vous avez mentionnée ci-dessus, que nous avons corrigé et pris en charge sur les deux environnements d'exécution, mais que nous n'avons pas obtenu plus de fonctionnalités. Serait-ce suffisant ?

ASP.NET Core et .NET Core sont les plates-formes riches en fonctionnalités à évolution rapide pour .NET à ce stade. C'est une version de .NET qui n'est liée à aucun système d'exploitation et qui nous donne l'agilité nécessaire pour innover rapidement et publier plus rapidement.

Ce navire a-t-il navigué ou existe-t-il une option pour conserver ASP.NET Core 2.0 tel quel ? c'est-à-dire avec la plupart des bibliothèques et des abstractions couvertes par .NET Standard 2.0, puis dans la prochaine version d'ASP.NET Core 3.0 annoncent que la prochaine plate-forme sera uniquement .NET Core ? Cela permettra aux organisations de continuer à aller de l'avant et d'adopter ASP.NET Core 2.0 et permettra au reste de l'écosystème de rattraper son retard, avec des outils et des bibliothèques stables et bien pris en charge, tout en ayant une séparation nette d'où .NET Core seule plate-forme/ les fonctionnalités commencent.

Nous sommes toujours ouverts aux commentaires et ASP.NET Core 2.0 n'a pas encore été livré. Si ASP.NET Core 3.0 était la version qui a abandonné .NET Framework, cela améliorerait-il les choses ? Si vous regardez certains des commentaires de @gulbanana et @ikourfaln , il existe des technologies qui ne seront probablement jamais portées et ne fonctionneront donc jamais sur .NET Core, cela ne signifie-t-il pas qu'il faut supporter .NET Framework à peu près pour toujours ? N'aurions-nous pas la même discussion dans un an ? Peut-être que d'ici là, l'écosystème ou les bibliothèques qui prennent en charge .NET Core seraient plus grands et auraient donc moins d'impact ? Qu'en est-il de ces bibliothèques d'entreprise qui ne seront jamais mises à jour (ou dont le code source a été perdu) ? Est-ce que ça changera dans un an ?

Mon point de vue lors de la création d'une bibliothèque est de la rendre le plus facile à utiliser possible, pour le plus grand nombre de personnes possible, dans le plus d'endroits possibles. C'est une douleur dans le cou (recherchez les directives du compilateur #if dans Newtonsoft.Json et vous obtenez plus de 1300 résultats) mais "Ça marche juste" est un argument de vente puissant.

Aucune offense @JamesNK mais JSON.NET est un analyseur JSON et pour la plupart un seul paquet (je sais qu'il y en a quelques autres). ASP.NET Core a > 200 packages.

Sans vouloir vous offenser, je suis un gars qui travaille à temps partiel. Votre problème est plus difficile mais vous avez exponentiellement plus de ressources.

Après avoir lu ceci et examiné les dépendances que nous avons, je suis beaucoup moins convaincu que ce soit une bonne idée.

Dans l'état actuel des plans, nous ne pouvons transférer aucune de nos applications vers netstandard / netcoreapp jusqu'à ce que System.DirectoryServices soit disponible ( CoreFX numéro 2089 ici ). Ainsi, bien que nous puissions porter vers ASP.NET Core 1.x, nous ne pouvons pas passer à 2.0. En regardant les applications ici : Opserver, Stack Overflow lui-même, nos applications internes... rien ne serait prêt car la version 2.0 est censée l'être à ce stade. Selon le standup de cette semaine, des éléments critiques comme DirectoryServices suivraient toujours dans une version 2.x ultérieure.

Donc, entre 1.0 et 2.0, c'est passé de quelque chose vers lequel je me préparais à passer, à quelque chose vers lequel je ne peux pas aller. Alors oui, je dirais que ce n'est pas prêt. ASP.NET est un moyen d'exposer les bits dont j'ai besoin via HTTP. ASP.NET n'est pas la chose dont j'ai besoin en soi. Je n'utilise pas .NET uniquement pour les éléments Web, je l'utilise pour la plate-forme... comme beaucoup de gens. La plate-forme n'est pas prête pour la grande variété de cas d'utilisation demandés par les utilisateurs, donc forcer les utilisateurs sur cette plate-forme provoque des douleurs et des blocages.

L'essentiel est que si nous avons besoin d'AD auth (une grande partie de la plate-forme), nous venons d'être abandonnés sur la ligne 1.x. C'est là que je me dirigeais avec nos applications... mais si telle est la direction, il est inutile de faire des efforts ici jusqu'à ce que les éléments dont j'ai besoin soient disponibles à destination.

Si nous pouvons dire que ces choses critiques comme System.DirectoryServices , System.Drawing , et les autres éléments principaux dont les gens ont besoin seront prêts avec ASP.NET Core 2.0, mon opinion change beaucoup. S'il s'agit d'une réflexion après coup (comme le montrent les calendriers actuels), veuillez continuer à prendre en charge le .NET Framework jusqu'à ce qu'ils le soient.

Se déplacer rapidement, c'est bien. Je l'aime. J'exécute des alphas en production en ce moment. Mais rien de tout cela n'a d'importance si cela ne fonctionne pas pour votre cas d'utilisation en premier lieu.

Une chose avec laquelle je me bats personnellement est la différence entre "plate-forme stable" et "nouvelles fonctionnalités". D'une part, nous voulons que la plate-forme soit stable, fiable et compatible, d'autre part, personne ne veut rester sur 1.x car elle n'a pas de fonctionnalités 2.x. Y a-t-il des fonctionnalités super convaincantes dans ASP.NET Core 2.x qui attirent les gens dans cette direction ou est-ce simplement le fait que nous avons plus de fonctionnalités que nous n'en avions dans 1.x (parce que c'est nouveau et brillant) ?

Si c'est le dernier cas, alors ces gens se soucient-ils de la stabilité ? Si la réponse est oui, alors pourquoi ASP.NET Core 1.x n'est-il pas suffisant ?

Je n'utilise pas .NET uniquement pour les éléments Web, je l'utilise pour la plate-forme... comme beaucoup de gens. La plate-forme n'est pas prête pour la grande variété de cas d'utilisation demandés par les utilisateurs, donc forcer les utilisateurs sur cette plate-forme provoque des douleurs et des blocages.

D'accord, mais à votre avis, quel est le lien avec la suppression de la prise en charge de .NET Framework par ASP.NET Core 2.x ? Lorsque davantage de dépendances seront mises en ligne, elles fonctionneront partout, donc dans un sens, à mesure que la plate-forme progresse, le large éventail d'environnements d'exécution en bénéficiera. Toutes les versions des applications ASP.NET Core pourraient soudainement tirer parti de ces fonctionnalités.

Si c'est le dernier cas, alors ces gens se soucient-ils de la stabilité ? Si la réponse est oui, alors pourquoi ASP.NET Core 1.x n'est-il pas suffisant ?

Tout le monde veut toujours de nouvelles fonctionnalités, la possibilité de nouvelles fonctionnalités, ou au moins savoir qu'ils auront la possibilité d'obtenir plus de goodies plus tard. Lorsque vous fermez une plate-forme et que vous la mettez en mode "stable"/"maintenance, les gens voient qu'on n'y prête plus attention.

Y a-t-il des fonctionnalités super convaincantes dans ASP.NET Core 2.x qui attirent les gens dans cette direction ou est-ce simplement le fait que nous avons plus de fonctionnalités que nous n'en avions dans 1.x (parce que c'est nouveau et brillant) ?

Support - c'est ce que nous payons.

Si la réponse est oui, alors pourquoi ASP.NET Core 1.x n'est-il pas suffisant ?

Parce que le support se termine environ un an après la sortie (selon Scott ci-dessus). Et j'aurai peut-être à peine fini de porter Stack Overflow d'ici là.

quel est le lien avec la suppression de la prise en charge de .NET Framework par ASP.NET Core 2.x ?

Parce que les bibliothèques que je dois avoir ne sont pas là. Et je ne sais pas quand ils le seront. Je serais donc bloqué sur 1.x et j'aurais une bombe à retardement jusqu'à la fin du support. Aurai-je suffisamment de temps pour effectuer le portage de la version 1.0 vers la version 2.x (ou 3.x) avant la fin du support ? Probablement pas.

Les grandes bases de code ne peuvent pas simplement s'arrêter et porter, elles ont besoin de temps, cela doit se faire par étapes. Faire un port .NET 4.6.x sur ASP.NET Core était faisable comme étape intermédiaire. Aller au cœur en une fois est beaucoup plus difficile, prend beaucoup plus de temps et nécessite des branches plus durables et plus de douleur. Si nous ne pouvons pas le faire par étapes, honnêtement, je ne nous vois tout simplement pas quitter la ligne ASP.NET 5, désormais abandonnée. Il n'y a aucun moyen que je puisse justifier le temps, le coût et l'impact sur le développement que cela aura.

Je pense que beaucoup d'auteurs OSS sont comme moi aussi - c'est une extension de notre travail quotidien. Si nous n'utilisons pas la plate-forme ou ne l'alimentons pas, les bibliothèques sont bien pires ou ne sont pas créées. Et nous ne pouvons pas justifier le temps nécessaire pour les entretenir avec les heures d'entreprise que nous passons aujourd'hui. Et chaque bibliothèque que nous fabriquons vient d'un besoin rencontré en production. L'écosystème abandonnant les cas d'utilisation a beaucoup d'impact en aval qui n'est pas soudain, mais qui s'additionne quand même.

Actuellement, mon point de vue est le suivant : il y a une nouvelle plate-forme qui fonctionne jusqu'en juillet 2018 environ. Après cela : je ne sais rien, j'espère juste que ce dont j'ai besoin sera disponible sur netstandard / netcoreapp d'ici là. Et j'espère avoir suffisamment de temps pour effectuer le portage avant la fin du support. Je ne suis pas payé pour espérer, je suis payé pour prendre des décisions de plate-forme pour notre entreprise, et ASP.NET Core est un mauvais pari (pour nous) avec ce changement et aucune date pour une version qui fonctionnera.

Permettez-moi de proposer un résumé en une ligne : sans la prise en charge de .NET Full Framework, ASP.NET Core n'offre pas de plate-forme prise en charge pour nos cas d'utilisation pour les 2 prochaines années.

En version courte, c'est ça :

Priorité 1 : Cela doit fonctionner sur net461 , peu importe les ifdefs, perf il y a.
Priorité 2. Si vous pouvez le rendre 10 fois plus rapide sur .NET Core 2.0, alors c'est génial. C'est une excellente raison pour les gens de choisir la plate-forme et/ou de migrer quand ils le peuvent.

L'essentiel ici est que pour un support à long terme, il doit encore travailler sur le cadre complet, même s'il est plus lent là-bas.

Priorité 1 : Cela doit fonctionner sur net461

Et si .NET Core était entièrement compatible avec net461 (dans des limites raisonnables); donc tout ce qui est écrit pour net461 a fonctionné sur Core; serait-ce alors ok?

Fondamentalement, à ce stade, vous avez une plate-forme plus stable que net4x, car vous pouvez le faire côte à côte et autonome (une touche de x-plat aussi). Alors que net461 a changé toute la machine en 4.6.1, 4.6.2, 4.7, etc.

Évidemment, quelque chose ne fonctionnera jamais; comme une confiance partielle - mais cela n'a jamais fonctionné de toute façon.

Véritable question, ASP.NET Core 1.x prend actuellement en charge .NET Framework et .NET Core. Disons qu'il s'agissait de la plate-forme stable que vous avez mentionnée ci-dessus, que nous avons corrigé et pris en charge sur les deux environnements d'exécution, mais que nous n'avons pas obtenu plus de fonctionnalités. Serait-ce suffisant ?

J'aimerais voir une version LTS d'ASP.NET Core 2.0 comme Ubuntu / Redhat le fait avec leurs versions LTS qu'ils prennent en charge depuis plus de 5 ans. Cela fournirait une cible solide et compatible que le reste de l'écosystème peut avoir la confiance nécessaire pour s'engager à adopter.

Personnellement, je suis plus intéressé par un .NET Standard 2.0 stable que par toute future fonctionnalité .NET Core uniquement, car j'aimerais revenir au développement .NET où tout fonctionne à nouveau, l'outillage n'est pas cassé, le populaire . NET fournissent tous une prise en charge, les solutions de déploiement et d'hébergement environnantes sont perfectionnées et de nombreux documents, publications, vidéos et bases de connaissances sont disponibles pour un noyau ASP.NET stable sur lequel nous pouvons commencer à créer des solutions.

N'aurions-nous pas la même discussion dans un an ? Peut-être que d'ici là, l'écosystème ou les bibliothèques qui prennent en charge .NET Core seraient plus grands et auraient donc moins d'impact ? Qu'en est-il de ces bibliothèques d'entreprise qui ne seront jamais mises à jour (ou dont le code source a été perdu) ? Est-ce que ça changera dans un an ?

Dans un monde idéal, .NET v4.x et .NET Core prendraient tous deux en charge ASP.NET Core dans un avenir prévisible et ce ne sont que les nouvelles fonctionnalités .NET Core uniquement qui ne seront disponibles que dans les packages .NET Core uniquement. Mais si MS est destiné à laisser .NET 4.x derrière lui, une version ASP.NET 2.0 LTS avant que vous ne vous sépariez officiellement serait la meilleure chose à faire. Par définition, personne ne dépend de nouvelles fonctionnalités qui n'existent pas encore, donc personne ne sera obligé de mettre à niveau vers une v3.0 .NET Core uniquement.

Avec la liberté de n'avoir à prendre en charge qu'une seule plate-forme, vous pourriez potentiellement fournir de nouvelles fonctionnalités qui inciteraient les développeurs à adopter la prochaine version la plus récente et la plus performante avec un nouveau flux continu de fonctionnalités, personnellement, je suis satisfait de la fonctionnalité ASP.NET a maintenant et ainsi de suite Je suis plus intéressé par une version stable où tout est peaufiné afin que je puisse redevenir productif et me concentrer sur le développement de solutions dessus au lieu de poursuivre une plate-forme toujours en mouvement.

Tout d'abord, merci @davidfowl d'avoir sauté dans le fil et d'avoir posé des questions, etc. Lorsqu'il y a une communauté passionnée qui pose des tas de questions, il est facile de ne pas intervenir et d'éviter d'être "une cible". Alors merci de vous être impliqué, de manière constructive. /me vous salue.

Je vois deux points/fils principaux qui ressortent de cette conversation :

1. Demande de prise en charge du bureau .NET dans vnext. (c'est 99% des réponses ici)
2. Manque de consultation de la communauté sur une décision aussi importante. (les 2 ou 3 réponses ici).

TL ; DR ;

• Pouvons-nous s'il vous plaît être plus ouverts avec de grands changements importants vnext.
• Allouez du temps pour certains RFC de la communauté à propos de ces changements vnext.

@mythz l'a bien dit dans sa phrase d'ouverture de son (à ce stade), ~ le plus récent ~ 2e commentaire le plus récent :

Je trouve toute cette situation un peu décourageante avec la rapidité et la facilité avec lesquelles une décision importante comme celle-ci qui affecte l'avenir de .NET peut se produire sans aucune transparence, à la dernière minute, encore une fois.

C'est ce qui m'a vraiment frappé personnellement et j'aimerais avoir des réponses/commentaires officiels de la part des personnes appropriées chez MS qui passent ces appels svp. "Nous" sommes dans cette communauté depuis très longtemps - des visages familiers, des noms familiers et c'est assez juste de le dire - tous poursuivant les mêmes objectifs positifs. J'irais même jusqu'à dire "nous" sommes une assez grande famille élargie, avec des verrues et tout.

J'ai donc l'impression qu'avec la nouvelle direction que MS a prise (OSS-all-the-things, etc.) et avec quelques méga-uber-.NET-threads récents au cours des 12/18 derniers mois (lire : apprendre de ces expériences de discussion communautaire ) ... que "nous" sommes tous dans le même bateau et que certaines de ces Really-Big-Things ™️ seraient discutées ouvertement, bien à l'avance.

Alors - pouvons-nous, s'il vous plaît, discuter de certaines de ces grandes décisions en public, avant la main ? Obtenir une consultation et une discussion communautaires positives ?

Remarque : J'accepte que ce ou ces projets ne soient pas une démocratie et que les _décisions_ soient prises par MS. Pas de problème. Je ne critique pas _ça_. Je parle des étapes avant cela. De plus, je ne demande pas que _tout_ soit mis en place pour RFC, etc. Juste l'élément de ticket majeur impair - comme ce que ce fil a commencé.

Mais si MS est destiné à laisser .NET 4.x derrière lui, une version ASP.NET 2.0 LTS avant que vous ne vous sépariez officiellement serait la meilleure chose à faire. Par définition, personne ne dépend de nouvelles fonctionnalités qui n'existent pas encore, donc personne ne sera obligé de mettre à niveau vers une v3.0 .NET Core uniquement.

Je ne comprends pas. Personne ne dépend des fonctionnalités d'ASP.NET 2.0, car elles n'existent pas dans une version. Alors, ASP.NET Core 1.x n'est-il pas cette version ? Il fonctionne sur un framework complet, core 1.0 et core 2.0 et peut servir de tremplin vers ASP.NET Core 2.x ?

@onovotny

Tout le monde veut toujours de nouvelles fonctionnalités, la possibilité de nouvelles fonctionnalités, ou au moins savoir qu'ils auront la possibilité d'obtenir plus de goodies plus tard. Lorsque vous fermez une plate-forme et que vous la mettez en mode "stable"/"maintenance, les gens voient qu'on n'y prête plus attention.

Oui, mais il est vraiment difficile de garantir le même niveau de qualité lorsque .NET Framework est la grande écurie supportée liée au composant OS. Comme @terrajobst l' a dit, certaines choses seront certainement portées à un moment donné, mais d'autres devront être résolues. Le fait est qu'ASP.NET Core fonctionne mieux sur .NET Core car nous avons la possibilité de faire tourner l'intégralité de la pile en une seule fois. Jusqu'à présent, il existe de grandes différences de performances entre les 2 runtimes et nous n'avons pas encore pris de dépendances sur les nouvelles API en raison de la prise en charge de .NET Framework. Au fur et à mesure que nous avançons, nous ajouterons de nouvelles API qui peuvent ou non apparaître sur .NET Framework à un moment donné et nous ne voulons pas évoluer au rythme du runtime le plus stable et le plus lent (.NET Framework).

@NickCraver

Parce que le support se termine environ un an après la sortie (selon Scott ci-dessus). Et j'aurai peut-être à peine fini de porter Stack Overflow d'ici là.

Je ne suis pas sûr que ce soit tout à fait exact. Lorsque 2.0 sera disponible, 1.1 sera toujours pris en charge. Alors, quel est ce "support" dont vous parlez ? Voulez-vous dire une assistance payante ou voulez-vous dire que nous résoudrons les problèmes lorsqu'ils surgiront ?

Parce que les bibliothèques que je dois avoir ne sont pas là. Et je ne sais pas quand ils le seront. Je serais donc bloqué sur 1.x et j'aurais une bombe à retardement jusqu'à la fin du support. Aurai-je suffisamment de temps pour effectuer le portage de la version 1.0 vers la version 2.x (ou 3.x) avant la fin du support ? Probablement pas.

Comme je l'ai dit, ces bibliothèques s'allumeront quelle que soit la version de .NET Core. Je pense que ce que vous dites, c'est que vous voulez utiliser la dernière version d'ASP.NET Core (quelle qu'elle soit) et que vous voulez qu'elle soit prise en charge sur .NET Framework jusqu'à ce qu'il y ait suffisamment de bibliothèques sur .NET Core pour que le port est facile pour votre scénario spécifique.

Les grandes bases de code ne peuvent pas simplement s'arrêter et porter, elles ont besoin de temps, cela doit se faire par étapes. Faire un port .NET 4.6.x sur ASP.NET Core était faisable comme étape intermédiaire. Aller au cœur en une fois est beaucoup plus difficile, prend beaucoup plus de temps et nécessite des branches plus durables et plus de douleur. Si nous ne pouvons pas le faire par étapes, honnêtement, je ne nous vois tout simplement pas quitter la ligne ASP.NET 5, désormais abandonnée. Il n'y a aucun moyen que je puisse justifier le temps, le coût et l'impact sur le développement que cela aura.

Comment les versions d'accélération d'ASP.NET Core affectent-elles cela ? Si nous abandonnions la prise en charge de .NET Framework dans la version 3.0 (comme les gens semblent le faire dans ce fil), ne seriez-vous pas dans la même impasse malgré tout ? Votre application ASP.NET Core 2.0 serait portée en cours d'exécution sur le framework pendant un an et lorsque la version 3.0 sortira, vous ne pourrez pas effectuer la mise à niveau. Vous pourrez quand même le faire avec ASP.NET Core 1.1.x qui s'exécute sur .NET Framework et est pris en charge même lorsque ASP.NET Core 2.0 est sorti.

Actuellement, mon point de vue est le suivant : il existe une nouvelle plate-forme qui fonctionne jusqu'en juillet 2018 environ. Après cela : je ne sais rien, j'espère juste que ce dont j'ai besoin sera disponible sur netstandard/netcoreapp d'ici là. Et j'espère avoir suffisamment de temps pour effectuer le portage avant la fin du support. Je ne suis pas payé pour espérer, je suis payé pour prendre des décisions de plate-forme pour notre entreprise, et ASP.NET Core est un mauvais pari (pour nous) avec ce changement et aucune date pour une version qui fonctionnera.

Alors une année de plus, c'est assez de temps pour tout le monde ? Ce n'est pas le sentiment que j'ai de ce fil.

Priorité 1 : Cela doit fonctionner sur net461, peu importe les ifdefs, perf il y a.
Priorité 2. Si vous pouvez le rendre 10 fois plus rapide sur .NET Core 2.0, alors c'est génial. C'est une excellente raison pour les gens de choisir la plate-forme et/ou de migrer quand ils le peuvent.

L'essentiel ici est que pour un support à long terme, il doit encore travailler sur le cadre complet, même s'il est plus lent là-bas.

La seule raison pour laquelle .NET Framework fonctionne aussi bien qu'aujourd'hui est que nous avions l'intention de le prendre en charge. Ce n'est pas gratuit, ce n'est pas "juste plus rapide sur le cœur", nous avons dû intentionnellement concevoir le système pour qu'il soit possible de le faire fonctionner sur .NET Framework. Même si vous ne le voyez pas encore, l'écart de fonctionnalités augmentera entre les 2 une fois que nous aurons décidé (et nous avons décidé) de prendre des dépendances sur des API qui n'existent pas encore dans .NET Framework. Nous pouvons faire ce que dit @PinpointTownes et commencer à jeter NotSupportedException lorsque ces lacunes de fonctionnalités apparaissent, mais IMO c'est une très mauvaise expérience.

Nous avons consacré un budget de développement important au portage de notre application ASP.net MVC5 sur le framework complet de base ASP.net pour qu'il fonctionne bien avec Azure Service Fabric. L'ensemble du projet a duré plusieurs mois au cours desquels plusieurs semaines ont été consacrées au portage de notre application Web (et franchement, à la lutte avec l'outillage maladroit de VS2015).

La seule raison qui a fonctionné était que le cadre complet était pris en charge, puisque nous exécutons actuellement SignalR sur le noyau ASP.net (au découragement @davidfowl ). Autant que je sache, SignalR n'est toujours pas pris en charge sur Asp.net Core ?

Ensuite, nous avons passé environ une semaine à migrer vers le nouvel outil VS2017. Amende.

_Notez que jusqu'à présent, il n'y a aucune amélioration du produit, il s'agit simplement d'ajuster la forme du code pour s'adapter aux exigences de la plate-forme et des outils de Microsoft._

Maintenant, vous me dites que d'ici 12 mois, je devrai effectuer plus d'efforts de développement sans aucune garantie que je serai même capable de le faire, en fonction d'un tas de gestes de la main et je devrais pouvoir le faire ? Non merci.

Tout d'abord, obtenez tout ce que Microsoft utilise aujourd'hui dans le cadre complet du noyau ASP.net en travaillant uniquement sur le noyau ASP.net. Deuxièmement, découvrez ce qui (le cas échéant) empêcherait l'écosystème d'adopter le noyau ASP.net comme vous le souhaitez. Ensuite, et alors seulement, supprimez le support de Netfx, comme cela est en cours de discussion.

Nous pouvons faire ce que dit @PinpointTownes et commencer à lancer NotSupportedException lorsque ces lacunes de fonctionnalités apparaissent, mais IMO c'est une très mauvaise expérience.

Ce n'est pas exactement ce que j'ai dit : lors de la compilation croisée, ifdefs devrait certainement être l'option préférée pour exclure les API indisponibles sur une plate-forme spécifique, mais si pour une raison quelconque vous DEVEZ absolument avoir cette signature d'API dans le public contrat, alors vous pouvez aller avec NotSupportedException .

Je ne comprends pas. Personne ne dépend des fonctionnalités d'ASP.NET 2.0 pour le moment non plus

Je m'attends à ce que la plupart des développeurs attendent un .NET Standard 2.0 stable et hautement compatible que leurs dépendances prennent en charge avant de s'engager à migrer vers ASP.NET Core. Ils ne voudront pas adopter .NET Core 1.1 maintenant, sachant qu'il est en fin de vie et que MS n'a pas l'habitude de fournir un support à long terme pour les anciennes versions de DNX/.NET Core. S'il existait une version LTS stable hautement compatible que le reste de l'écosystème peut adopter en toute sécurité, les entreprises devraient disposer de tout ce dont elles ont besoin pour exécuter leurs systèmes dessus et elles ne se sentiront pas obligées de passer à .NET Core vNext car elles auront tout ce dont elles ont besoin. besoin sur v2.0 et le moment venu, il sera beaucoup plus facile de planifier leur migration d'ASP.NET Core 2.0/.NET v4.6 vers une future version .NET Core uniquement.

@mythz

Personnellement, je suis plus intéressé par un .NET Standard 2.0 stable que par toute future fonctionnalité .NET Core uniquement, car j'aimerais revenir au développement .NET où tout fonctionne à nouveau, l'outillage n'est pas cassé, le populaire . NET fournissent tous une prise en charge, les solutions de déploiement et d'hébergement environnantes sont perfectionnées et de nombreux documents, publications, vidéos et bases de connaissances sont disponibles pour un noyau ASP.NET stable sur lequel nous pouvons commencer à créer des solutions.

D'accord avec tout là-bas mais je ne vois pas comment cette décision affecte tout ce que vous avez dit. Je veux toutes ces mêmes choses 👍 .

Avec la liberté de n'avoir à prendre en charge qu'une seule plate-forme, vous pourriez potentiellement fournir de nouvelles fonctionnalités qui inciteraient les développeurs à adopter la prochaine version la plus récente et la plus performante avec un nouveau flux continu de fonctionnalités, personnellement, je suis satisfait de la fonctionnalité ASP.NET a maintenant et ainsi de suite Je suis plus intéressé par une version stable où tout est peaufiné afin que je puisse redevenir productif et me concentrer sur le développement de solutions dessus au lieu de poursuivre une plate-forme toujours en mouvement.

D'accord, n'est-ce pas ASP.NET Core 1.x ? Si le support était étendu sur 1.x, cela ne suffirait-il pas ? Nous pourrions simplement nous assurer que ASP.NET Core 1. qui est netstandard 1.x s'exécute sur .NET Core 2.0 (ce qu'il fait déjà) et le prendre en charge pendant environ un an.

Ce n'est pas exactement ce que j'ai dit : lors de la compilation croisée, ifdefs devrait certainement être l'option préférée pour exclure les API indisponibles sur une plate-forme spécifique, mais si pour une raison quelconque vous avez besoin d'avoir cette signature API dans le contrat public, alors vous pouvez aller avec NotSupportedException.

Je ne parle même pas d'exposer l'API publique. Je parle des API que nous devons appeler et qui n'existeront pas dans netstandard. #ifdefs n'aide pas ici. Nous lancerions simplement à mesure que les écarts augmenteraient.

@davidfowl Questions - réponses totalement valables :

Voulez-vous dire une assistance payante ou voulez-vous dire que nous résoudrons les problèmes lorsqu'ils surgiront ?

Correctifs actifs pour les problèmes - la version 1.x recevra-t-elle des correctifs pour toutes les choses que nous cassons, ou nous demandera-t-on de mettre à jour pour un correctif dans certains cas ? (Remarque : c'est une mise à niveau que nous ne pouvons pas faire tant que nos bibliothèques comme DirectoryServices ne sont pas là... et même si nous le pouvons , c'est loin d'être gratuit ou même bon marché, c'est probablement des mois au minimum). On est gros, on est rapide, on trouvera des cassures dans le cadre. Nous avons pour chaque version majeure et mineure pendant des années. Le soutien est essentiel pour nous.

Je pense que ce que vous dites, c'est que vous voulez utiliser la dernière version d'ASP.NET Core

Non, je veux une version qui fonctionne et une voie à suivre. Avec 1.x, nous n'avons que la première moitié. Jusqu'à ce numéro, la seconde était en quelque sorte assumée.

Comment les versions d'accélération d'ASP.NET Core affectent-elles cela ?

Parce que si vous abandonnez le support pour le framework complet, nous sommes obligés de faire un changement majeur pour rester dans le support.

Si nous abandonnions la prise en charge de .NET Framework dans la version 3.0 (comme les gens semblent le faire dans ce fil), ne seriez-vous pas dans la même impasse malgré tout ?

Peut-être? Le point est d'avoir la parité dans les cas d'utilisation avant de faire le plongeon. C'est ma carrière, je ne peux pas dire à notre entreprise de sauter quand l'autre côté ne nous soutient pas. Ce serait juste irresponsable de ma part. Si nos cas d'utilisation étaient pris en charge dans la période 2.x, la voie à suivre est claire et il est beaucoup plus sûr de faire des paris sur ASP.NET Core.

Alors une année de plus, c'est assez de temps pour tout le monde ?

La durée absolue n'a pas vraiment d'importance - elle doit être compatible avec les cas d'utilisation + temps (IMO). Si nos cas d'utilisation ont fonctionné aujourd'hui (par exemple AD auth), alors 2 ans suffisent, oui. Mais ce n'est pas le cas actuellement, donc convenir qu'un moment arbitraire à partir de maintenant est acceptable est, au mieux, prématuré.

Ce n'est pas gratuit, ce n'est pas "juste plus rapide sur le cœur", nous avons dû intentionnellement concevoir le système pour qu'il soit possible de le faire fonctionner sur .NET Framework. Même si vous ne le voyez pas encore, l'écart de fonctionnalités augmentera entre les 2 une fois que nous aurons décidé (et nous avons décidé) de prendre des dépendances sur des API qui n'existent pas encore dans .NET Framework.

Alors pas d'offense, mais pourquoi ne pas simplement le dire et clore le sujet ? Cette déclaration semble comme il n'y a plus rien à discuter, et notre temps est mieux dépensé ailleurs. Si ce n'est pas le cas, merci de préciser ?

Le principal problème est que nous ne pouvons pas porter nos charges de travail vers netstandard aujourd'hui ou, comme proposé actuellement, au lancement. Si ce que nous avons déjà ne fonctionne pas, pourquoi nous soucierions-nous des nouvelles fonctionnalités ? L'équipe n'arrête pas de parler de performance (et c'est génial, vraiment), mais quelque chose que je ne peux pas utiliser pour courir vite n'a vraiment pas beaucoup d'importance.

En tant que responsable architecture/plateforme, je dois décider des paris que nous faisons. Actuellement, c'est un mauvais pari. Lorsque la version 1 vous prend en charge mais que la version 2 ne le fait pas, mais espérons-le un jour , c'est un très mauvais pari à faire avec le temps et l'argent des autres. Au moins pour nous, nous avons choisi .NET pour les fonctionnalités, l'écosystème et le support. Actuellement, dans le nouveau mot, nous sommes passés de tous les 3 à 1. L'écosystème n'est pas encore là (surface API, libs), et le support est beaucoup plus court que ce à quoi nous sommes habitués, sans aucun chemin de mise à niveau garanti et un temps inconnu pour le faire.

@jahmai

La seule raison qui a fonctionné était que le cadre complet était pris en charge, puisque nous exécutons actuellement SignalR sur le noyau ASP.net (au découragement @davidfowl ). Autant que je sache, SignalR n'est toujours pas pris en charge sur Asp.net Core ?

Même le SignalR 2 n'est pas pris en charge sur ASP.NET Core (bien que les gens l'aient piraté pour le faire fonctionner). SignalR est toujours en cours de développement et ne sortira même pas avec ASP.NET Core 2.0, il viendra plus tard.

Maintenant, vous me dites que d'ici 12 mois, je devrai effectuer plus d'efforts de développement sans aucune garantie que je serai même capable de le faire, en fonction d'un tas de gestes de la main et je devrais pouvoir le faire ? Non merci.

Y a-t-il des fonctionnalités dont vous avez besoin dans ASP.NET Core 2.0 ? Ou spéculez-vous simplement sur le fait que vous devrez éventuellement passer au prochain ASP.NET Core et qu'à ce stade, les choses ne fonctionneront pas sur .NET Framework?

Tout d'abord, obtenez tout ce que Microsoft utilise aujourd'hui dans le cadre complet du noyau ASP.net en travaillant uniquement sur le noyau ASP.net. Deuxièmement, découvrez ce qui (le cas échéant) empêcherait l'écosystème d'adopter le noyau ASP.net comme vous le souhaitez. Ensuite, et alors seulement, supprimez le support de Netfx, comme cela est en cours de discussion.

Dans le cadre de netstandard 2.0, beaucoup de travail a été fait pour identifier les API importantes à ramener afin que les bibliothèques qui ciblaient .NET Framework soient pour la plupart compatibles avec le binaire. Bien sûr, il y a des domaines qui ne fonctionneront tout simplement pas comme WCF, WPF, etc. mais cela aidera car nous avons fait des recherches et ~ 60% des bibliothèques sont compatibles API avec netstandard 2.0 (corrigez-moi si je me trompe sur ce nombre @terrajobst) et peut fonctionner uniquement sur .NET Core 2.0.

D'accord, n'est-ce pas ASP.NET Core 1.x ? Si le support était étendu sur 1.x, cela ne suffirait-il pas ?

Je m'attendais à ce que .NET Standard 2.0 soit la plate-forme stable qui relie la compatibilité avec .NET 4.x, il est donc plus logique que le support LTS soit autour de cela. Personne ne s'attend à ce que la version 1.1/.NET v4.x soit en fin de vie à mi-parcours, il serait donc respectueux d'annoncer LTS sur la dernière version lors de sa sortie, sans tirer le support de .NET 4.x avant sa sortie, non- on fait LTS en rétrospective d'anciennes versions comme celle-là.

Je sais que nous maintenons nos packages .NET Core dans des packages *.Core distincts afin que nous puissions rester sur une cadence de publication distincte qui suit la dernière version de .NET Core au moment où nous fusionnons dans les packages NuGet principaux, cela signifie nous nous engageons sur une version stable que nous allons officiellement prendre en charge, nous devons donc être très confiants que nous avons une version que nous pouvons prendre en charge dans un avenir prévisible, ce que j'attendais de .NET Standard 2.0, pas de l'actuel .NET Standard Mélange 1.1/1.3/1.6. Je me souviens qu'il y avait aussi un moment où il allait y avoir une version 1.7/8 stop gap qui allait être incompatible avec 2.0 brisant les attentes de versioning .NET Standard qui ne sont pas des signaux d'une plate-forme stable.

Je m'attendais avec impatience à ce que .NET Standard 2.0 soit destiné à fournir la surface hautement compatible très recherchée et la stabilité indispensable.

Même le SignalR 2 n'est pas pris en charge sur ASP.NET Core (bien que les gens l'aient piraté pour le faire fonctionner). SignalR est toujours en cours de développement et ne sortira même pas avec ASP.NET Core 2.0, il viendra plus tard.

Je ne sais pas comment vous entendiez cette déclaration, mais je pense que cela ne fait que renforcer mes préoccupations.

Y a-t-il des fonctionnalités dont vous avez besoin dans ASP.NET Core 2.0 ? Ou spéculez-vous simplement sur le fait que vous devrez éventuellement passer au prochain ASP.NET Core et qu'à ce stade, les choses ne fonctionneront pas sur .NET Framework?

Je veux passer à netstandard2 à un moment donné pour des raisons. Je devrai déplacer mon application Web vers asp.net core 2 pour cela, n'est-ce pas?

Dans le cadre de netstandard 2.0, beaucoup de travail a été fait pour identifier les API importantes à ramener afin que les bibliothèques qui ciblaient .NET Framework soient pour la plupart compatibles avec le binaire. <...>

Bien sûr, et j'aime ce qui se fait avec netstandard, mais s'il manquait quelque chose dans netstandard, vous pouvez contourner le problème car vous pouvez cibler un framework complet dans les applications qui en ont besoin. Nous avons maintenant une poignée de bibliothèques pures netstandard 1.3 (notre source) partagées entre : Xamarin.iOS, Xamarin.Android, net46, Asp.net core 1.1 - parce que nous pouvons compléter les fonctionnalités manquantes dans netstandard avec des bibliothèques de ciblage de framework spécifiques, y compris des éléments net46 dans notre application Web principale asp.net.

La _ seule _ raison pour laquelle nous avons ces bibliothèques netstandard est que nous avions besoin de porter notre énorme application Web (comme je l'ai mentionné précédemment). Je voudrais _aimer_ ne pas avoir à étendre notre base de code spécifique à la plate-forme pour d'autres plates-formes, et à la place continuer à remonter la chaîne netstandard. Je ne veux vraiment pas être bloqué sur netstandard 1.3 car il n'y a pas de chemin pour passer à asp.net core 2.

Correctifs actifs pour les problèmes - la version 1.x recevra-t-elle des correctifs pour toutes les choses que nous cassons, ou nous demandera-t-on de mettre à jour pour un correctif dans certains cas ? (Remarque : c'est une mise à niveau que nous ne pouvons pas faire tant que nos bibliothèques comme DirectoryServices ne sont pas là... et même si nous le pouvons, c'est loin d'être gratuit ou même bon marché, c'est probablement des mois au minimum). On est gros, on est rapide, on trouvera des cassures dans le cadre. Nous avons pour chaque version majeure et mineure pendant des années. Le soutien est essentiel pour nous.

Je ne pense pas qu'il y ait un problème d'assistance. En fait, je ne pense pas que ce serait un gros problème et si cela rendait les gens plus confiants pour prendre un pari, alors cela vaut peut-être la peine d'étendre le support pour 1.x à une période plus longue.

Non, je veux une version qui fonctionne et une voie à suivre. Avec 1.x, nous n'avons que la première moitié. Jusqu'à ce numéro, la seconde était en quelque sorte assumée.

Cela signifie simplement que vous devez rester sur 1.x jusqu'à ce que toutes vos dépendances soient portées, non ?

@NickCraver Toutes vos plaintes parlent de choses manquantes sur .NET Core plutôt que sur ASP.NET Core. Dans .NET Core 1.x et ASP.NET Core 1.x, ces 2 entités sont livrées ensemble mais sont complètement découplées. Je n'ai pas entendu une seule raison de vouloir utiliser ASP.NET Core 2.0 spécifiquement autre que des préoccupations valables concernant la v1 prenant en charge quelque chose et la v2 ne le prenant pas en charge. Je pense que nous aurions exactement la même discussion dans un an s'il y avait une autre raison pour laquelle vous ne pouviez pas porter uniquement sur .NET Core (peut-être que lors du développement d'ASP.NET Core sur un framework complet, vous avez pris de nouvelles dépendances qui ne sera jamais porté comme exemple).

Alors pas d'offense, mais pourquoi ne pas simplement le dire et clore le sujet ? Cette déclaration semble comme il n'y a plus rien à discuter, et notre temps est mieux dépensé ailleurs. Si ce n'est pas le cas, merci de préciser ?

Je suis ici pour répondre et répondre parce que j'essaie de comprendre pourquoi nous devons prendre en charge .NET Framework si oui, pendant combien de temps. Je reçois toujours une ambiance mitigée sur ce fil à propos de ces délais. De plus, je peux comprendre une crainte générale d'être "relégué à ASP.NET Core 1.x", mais rien de concret en termes de fonctionnalités spécifiques nécessaires dans 2.x.

L'une des principales choses que j'aime dans le couplage de .NET Core et ASP.NET Core est qu'il résout une partie de la folie des versions et des noms. Beaucoup de gens ne savent même pas qu'ASP.NET Core fonctionne sur .NET Framework (il confond même les nouveaux arrivants dans la pile). Cela dit, nous avons beaucoup de clients avec beaucoup de besoins différents et nous écoutons leurs commentaires.

@mythz

Je m'attendais avec impatience à ce que .NET Standard 2.0 soit destiné à fournir la surface hautement compatible très recherchée et la stabilité indispensable.

Bien sûr, mais comme je l'ai dit, ASP.NET Core, .NET Core et .NET Standard dans 1.x sont complètement découplés. Vous pouvez utiliser n'importe quelle bibliothèque .NET Standard sur n'importe quelle version de .NET Core qui la prend en charge. Donc, si .NET Core 2.0 est un nouveau LTS, nous pourrions toujours déclarer que ASP.NET Core 1.x est pris en charge dessus.

@jahmai

Je veux passer à netstandard2 à un moment donné pour des raisons. Je devrai déplacer mon application Web vers asp.net core 2 pour cela, n'est-ce pas?

Non, ce n'est pas vrai. Vous pouvez passer à netstandard 2 quand vous le souhaitez sans déplacer votre application Web vers ASP.NET Core 2.0.

La seule raison pour laquelle nous avons ces bibliothèques netstandard est que nous avions besoin de porter notre énorme application Web (comme je l'ai mentionné précédemment). J'aimerais ne pas avoir à étendre notre base de code spécifique à la plate-forme pour d'autres plates-formes, et continuer à remonter la chaîne netstandard. Je ne veux vraiment pas être bloqué sur netstandard 1.3 car il n'y a pas de chemin pour passer à asp.net core 2.

Vous n'avez pas besoin d'être bloqué sur netstandard 1.3. Les 2 choses ne sont pas liées.

Lorsque la version 1 vous prend en charge mais que la version 2 ne le fait pas mais _espérons-le un jour_, c'est un très mauvais pari....

Je pense que c'est le nœud du problème. Nous avons reçu des commentaires selon lesquels _certaines_ des lacunes ( DirectoryService , et. al.) sont connues et seront traitées. Nous avons besoin de quelque chose de plus concret que cela.

Je suis d'accord avec ASP.NET Core ciblant .NET Core et avec nous manquant le bateau 2.0 si la feuille de route est claire sur le moment où nous pouvons nous attendre à ce que ces lacunes (et quelles lacunes) soient comblées (encore une fois, en supposant qu'il y ait suffisamment de temps pour le port avant 1.X devient non pris en charge).

Dans l'état actuel des choses, le problème sur lequel nous sommes bloqués pour WCF stagne depuis mai 2015 et pourrait ne jamais être résolu. Nous laissant effectivement bloqués.

@davidfowl

Non, ce n'est pas vrai. Vous pouvez passer à netstandard 2 quand vous le souhaitez sans déplacer votre application Web vers ASP.NET Core 2.0.

Excellent. Dans ce cas, tant que Microsoft s'assure que 1.x est pris en charge (toutes sortes de corrections de bogues et de support opérationnel) jusqu'à ce qu'il offre aux clients un chemin de migration 2.x approprié (par exemple SignalR), alors je suis à l'aise d'attendre mon heure jusqu'à ce que nous besoin du noyau asp.net 2.

Cela signifie simplement que vous devez rester sur 1.x jusqu'à ce que toutes vos dépendances soient portées, non ?

Correct, mais cela doit être un délai connu. Nous n'avons pas de dates, la seule chose qu'on nous a dit jusqu'à présent est "pas en 2.0"... donc ce n'est pas bon. Par exemple, System.DirectoryServices a été demandé depuis la mi-2015, et est toujours manquant mais est souvent répété comme le plus recherché par les utilisateurs (suivi de System.Drawing ). Dire que nous apportons .NET Standard 2.0 à environ 60 % de parité API, mais manquer les bits que les utilisateurs ont demandés envoie très certainement des signaux mitigés sur ce qui est important.

Toutes vos plaintes parlent de choses manquantes sur .NET Core plutôt que sur ASP.NET Core.

C'est faux. J'ai besoin des bits dont nous avons besoin pour exécuter (par exemple AD auth) sur une plate-forme prise en charge. Ce qui manque, c'est le soutien de ce dernier. La prise en charge de 1.x est certainement ma principale préoccupation. Nous n'avons pas de voie à suivre prise en charge ni de calendrier pour savoir quand nous pouvons en attendre une.

Je pense que nous aurions exactement la même discussion dans un an

Je ne pense pas que ce soit le cas. Le problème est que nous n'avons pas pu effectuer de portage aujourd'hui . Les API ne sont pas là. Tant qu'il n'y a pas un seul moment dans le temps que nous étions même capables de porter, les discussions sur l'avenir sont un peu discutables. Je m'attendrais à ce que la prise en charge complète du framework .NET dans ASP.NET Core soit obsolète une fois qu'il y aurait eu parité et que la plupart des utilisateurs pourraient passer. Et je m'attendrais à ce que cette version ait un long délai de support pour que les gens se déplacent.

Si DirectoryServices, Drawing, etc. arrivent en 2.x, alors génial. Cette version doit prendre en charge .NET Framework et être une version LTS. Et 3.x devrait abandonner la prise en charge complète du framework.

L'une des principales choses que j'aime dans le couplage de .NET Core et ASP.NET Core est qu'il résout une partie de la folie des versions et des noms. Beaucoup de gens ne savent même pas qu'ASP.NET Core fonctionne sur .NET Framework (il confond même les nouveaux arrivants dans la pile). Cela dit, nous avons beaucoup de clients avec beaucoup de besoins différents et nous écoutons leurs commentaires.

Assez juste, mais toute la folie là-bas est secondaire à "ça marche même?". Actuellement, c'est un non ferme. ASP.NET et .NET Core/Standard/quoi que ce soit peuvent être 2 ensembles de choses à l'intérieur de Microsoft (et je comprends tout à fait cela), mais pour les développeurs, c'est toujours 1 plate-forme. Le côté ASP.NET a besoin que les API soient utiles à beaucoup, et elles n'en sont pas encore là. Cette décision réduit encore les API disponibles. L'équipe ASP.NET peut obtenir ceux qu'elle veut, mais c'est au détriment de ceux dont nous avons besoin.

@ctolkien @NickCraver

Je pense que c'est le nœud du problème. Nous avons eu des commentaires selon lesquels certaines des lacunes (DirectoryService, et. al.) sont connues et seront traitées. Nous avons besoin de quelque chose de plus concret que cela.

Correct, mais cela doit être un délai connu. Nous n'avons pas de dates, la seule chose qu'on nous a dit jusqu'à présent est "pas en 2.0"... donc ce n'est pas bon. Par exemple, System.DirectoryServices a été demandé depuis la mi-2015, et est toujours manquant mais est souvent répété comme le plus recherché par les utilisateurs (suivi par System.Drawing).

Ces lacunes sont cependant liées à .NET Core lui-même et je peux comprendre l'anxiété de ne pas savoir quand ces dépendances seront disponibles et c'est pourquoi il serait bon de nous aider à les hiérarchiser. La bonne nouvelle est que netstandard 2.0 et netcoreapp2.0 ont travaillé en groupe pour faciliter le portage d'autres bibliothèques. Je pense qu'après avoir livré la version 2.0, il sera beaucoup plus facile de faire apparaître d'autres dépendances en transférant des pans de code au-dessus de notre base très compatible.

CSOM fonctionnera-t-il dans netcore 2 ? Ce serait un énorme blocage pour nous et un domaine sur lequel je n'ai rien entendu.

@davidfowl J'espère sincèrement que c'est aussi le cas, mais je ne parie pas notre entreprise là-dessus. Abandonner le support avant que cela ne se produise, et pas après, je suis fortement en désaccord avec. Je pense que cela se produit dans la période 3.x après la mise en place de ces API critiques pour de nombreux consommateurs est tout à fait valable. Le faire avant qu'ils ne soient prêts ne fait qu'arrêter notre adoption.

J'étais sur le point d'adopter 1.0 en supposant que 2.x (ou tout ce qui est activement développé/corrigé) prendrait en charge le framework complet jusqu'à ce que ces API critiques soient prêtes (je suis sérieux - vous savez combien de travail j'ai déjà mis dans les bibliothèques ). Mais à ce stade, je ne peux pas faire ça chez Stack... c'était une mauvaise hypothèse. Je ne peux pas en toute bonne conscience dire à nos équipes d'utiliser .NET Core alors que l'avenir de n'importe quel port est si incertain. J'aimerais vraiment pouvoir le faire, mais ça ne vaut pas le risque et la douleur pour le moment.

@NickCraver

Je m'attendrais à ce que la prise en charge complète du framework .NET dans ASP.NET Core soit obsolète une fois qu'il y aurait eu parité et que la plupart des utilisateurs pourraient passer. Et je m'attendrais à ce que cette version ait un long délai de support pour que les gens se déplacent.

Quelle est la mesure de "la plupart des utilisateurs" ici ? Quelle est la liste des dépendances qui doivent être couvertes jusqu'à ce que nous puissions supprimer le support ? Votre liste est différente des autres utilisateurs de cette liste. Je m'attends également à ce que certaines personnes disent pour toujours ou jusqu'à ce que .NET Core atteigne la parité .NET Framework (ce qui est tout simplement irréaliste). Je vais toujours poser qu'ASP.NET Core 1.x est assez bon à cette fin et nous devrions envisager d'étendre la prise en charge jusqu'à ce moment-là.

C'est faux. J'ai besoin des bits dont nous avons besoin pour exécuter (par exemple AD auth) sur une plate-forme prise en charge. Ce qui manque, c'est le soutien de ce dernier. La prise en charge de 1.x est certainement ma principale préoccupation. Nous n'avons pas de voie à suivre prise en charge ni de calendrier pour savoir quand nous pouvons en attendre une.

Quel composant ASP.NET manque pour ce scénario ? Lorsque vous dites 1.x vs 2.x, il serait utile de mentionner ASP.NET Core vs .NET Core.

Si DirectoryServices, Drawing, etc. arrivent en 2.x, alors génial. Cette version doit prendre en charge .NET Framework et être une version LTS. Et 3.x devrait abandonner la prise en charge complète du framework.

Je l'ai déjà mentionné, de quelles fonctionnalités ASP.NET Core avez-vous besoin pour qu'ASP.NET Core 1.x ne soit pas suffisant pour cela ?

ASP.NET et .NET Core/Standard/tout ce qui peut être 2 ensembles de choses à l'intérieur de Microsoft (et je comprends tout à fait), mais pour les développeurs, c'est toujours 1 plate-forme

D'accord, mais nous devons éclaircir le FUD sur cette discussion afin que nous puissions évaluer correctement l'impact. ASP.NET Core 1.x cible .NET Standard 1.x (1.0 - 1.6) et .NET Framework 4.5.1. Cela signifie qu'il peut s'exécuter sur n'importe quelle plate-forme prenant en charge ces versions de netstandard et .NET Framework. Cela signifie que ASP.NET Core 1.x s'exécutera sur .NET Core 2.0.

@smbecker

CSOM fonctionnera-t-il dans netcore 2 ? Ce serait un énorme blocage pour nous et un domaine sur lequel je n'ai rien entendu.

Je n'ai aucune idée de ce que c'est. Est-ce que c'est https://msdn.microsoft.com/en-us/library/ff798388.aspx ? Si c'est le cas, aucun travail n'a été fait pour le soutenir explicitement. Cela pourrait simplement fonctionner sur la base de la compatibilité .NET Framework dans .NET Core 2.0, mais je suppose qu'il ne sera jamais porté sur .NET Core (juste sur la base de mes 5 minutes de lecture), mais je peux me tromper.

Quelle est la mesure de "la plupart des utilisateurs" ici ? Quelle est la liste des dépendances qui doivent être couvertes jusqu'à ce que nous puissions supprimer le support ? Votre liste est différente des autres utilisateurs de cette liste. Je m'attends également à ce que certaines personnes disent pour toujours ou jusqu'à ce que .NET Core atteigne la parité .NET Framework (ce qui est tout simplement irréaliste). Je vais toujours poser qu'ASP.NET Core 1.x est assez bon à cette fin et nous devrions envisager d'étendre la prise en charge jusqu'à ce moment-là.

Commençons par les principales API manquantes - ce sont elles qui causent des blocages pour la plupart des gens. Pour nous, c'est DiretoryServices, qui est le numéro 1. Si ce n'est même pas là, c'est un très mauvais signe pour la communauté. Je suis d'accord que les listes sont différentes, mais si nous n'incluons même pas le numéro 1 ...

Quel composant ASP.NET manque pour ce scénario ? Lorsque vous dites 1.x vs 2.x, il serait utile de mentionner ASP.NET Core vs .NET Core.

Je l'ai déjà mentionné, de quelles fonctionnalités ASP.NET Core avez-vous besoin pour qu'ASP.NET Core 1.x ne soit pas suffisant pour cela ?

Je veux dire la prise en charge du dernier ASP.NET Core qui prend en charge Full Framework (et donc les bibliothèques dont j'ai besoin). J'espère que c'est 2.x, car nous voulons des modules, des pages de rasoir, etc. Nous avons des utilisations pour de nombreuses fonctionnalités 2.x. Mais il semble que notre seule option soit 1.x à ce stade. Nous ne pouvons pas passer d'ASP.NET 5 à ASP.NET Core et du framework complet avec toutes nos bibliothèques de travail à netcoreapp en 1 mouvement. C'est trop. C'est trop cher. C'est trop risqué. Et maintenant, nous ne savons pas si nous pouvons faire ce mouvement coûteux et risqué à l'intérieur d'une fenêtre de support. C'est une mauvaise situation - si mauvaise qu'il vaut mieux ne pas bouger (dans l'état actuel des choses). Je pense que c'est vraiment dommage.

Quel composant ASP.NET manque pour ce scénario ? Lorsque vous dites 1.x vs 2.x, il serait utile de mentionner ASP.NET Core vs .NET Core.

• À moins qu'il existe un moyen de gérer l'authentification/les requêtes AD via un package Microsoft.Authentication.* NuGet, c'est une grande chose. Je suis actuellement dans le même bateau, mais comme j'utilise .NET Core 1.1 au-dessus de .NET 462, je pourrai y parvenir. En dehors de cela, comment pourrais-je interroger des groupes AD, des métadonnées par des moyens pris en charge ? J'ai vu dans le référentiel corefx qu'il y a beaucoup de travail en cours sur System.DirectoryServices , donc j'en suis au moins content.

• System.Data.Common.DbDataAdapter / SqlClient.SqlDataAdapter . Actuellement, je ne peux y accéder que lors de l'exécution sur .NET Core en plus du .NET Framework complet. Je suppose que c'est plus une question de commodité, puisque je peux toujours utiliser le DbDataReader / SqlDataReader .

Fondamentalement, j'ai besoin de savoir qu'il y aura une garantie de CERTAINS moyens pris en charge pour gérer l'authentification AD lors de l'utilisation d'ASP.NET Core 2.x, sans avoir besoin du .NET Framework complet.

J'y ai beaucoup réfléchi aujourd'hui et je trouve que mes préoccupations sont différentes de la plupart de celles ici (non pas que ces préoccupations ne soient pas aussi importantes, sinon plus).

Je suis toujours un peu bloqué sur le cas d'utilisation de la consommation de packages ASP.NET Core sur netstandard . Jusqu'à ce problème, j'avais supposé (peut-être à tort) que netstandard était la cible de facto pour les bibliothèques. En d'autres termes, le comportement prévu pour les auteurs de bibliothèques serait de cibler netstandard moins qu'il n'y ait une raison nécessaire et impérieuse de ne pas le faire. Cela garantit non seulement la compatibilité avec Framework, mais aussi avec les autres plates-formes telles que Xamarin et UWP. Le travail sur .NET Standard 2.0 semblait soutenir cela en essayant d'unifier la surface de l'API des différents runtimes dans une cible commune sans besoin d'y penser.

Pour moi, ce changement signale quelque chose de différent. Certes, en fin de compte, ASP.NET Core n'est qu'une bibliothèque et peut-être a-t-il des "raisons nécessaires et impérieuses" de ne pas prendre en charge la surface commune netstandard . Mais c'est aussi l'une des bibliothèques .NET les plus visibles développées par Microsoft et en disant "nous voulons la dernière et la meilleure, nous allons donc arrêter de prendre en charge netstandard ", cela signale à tous les autres développeurs de bibliothèques (ou à moins pour moi) qu'ils devraient peut-être arrêter d'essayer si fort de prendre en charge netstandard et commencer à cibler le runtime Core. Pourquoi s'embêter avec tout ce truc de compatibilité alors que Microsoft ne s'en soucie même pas tant que ça ? .NET Core 4. Et c'est peut-être pour le mieux - c'est certainement différent de ce que je pensais que nous allions avec plusieurs runtimes et une surface d'API principalement unifiée.

Cette préoccupation devient encore plus profonde si l'on considère que ASP.NET Core contient de très nombreuses bibliothèques qui sont utiles directement en dehors du contexte d'ASP.NET. Il était peut-être faux de supposer que ceux-ci étaient destinés à être utilisés isolément, mais ce serait vraiment dommage de les perdre. Les auteurs de bibliothèques qui souhaitent les utiliser devront également décider de basculer leur propre ciblage vers .NET Core ou de rester sur netstandard et d'y perdre l'accès. Je soupçonne que beaucoup choisiront l'ancien support de bibliothèque, plus fragmenté, pour les plates-formes alternatives. Au moins si j'ai compris les commentaires ici, il est trop difficile de cibler différentes plates-formes pour les bibliothèques de support.

Enfin, je suis un peu (bien qu'un peu moins) préoccupé par les commentaires ici selon lesquels dès que possible, de nouvelles API seront ajoutées à Core pour rev en conjonction avec ASP.NET. En particulier, ces nouvelles API ne seront peut-être jamais intégrées dans netstandard ou .NET Framework. Je comprends certainement qu'il peut y avoir des choses passionnantes qui peuvent être faites si les problèmes d'héritage et de compatibilité sont abandonnés ou assouplis. Mais pour être franc, j'ai eu l'impression que l'équipe ASP.NET Core est souvent en train de charger. Ce n'est pas nécessairement une mauvaise chose, mais cela a également conduit à un certain nombre de décisions plus larges qu'il a fallu revenir en arrière. Je ne peux pas m'empêcher de me demander si cela, et l'évolution rapide ultérieure du runtime Core, auront pour résultat de fracturer considérablement l'ensemble des runtimes au fil du temps (et encore une fois, ce n'est pas seulement Windows/Framework qui sera laissé pour compte - il y a également Xamarin, Mono, UWP, etc.).

Tout ce fil m'a amené à réorienter ma compréhension de l'avenir de .NET autour de .NET Core au lieu de netstandard . Peut-être que je suis extrême et que cela s'atténuera dans les semaines à venir, ou peut-être que c'est même la position prévue et c'est pour le mieux - de toute façon, je suis actuellement tenté de sortir et de cibler .NET Core pour mon propre choses et se concentrer uniquement sur cela à partir de tout ce que j'ai lu ici.

@NickCraver

Je veux dire la prise en charge du dernier ASP.NET Core qui prend en charge Full Framework (et donc les bibliothèques dont j'ai besoin). J'espère que c'est 2.x, car nous voulons des modules, des pages de rasoir, etc. Nous avons des utilisations pour de nombreuses fonctionnalités 2.x.

En ce moment c'est 1.1.1 (il n'y a pas de modules dans 2.0), Razor Pages est un bon, un autre est SignalR. Ce sont les 2 choses que je vois être les plus douloureuses dans le cadre de cela.

Nous ne pouvons pas passer d'ASP.NET 5 à ASP.NET Core et du framework complet avec toutes nos bibliothèques de travail à netcoreapp en 1 mouvement. C'est trop. C'est trop cher. C'est trop risqué. Et maintenant, nous ne savons pas si nous pouvons faire ce mouvement coûteux et risqué à l'intérieur d'une fenêtre de support. C'est une mauvaise situation - si mauvaise qu'il vaut mieux ne pas bouger (dans l'état actuel des choses). Je pense que c'est vraiment dommage.

Est-ce bien? Le passage d'ASP.NET Core 1.x à 2.x ou 3.x en supposant que vos dépendances ont été portées serait trivial. Si vous envisagez de passer à ASP.NET Core en général, passer à 1.1 est une bonne première étape et vous n'économiserez aucun travail en l'évitant.

@snickler

Fondamentalement, j'ai besoin de savoir qu'il y aura une garantie de CERTAINS moyens pris en charge pour gérer l'authentification AD lors de l'utilisation d'ASP.NET Core 2.x, sans avoir besoin du .NET Framework complet.

Jusqu'à ce que System.DirectoryServices soit pris en charge sur .NET Core, y a-t-il une raison pour laquelle vous ne pouvez pas utiliser ASP.NET Core 1.x sur .NET Framework ?

Jusqu'à ce que System.DirectoryServices soit pris en charge sur .NET Core, y a-t-il une raison pour laquelle vous ne pouvez pas utiliser ASP.NET Core 1.x sur .NET Framework ?

C'est ce que je fais actuellement. J'attends simplement avec impatience dans l'espoir de ne pas avoir à me soucier du .NET Framework si je n'en ai pas besoin. Actuellement, cela me limite à ma machine Windows car l'espace de noms System.DirectoryServices.AccountManagement n'existe pas dans Mono. Dans ces mêmes considérations, y aura-t-il System.DirectoryServices.AccountManagement disponible en dehors de la contrainte de Windows ? Ce petit morceau m'oblige à passer d'une machine à l'autre tout en déboguant mon projet MVC et mon application Xamarin.iOS localement.

Si vous envisagez de passer à ASP.NET Core en général, passer à 1.1 est une bonne première étape et vous n'économiserez aucun travail en l'évitant.

Je suis totalement d'accord, si nous savions que le support était là jusqu'à ce que nous passions à une autre plate-forme qui fonctionnait . À l'heure actuelle, nous ne savons pas quand les éléments nécessaires seront disponibles dans le monde .NET Core. Par conséquent, fixer une limite de temps maintenant et ne pas savoir quand ces éléments viendront plus tard , c'est parier sur une promesse. C'est le cœur du problème. Si nous avons une version prise en charge qui se chevauche et qui permet le portage, je serais prêt et heureux d'investir. Si le support est abandonné avant que les API ne soient là, nous sautons un écart sur la foi, avec une quantité inconnue de piste.

Je continue de faire référence à DirectoryServices parce que c'est ce que je sais ne fonctionne pas sur netcoreapp2.0 aujourd'hui. Il y aura bien sûr d'autres choses que nous trouverons qui tomberont dans le même bateau. Nous avons besoin d'ASP.NET Core + framework complet + support pendant plusieurs années sur certaines plates-formes. Avec 1.x, nous n'obtenons pas beaucoup de gains, nous en obtenons en fait très peu. La performance n'est pas un argument génial puisque nous rendons déjà les pages en ~ 18 ms et c'est éclipsé par le temps de transport. 2.0 offre cependant pas mal de bons articles. Les pages de rasoir et la perspective de plugins le rendent très attrayant à porter. Au point d'être justifiable.

À l'heure actuelle, la seule version à utiliser avec le support (1.1.x avec un support plus long, c'est ce que j'attends après avoir lu ce fil) ne vaut pas la peine d'être déplacée. Il faudrait essentiellement beaucoup de temps et d'efforts pour arriver là où nous en sommes aujourd'hui. 2.x offre au moins quelques améliorations décentes et des éléments dont nous voudrions profiter. Ils permettent de justifier le coût du déménagement.

La performance n'est pas un argument génial puisque nous rendons déjà les pages en ~18ms

Sur une diatribe OT mineure, j'aimerais savoir comment vous pouvez rendre des pages en ~ 18 ms @NickCraver . C'est génial

@daveaglick

Je suis toujours un peu bloqué sur le cas d'utilisation de la consommation de packages ASP.NET Core sur netstandard. Jusqu'à ce numéro, j'avais supposé (peut-être à tort) que netstandard était la cible de facto des bibliothèques. En d'autres termes, le comportement prévu pour les auteurs de bibliothèques serait de cibler netstandard à moins qu'il n'y ait une raison nécessaire et impérieuse de ne pas le faire. Cela garantit non seulement la compatibilité avec Framework, mais aussi avec les autres plates-formes telles que Xamarin et UWP. Le travail sur .NET Standard 2.0 semblait soutenir cela en essayant d'unifier la surface de l'API des différents runtimes dans une cible commune sans besoin d'y penser.

Rien n'a changé ici. En fait, un grand nombre de nos bibliothèques que nous souhaitons exécuter sur d'autres plates-formes sont toujours netstandard. Si vous relisez certains des éléments ci-dessus :

• Microsoft.Extensions.* (journalisation, DI, configuration, fournisseurs de fichiers, etc.)
• Cadre d'entité
• Clients SignalR (ils doivent s'exécuter sur .NET Framework, Xamarin, UWP, etc.).

.NET Standard est le moyen de facto d'écrire des bibliothèques qui s'exécutent partout. Les auteurs de bibliothèques doivent viser à cibler netstandard dans la mesure du possible pour obtenir la plus large portée de plate-forme. Les auteurs de la bibliothèque doivent décider s'ils veulent avoir une portée ou non. C'est pourquoi les bibliothèques comme JSON.NET prennent en charge netstandard1.x et .NET Framework 2.0. Ils font un effort supplémentaire pour que les choses "fonctionnent simplement" comme @JamesNK l'a mentionné ci-dessus.

ASP.NET Core s'éloigne de netstandard à certains endroits est plus une déclaration que ces API ne sont pas destinées aux applications UWP et nous ne les testons certainement pas là-bas (par exemple). Il essaie également de solidifier le fait que .NET Core et ASP.NET Core sont un seul produit qui fonctionne ensemble (puisqu'il a Core dans le nom). Avec ASP.NET Core 1.x prenant en charge à la fois .NET Core et .NET Framework, ce message était un peu flou et cela sème la confusion chez beaucoup de gens (en particulier les nouveaux développeurs) et nous l'avons fait pour atténuer le problème d'écart de bibliothèque.

Cette préoccupation devient encore plus profonde si l'on considère que ASP.NET Core contient de très nombreuses bibliothèques qui sont utiles directement en dehors du contexte d'ASP.NET. Il était peut-être faux de supposer que ceux-ci étaient destinés à être utilisés isolément, mais ce serait vraiment dommage de les perdre. Les auteurs de bibliothèques qui souhaitent les utiliser devront également décider de basculer leur propre ciblage vers .NET Core ou de rester sur netstandard et d'y accéder librement. Je soupçonne que beaucoup choisiront l'ancien support de bibliothèque, plus fragmenté, pour les plates-formes alternatives. Au moins si j'ai compris les commentaires ici, il est trop difficile de cibler différentes plates-formes pour les bibliothèques de support.

Je suppose que ceux-ci sont toujours netstandard. Lesquels ne le sont pas ?

Je ne peux pas m'empêcher de me demander si cela, et l'évolution rapide ultérieure du runtime Core, auront pour résultat de fracturer considérablement l'ensemble des runtimes au fil du temps (et encore une fois, ce n'est pas seulement Windows/Framework qui sera laissé pour compte - il y a également Xamarin, Mono, UWP, etc.).

Je pense que netstandard va évoluer, mais .NET Framework sera toujours le dernier à obtenir de nouvelles API (Xamarin et Mono sont assez rapides pour ajouter des choses).

@snickler

C'est ce que je fais actuellement. J'attends simplement avec impatience dans l'espoir de ne pas avoir à me soucier du .NET Framework si je n'en ai pas besoin. Actuellement, cela me limite à ma machine Windows car l'espace de noms System.DirectoryServices.AccountManagement n'existe pas dans Mono. Dans ces mêmes considérations, y aura-t-il System.DirectoryServices.AccountManagement disponible en dehors de la contrainte de Windows ? Ce petit morceau m'oblige à passer d'une machine à l'autre tout en déboguant mon projet MVC et mon application Xamarin.iOS localement.

Assurez-vous de déposer des problèmes de ce type sur dotnet/corefx. Supposer que vos dépendances seront portées (à moins que ce ne soit très populaire) est la mauvaise chose à faire.

@davidfowl Question : Je veux Fichier -> Nouveau projet avec ASP.NET Core 2.0 et m'authentifier auprès d'AD. Cela sera-t-il possible ? Je ne peux tout simplement pas imaginer une plate-forme Microsoft expédiée sans la possibilité de le faire.

D'accord avec tout là-bas mais je ne vois pas comment cette décision affecte tout ce que vous avez dit. Je veux toutes ces mêmes choses

En supprimant la prise en charge de .NET v4.x, cela tuera un chemin de migration populaire et fragmentera encore plus l'écosystème .NET et empêchera de nombreux développeurs et organisations de pouvoir l'adopter, ce qui réduira le pool communautaire plus large de connaissances et d'investissements dans ASP. NET Core, car de nombreux développeurs .NET devront prendre en charge indéfiniment leurs bases de code ASP.NET v4.x existantes (sur lesquelles ils sont payés pour travailler à plein temps).

Plus la part de marché de .NET Core est petite, moins il sera prioritaire pour les responsables de la bibliothèque de le prendre en charge et certains ne le feront probablement jamais s'ils travaillent pour une organisation qui ne pourra plus envisager de migrer vers ASP.NET Core en raison de ceci, qui à son tour affecte n'importe qui d'autre en fonction de ses forfaits, et ainsi de suite. Ce sont tous des effets secondaires de l'augmentation de la charge liée à l'adoption d'ASP.NET Core, en ne disposant pas d'une plate-forme stable, de garanties de support à long terme et en tuant maintenant un chemin de migration populaire.

Je crois que tout le monde ici veut que l'écosystème .NET prospère, mais il semble que nous ne soyons pas d'accord avec l'équipe MS sur la meilleure façon d'y parvenir, car je crois fermement que l'abandon de .NET v4.x aussi tôt avant une quantité connue, hautement compatible, Une version LTS stable est disponible est une erreur qui aura des effets néfastes pour les années à venir.

@davidfowl Merci - votre commentaire aide beaucoup. J'avais (apparemment à tort) compris que la plupart/toutes les bibliothèques de support se déplaçaient de netstandard dans le cadre de ce changement. J'en utilise plusieurs et j'en connais d'autres qui le font aussi, alors entendre qu'ils ne le sont pas est une bonne nouvelle.

@NickCraver quel type d'authentification utilisez-vous contre AD aujourd'hui ? OpenIdConnect, WsFed, NTLM, autre ?

@Tratcher AD auth, via DirectoryServices (nous devons interroger l'appartenance au groupe, etc. - les bits standard)

@mythz Je pense que c'est raisonnable et je pense que l'extension de la durée de vie de la prise en charge d'ASP.NET Core 1.x serait suffisante pour couvrir la plupart des cas.

Je vois pourquoi vous devez prendre cette décision à un moment donné, mais je pense aussi que c'est prématuré et je serais plus heureux avec :

• ASP.NET Core 2.x étant LTS et le dernier à prendre en charge Full Framework (puisque nous étions déjà en avant-première, vous n'êtes pas trop loin) avec également SignalR suivant plus tard dans l'année pour le prendre en charge afin que ce soit le cadre cible pour faire le saut d'ASP.NET à ASP.NET Core
• 3.x supprime la prise en charge de Full Framework et est publiée lorsque les principales dépendances sont migrées

À mon avis, étendre simplement la prise en charge d'ASP.NET Core 1.1 ne serait pas suffisant car cette plate-forme n'est pas suffisamment mature/adoptée pour être la cible de nombreuses migrations ASP.NET (dans mon cas, SignalR étant le bloqueur).

Juste pour le lulz, j'ai essayé d'utiliser EntityFramework 6 - que j'ai vu massivement utilisé dans les applications ASP.NET Core 1.0 sur lesquelles j'ai travaillé - avec les dernières versions nocturnes de Preview2 .NET Core. Devinez quoi...

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <NetStandardImplicitPackageVersion>2.0.0-*</NetStandardImplicitPackageVersion>
    <RuntimeFrameworkVersion>2.0.0-preview2-002093-00</RuntimeFrameworkVersion>
    <PackageTargetFallback>net45;net461</PackageTargetFallback>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="EntityFramework" Version="6.1.3" />
    <PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0-*" />
  </ItemGroup>

</Project>

Arrêtez de prétendre que les assemblages conçus et compilés pour le framework complet fonctionneront parfaitement sur .NET Core : les cas triviaux (lire hello world apps) fonctionneront probablement, mais dans de nombreux cas, vous finirez par être bloqué par des API manquantes ou des API non fonctionnelles .

Ce qui est absolument terrible, c'est que vous ne réaliserez que cela ne fonctionne pas au moment de l'exécution. Dans certains cas, ce ne sera même pas évident du tout. Par exemple, SqlClient .NET Core ne prend pas en charge l'inscription de transactions ambiantes ni les transactions distribuées avec TransactionScope : même si vous trouvez un moyen de faire fonctionner EF 6, vos TransactionScope s ne sera pas efficace du tout et vos appels DB n'utiliseront pas le niveau d'isolation dont vous avez besoin.

Je pense qu'il est nécessaire d'ajouter mes deux cents ici en ce qui concerne mes préoccupations concernant ce déménagement. Nous avons une application de bureau qui est principalement Windows Forms avec certains des nouveaux domaines développés dans WPF. Il y a plus de 15 ans d'efforts dans cette application et il faudra des années pour s'éloigner complètement de WinForms. J'aimerais que ce ne soit pas le cas mais ça l'est. Nous nous sommes efforcés d'intégrer davantage de modularité dans la base de code afin de pouvoir utiliser les couches métier et d'accès aux données via une interface Web plus récente et l'application WinForms existante. J'avais l'intention de passer très prochainement à ASP.NET Core pour notre nouvelle application Web, mais comme je viens de le dire, je devrai consommer une grande majorité de notre base de code existante qui cible .NET v4.6.x. Je sais avec certitude que nous utilisons System.Drawing et System.Security.Cryptography. Nous utilisons également intensivement TransactionScope de la manière mentionnée ci-dessus.

J'attendais avec impatience de bénéficier de certains des avantages d'ASP.NET Core, tels que la possibilité d'encapsuler des zones de notre application Web dans des assemblages distincts sans avoir à compter sur MEF pour tout rassembler. Il y a beaucoup de raisons supplémentaires, mais c'est celle-là qui le rend vraiment agréable. Cependant, si je fais la transition de notre application vers ASP.NET Core, je serai probablement bloqué sur 1.x dans un avenir prévisible car nous devons maintenir la portabilité de notre code backend avec WinForms. Je me suis concentré principalement sur le produit Web, donc je ne peux pas vous dire où nous nous accrochons à des choses comme WMI, etc., et si cela a un impact sur la question de la portabilité, mais je sais que nous sommes dans notre base de code. Nous sommes dans une phase vraiment intéressante en ce moment et la dernière chose que je veux avoir à faire est de développer toutes les versions Web de nos fonctionnalités sur ASP.NET MVC 5 et d'accumuler un tas de nouveau code hérité qui devra être porté à certains effort futur.

Je suis sûr que nous allons avoir beaucoup d'utilisations qui vont nous empêcher de cibler .NET Standard même si/quand nous n'utilisons plus WinForms. Nous sommes un partenaire Microsoft et nous travaillons directement avec Microsoft pour notre produit de plusieurs manières, donc je ne veux pas entrer dans trop de détails sur ce que nous faisons ici, mais je serais heureux d'avoir une discussion plus privée avec @ shanselman ou @davidfowl si vous avez besoin de plus de détails sur ce que nous faisons. Je vais également être à MS Build et je pourrais vous rencontrer et parler à l'un de vous si vous êtes présent.

Je pense que vous n'avez pas envisagé les entreprises utilisant votre pile avec ce genre de défis. Cependant, avis de non-responsabilité complet : j'ai l'intention d'exécuter l'analyseur de portabilité mentionné précédemment pour voir où nous sommes effectivement bloqués en raison de la nécessité de maintenir cette portabilité dans notre base de code. Je serai heureux de vous fournir une liste de toutes les API .NET Framework qui échouent à cette vérification.

Mouahaha. Je ne sais pas si je dois rire ou pleurer...

Voici le rapport généré par l'outil d'analyse ApiPort pour mon application triviale EF 6 à 23 lignes qui ne fonctionne pas :

La compilation croisée est une surcharge qui doit être équilibrée avec les besoins des clients et des produits. C'est pourquoi nous souhaitons obtenir ces commentaires afin de pouvoir définir plus concrètement à quoi ressemble le paysage pour nos clients et pour nous alors que nous continuons à faire évoluer ASP.NET Core.

Avant l'ouverture de ce problème, y avait-il un processus de rétroaction ?

Nous parlons tous de délais et de prise en charge de la version 1.1, mais le fait qu'ASP.NET Core va supprimer le framework complet m'a énormément surpris.

Ma compréhension était que le cadre de base était un jeu multiplateforme, un nouveau cadre composé d'un sous- ensemble du cadre complet qui n'est pas couplé à Windows. La version 2.0 était celle que nous attendions tous et où nous récupérons la plupart des API.

ASP.NET Core était la nourriture pour chien de ce nouveau framework, un nouveau framework Web qui dépendait d'une si petite surface d'API de framework qu'il pouvait s'exécuter partout.

Je m'attendais à ce qu'une fois que le framework de base soit à parité avec le framework complet, toutes les nouvelles API seraient ajoutées à netstandard et finiraient par être intégrées aux deux frameworks. Nous commencerions tous à cibler le netstandard et tout serait des arcs-en-ciel et des licornes.

Maintenant, pour trouver ASP.NET ne sera même pas dogfood netstandard et va spécifique au framework hein :/

@rohatsu

À mon avis, étendre simplement la prise en charge d'ASP.NET Core 1.1 ne serait pas suffisant car cette plate-forme n'est pas suffisamment mature/adoptée pour être la cible de nombreuses migrations ASP.NET (dans mon cas, SignalR étant le bloqueur).

Et si SignalR fonctionnait sur ASP.NET Core 1.x ? Qu'y a-t-il d'autre d'immature dans la plateforme dont vous avez besoin ?

@millman82 Merci pour ce partage. Il semble que vous seriez bloqué sur la version avant que la prise en charge de .NET Framework ne soit abandonnée pendant un certain temps. Donc, certaines des suggestions ici où nous gardons la compatibilité 2.x et 3.x l'abandonneraient pourraient même ne pas fonctionner pour vous. Pourquoi ne pas simplement rester sur ASP.NET Core 1.x ? Que manque-t-il dont vous avez besoin dans votre port ? Ou est-ce juste la même préoccupation que celle de @NickCraver (que 2.x ne le supporte pas vous rend nerveux à l'idée de parier dessus).

@jkells

Je m'attendais à ce qu'une fois que le framework de base soit à parité avec le framework complet, toutes les nouvelles API seraient ajoutées à netstandard et finiraient par être intégrées aux deux frameworks. Nous commencerions tous à cibler le netstandard et tout serait des arcs-en-ciel et des licornes.

Ce n'est pas exagéré, il manque juste la composante temporelle. Fera éventuellement partie de tous les cadres que chaque navire expédiera selon son propre horaire.

Maintenant, pour trouver ASP.NET ne sera même pas dogfood netstandard et va spécifique au framework hein :/

Une partie de celui-ci cible toujours netstandard, comme cela a été mentionné à plusieurs reprises dans ce fil.

Pourquoi ne pas simplement rester sur ASP.NET Core 1.x ?

Vous ne pouvez pas - il n'y a plus de support 1 an après la chute de 2.0 (en supposant que 2.0 est le prochain LTS).

@davidfowl C'est certainement une grande partie de cela. Nous utilisons également OData et SignalR dans notre application Web actuelle et cela doit être dans ASP.NET Core avant de pouvoir passer. Cependant, la seule chose que je ne veux pas qu'il se produise est d'être coincé dans les limbes lorsque la prise en charge d'ASP.NET Core 1.x est abandonnée et qu'il n'y a pas de chemin de migration avec les parties de framework que nous utilisons qui ne sont pas actuellement prises en charge. Je prévois que ASP.NET Core remplacera ASP.NET en gros. C'est peut-être quelque part sur la route, mais ça vient. Sachant que je détesterais réécrire notre interface utilisateur maintenant dans ASP.NET MVC 5 (nous avons quelques éléments là-bas maintenant, mais il est facile de le déplacer car il est petit) seulement quelques années plus tard, réécrivez-le à nouveau dans ASP.NET Core une fois la fin de vie d'ASP.NET arrivée.

Nous pourrions potentiellement nous préparer à être gravement brûlés si ce chemin de migration est inexistant lorsque l'EOL d'ASP.NET Core 1.x arrive s'il est étendu entre-temps si nous ciblons Core 1.x maintenant. Nous pourrions probablement contourner certains d'entre eux avec des micro-services, cependant, cela a bien sûr ses propres préoccupations.

@ctolkien

Vous ne pouvez pas - il n'y a plus de support 1 an après la chute de 2.0 (en supposant que 2.0 est le prochain LTS).

Supposons une seconde qu'il n'est pas hors de support lorsque 2.0 tombe. N'est-ce pas suffisant ?

Cependant, la seule chose que je ne veux pas qu'il se produise est d'être coincé dans les limbes lorsque la prise en charge d'ASP.NET Core 1.x est abandonnée et qu'il n'y a pas de chemin de migration avec les parties de framework que nous utilisons qui ne sont pas actuellement prises en charge.

Remplacez 1.x par 2.x dans cette phrase. Pensez-vous que dans un an toutes vos dépendances seraient portées ?

Remplacez 1.x par 2.x dans cette phrase. Pensez-vous que dans un an toutes vos dépendances seraient portées ?

Pas du tout, cependant, je m'attendrais à ce que lorsqu'ils ne seraient plus en mesure de cibler .NET Full, ils le seraient. Je comprends pourquoi vous voudriez augmenter cela, mais je ne pense pas que vous puissiez vous attendre à ce que les entreprises adoptent quelque chose qui ne sera plus pris en charge sans aucun moyen de passer à une version plus récente car les dépendances manquantes n'ont pas été portées.

Je ne pense pas que vous puissiez vous attendre à ce que les entreprises adoptent quelque chose qui ne sera plus pris en charge sans aucun moyen de passer à une version plus récente car les dépendances manquantes n'ont pas été portées.

Pourquoi tomberait-il hors de support? Dans mon monde hypothétique, nous prendrions en charge ASP.NET Core 1.x sur .NET Framework plus longtemps.

Pourquoi tomberait-il hors de support? Dans mon monde hypothétique, nous prendrions en charge ASP.NET Core 1.x sur .NET Framework plus longtemps.

Ma question est combien de temps encore ? De plus, l'équipe est-elle suffisamment grande pour apporter ces dépendances nécessaires comme SignalR et OData à ASP.NET Core 1.x et maintenir la prise en charge jusqu'à ce que toutes ces dépendances manquantes aient, en fait, été portées ? On dirait que cela va à l'encontre des arguments avancés plus tôt sur la raison pour laquelle vous voudriez abandonner la prise en charge complète de .NET maintenant. question honnête...

Ma question est combien de temps encore ? De plus, l'équipe est-elle suffisamment grande pour apporter ces dépendances nécessaires comme SignalR et OData à ASP.NET Core 1.x et maintenir la prise en charge jusqu'à ce que toutes ces dépendances manquantes aient, en fait, été portées ? On dirait que cela va à l'encontre des arguments avancés au début sur la raison pour laquelle vous voudriez abandonner la prise en charge complète de .NET maintenant. question honnête...

Je vais lancer un nombre aléatoire, 3 ans. L'équipe ASP.NET ne possède pas l'intégration Odata, l'équipe odata le fait donc je ne peux pas répondre pour eux. Quant à SignalR, je pense qu'il serait possible de cibler ASP.NET Core 1.x.

Le problème que je vois est que chaque personne a un ensemble différent de "dépendances manquantes", ce qui rend impossible de raisonner sur le moment où il est même "ok" d'abandonner la prise en charge de .NET Framework pour tout le monde. Il est également probable que certaines de ces dépendances ne soient jamais portées (comme CSOM).
Bien sûr, étant sur le train 1.x, vous obtiendrez des corrections de bogues et des fonctionnalités mineures, mais la majeure partie du travail se produirait toujours dans la dernière version majeure d'ASP.NET Core.

De plus, rien de tout cela ne vous empêche d'utiliser .NET Core 2.0 ou .NET Standard 2.0 avec ASP.NET Core 1.x. Je veux juste m'assurer que tout le monde en est conscient, car cette constante de threads confond ASP.NET Core avec .NET Core (ce qui est l'une des raisons pour lesquelles nous voulons cibler uniquement .NET Core).

Le problème que je vois est que chaque personne a un ensemble différent de "dépendances manquantes", ce qui rend impossible de raisonner sur le moment où il est même "ok" d'abandonner la prise en charge de .NET Framework pour tout le monde.

Engagez l'écosystème pour savoir quelle est la liste (non, ce numéro n'est pas le lieu pour le faire). S'il s'agit d'une dépendance appartenant à Microsoft, transférez-la. Si ce n'est pas le cas, contactez le propriétaire pour l'informer des plans et aidez-le avec un guide de migration (s'il ne fait rien, ce n'est pas la faute de Microsoft). Dans le temps nécessaire pour passer par ce processus, prenez en charge ASP.net core 1.x. Je ne vois pas d'autre moyen d'atteindre vos objectifs sans déranger beaucoup de gens. C'est une grande chose proposée qui nécessite un niveau élevé de soins et d'attention pour bien faire.

Personnellement, je pense qu'il y a beaucoup plus de confusion entre .NET Framework vs .NET Standard vs .NET Core. Quand j'ai vu que je pouvais cibler .NET Framework, je n'ai jamais dit "mais c'est ASP.NET Core, alors pourquoi puis-je utiliser .NET Framework". Les distinctions entre les éléments ci-dessus sont beaucoup plus déroutantes pour la plupart de votre clientèle. J'aime tout ce que fait ASP.NET Core. J'adore également la direction avec .NET concernant l'indépendance de la plate-forme. Je pense juste que le domaine de la confusion est mal défini. Je dirais que la majorité de votre base d'utilisateurs aura une certaine quantité de code qui n'est pas portable en raison de la nature de ce qu'elle fait et des API qu'elle cible dans le Framework.

Ma préférence serait de travailler vers la parité des API dans .NET Core et .NET Standard et .NET Framework. Déterminez également quel est celui que les gens devraient s'efforcer de cibler. Comme je pense que cela a été dit plus tôt, peut-être d'une manière légèrement différente, .NET Standard ressemble à un pansement. Finalement, je m'attendrais à ce que .NET Core soit la seule option "framework" et lorsque cela se produit, .NET Framework et .NET Standard sont abandonnés. Moi-même, et je pense que la plupart de ceux qui se sont exprimés depuis l'annonce, aimeraient pouvoir continuer à bénéficier du travail que vous faites du côté ASP.NET Core sans avoir la liberté de ce qu'ils exécutent leur code en plus d'être supprimé.

Je pense que les cas considérés comme exceptionnels, comme le mien où j'ai une dépendance à des choses comme WMI, ne sont pas aussi exceptionnels que l'équipe peut le penser. Encore une fois, je ferai la recherche et verrai ce qui manque (bien que le message précédent donnant des résultats de portabilité incorrects m'inquiète un peu de l'exactitude) et je vous le signalerai avec plaisir dans un média plus privé.

En bout de ligne, nous sommes passionnés par cela parce que nous voulons l'utiliser.

Personnellement, je pense qu'il y a beaucoup plus de confusion entre .NET Framework vs .NET Standard vs .NET Core. Quand j'ai vu que je pouvais cibler .NET Framework, je n'ai jamais dit "mais c'est ASP.NET Core, alors pourquoi puis-je utiliser .NET Framework". Les distinctions entre les éléments ci-dessus sont beaucoup plus déroutantes pour la plupart de votre clientèle. J'aime tout ce que fait ASP.NET Core. J'adore également la direction avec .NET concernant l'indépendance de la plate-forme. Je pense juste que le domaine de la confusion est mal défini. Je dirais que la majorité de votre base d'utilisateurs aura une certaine quantité de code qui n'est pas portable en raison de la nature de ce qu'elle fait et des API qu'elle cible dans le Framework.

Nous avons beaucoup de clients et nous avons de nouveaux développeurs qui n'ont jamais vu .NET de leur vie. Nous devons satisfaire tout le monde car c'est ce que nous essayons de faire en tant que Microsoft. Les personnes qui exécutent sur .NET Framework savent, aiment et comprennent que cela fonctionne, alors assurez-vous que vous comprenez qu'ASP.NET Core s'exécute sur .NET Framework, mais en tant que nouveau développeur approchant de la plate-forme, j'espère ne jamais mentionner cela car cela brouille l'histoire par rapport à quelque chose comme go ou node (qui ont à peu près 0 héritage à ce stade).

Ma préférence serait de travailler vers la parité des API dans .NET Core et .NET Standard et .NET Framework. Déterminez également quel est celui que les gens devraient s'efforcer de cibler. Comme je pense que cela a été dit plus tôt, peut-être d'une manière légèrement différente, .NET Standard ressemble à un pansement. Finalement, je m'attendrais à ce que .NET Core soit la seule option "framework" et lorsque cela se produit, .NET Framework et .NET Standard sont abandonnés. Moi-même, et je pense que la plupart de ceux qui se sont exprimés depuis l'annonce, aimeraient pouvoir continuer à bénéficier du travail que vous faites du côté ASP.NET Core sans avoir la liberté de ce qu'ils exécutent leur code en plus d'être supprimé.

Tout cela se passe en parallèle. ASP.NET Core n'arrête pas de travailler sur les fonctionnalités tant que "tout" n'est pas transféré sur .NET Core à partir de .NET Framework. ASP.NET continuera d'innover et de tirer parti des API disponibles sur .NET Core puisque nous livrons dans le même coffret.

Je vois quelques idées tendances sur ce fil de:

• Je veux que vous preniez en charge .NET Framework pour toujours.
• Je souhaite que vous preniez en charge .NET Framework jusqu'à ce que les dépendances dont j'ai besoin pour mon application soient portées.
• J'ai juste besoin d'un an de plus, ce sera assez de temps pour que j'abandonne le support de .NET Framework (ASP.NET Core 3.x).

Il y a aussi le fait que nous n'avons pas écrit d'annonce (ce qui est de notre faute) mais qu'une arrive (promis, je blâme le week-end).

Je ne sais pas non plus à quoi ressemble la parité API pour la plupart des gens ici, je suppose que c'est différent pour différentes personnes. .NET Framework est une technologie d'entreprise solide et fiable de plus de 15 ans liée à Windows.
.NET Core a été conçu pour écrire des micro-services multiplateformes légers et modernes et a lentement évolué pour être plus compatible afin de faciliter le portage des bibliothèques. Cela dit, je ne sais pas ce que cela signifie d'aborder .NET Framework en termes de compatibilité ou si c'est même un objectif (ce n'était pas le cas à l'origine). À un moment donné, vous ne pourrez plus utiliser ASP.NET Core sur .NET Framework et il y aura des dépendances qui ne pourront pas être réécrites et qui ne seront pas compatibles avec .NET Core. Les applications devront en tenir compte lors de leur conception avec ASP.NET Core à l'esprit (dans un avenir proche).

En ce qui concerne les projets sur lesquels je travaille, une période de support beaucoup plus longue pour 1.1 serait une atténuation décente. Il est peu probable que nous puissions supprimer les dépendances netfx en 1 an, mais beaucoup plus probablement avec les +3 ans que vous avez suggérés en tant qu'homme de paille. Ce serait vraiment bien d'avoir une version où tout se rassemble d'abord au niveau 2.0 - c'est le point où tout était censé devenir plus facile à porter ! Je ne parle que pour une seule organisation, mais "2.0 sera une version LTS ; 3.0 supprimera netfx" serait fondamentalement comme d'habitude pour nous au lieu d'être une cause pour FUD.

Je voudrais également faire écho à ce que @PureKrome a dit sur l'appréciation de cet engagement, cela a été une discussion très informative.

En ce qui concerne la parité - j'avais précédemment supposé que .net core n'approcherait jamais les niveaux de compatibilité du framework .net, mais que c'était bien car asp .net core continuerait à prendre en charge les deux.

Je pense qu'en tant que communauté, nous utilisons essentiellement .net core pour utiliser asp.net core, pas pour ses propres mérites. Comme vous l'avez dit, il s'agit d'un seul produit, et j'avais pensé au core clr comme une partie facultative de ce produit avec des avantages et des inconvénients s'il était choisi.

Après avoir dormi dessus pendant une nuit -

Personnellement, je pense que c'est une bonne idée d'abandonner l'ancien framework .net et d'écrire le meilleur framework Web possible pour l'environnement d'exécution moderne.

Mais vous savez que c'est définitivement risqué et que vous pourriez perdre certains de vos clients ici en cours de route (j'espère que non - mais je fais beaucoup de conseil - et .NET Core est pour de nombreuses entreprises hors de portée en ce moment - espérons 2.0 ça change).

..et oui - la communication autour de cela était (comme d'habitude) quelque chose que vous pouvez améliorer (la version la plus polie de cette phrase pour un Allemand) ;)

+1

Personnellement, je pense que c'est une bonne idée d'abandonner l'ancien framework .net et d'écrire le meilleur framework Web possible pour l'environnement d'exécution moderne.

Je suis fortement d'accord. J'espérais que cela aurait été un changement progressif, par exemple Kestrel abandonnant d'abord le support pour perf (l'hébergement basé sur http.sys restant), puis mvc/* suivant pour les améliorations de l'API et des fonctionnalités pendant que les efforts de portage/test de compatibilité pour netstandard2.0 commencent.

Excellent. Dans ce cas, tant que Microsoft s'assure que 1.x est pris en charge (toutes sortes de corrections de bogues et > support opérationnel) jusqu'à ce qu'il offre aux clients un chemin de migration 2.x approprié (par exemple SignalR), alors je suis > à l'aise d'attendre mon temps jusqu'à ce que nous ayons besoin d'asp.net core 2.

+1

capable de porter uniquement sur .NET Core (peut-être que lors du développement d'ASP.NET Core sur un framework complet, vous avez pris de nouvelles dépendances qui ne seront jamais portées à titre d'exemple).

Entièrement d'accord.
Pour l'instant, je pense que c'est une bonne décision. Je pense que dans des scénarios idéaux, nous avons besoin de plus d'un an de support, je ne sais pas peut-être 2-3 ans, et d'informations sur ce qui sera porté, pour la confiance de la communauté.
Pas de prise en charge de .net 461.

@dasMulli

Je suis fortement d'accord. J'espérais que cela aurait été un changement progressif, par exemple Kestrel abandonnant d'abord le support pour perf (l'hébergement basé sur http.sys restant), puis mvc/* suivant pour les améliorations de l'API et des fonctionnalités pendant que les efforts de portage/test de compatibilité pour netstandard2.0 commencent.

Nous n'exécutons même pas de tests de performances sur .NET Framework... Les tests de portage et les améliorations de .NET Core et .NET Standard se produiront de toute façon, que l'OMI n'a aucune incidence sur l'abandon ou non de la prise en charge de .NET Framework. Au contraire, cela nous oblige à nous concentrer sur ces scénarios, car c'est la seule cible.

@gulbanana

Ce serait vraiment bien d'avoir une version où tout se rassemble d'abord au niveau 2.0 - c'est le point où tout était censé devenir plus facile à porter ! Je ne parle que pour une seule organisation, mais "2.0 sera une version LTS ; 3.0 supprimera netfx" serait fondamentalement comme d'habitude pour nous au lieu d'être une cause pour FUD.

Pourquoi avez-vous besoin d'ASP.NET Core 2.0 (oubliez .NET Standard et .NET Core 2.0) ?

Nous n'avons pas particulièrement besoin des fonctionnalités d'asp.net core 2.0. J'aimerais beaucoup avoir les processus de construction et l'interopérabilité plus simples fournis avec la vague 2.0. Asp.net core 1.1, s'il s'exécute sur netcoreapp2.0, pourra-t-il utiliser les bibliothèques netstandard2.0? Cela serait-il considéré comme un scénario « standard » et pris en charge plutôt que quelque chose auquel personne ne teste ou auquel personne ne prête attention ?

Fondamentalement, si 1.1 devenait LTS, je crains que les problèmes ne soient résolus dans dix-huit mois avec "Eh bien, vous pouvez le faire en utilisant l'API 2.0".

Nous n'avons pas particulièrement besoin des fonctionnalités d'asp.net core 2.0. J'aimerais beaucoup avoir les processus de construction et l'interopérabilité plus simples fournis avec la vague 2.0. Asp.net core 1.1, s'il s'exécute sur netcoreapp2.0, pourra-t-il utiliser les bibliothèques netstandard2.0? Cela serait-il considéré comme un scénario « standard » et pris en charge plutôt que quelque chose auquel personne ne teste ou auquel personne ne prête attention ?

Bien sûr, cela fonctionnerait. Comme je l'ai dit tout au long, les 3 choses sont complètement découplées aujourd'hui. Voici un exemple de projet exécutant ASP.NET Core 1.1 sur .NET Core 2.0 à l'aide d'une version des API System.Configuration qui ont été portées vers un package .NET Standard 2.0 :

https://github.com/davidfowl/AspNetCore1OnNetCore2

Je serais plus heureux d'accepter cela s'il y avait une couche d'interopérabilité automatique entre .NET Core et .NET Framework (pas l'actuelle qui peut lever des exceptions lors de l'exécution, et non des appels WebAPI internes faits soi-même) - une sorte de wrapper ("WowNET" ?) Cela nous obligerait à conserver le code dépendant de 4.6 dans des fichiers .dll séparés, mais permettrait d'exécuter l'héritage au détriment des performances (ce qui, dans le cas des applications LOB, n'est pas la principale préoccupation). Pensez-vous que ce serait techniquement possible ?

Je me demande également si ce changement signifie que le framework complet lui-même approche de la fin de sa vie et ne jouera aucun autre rôle important que d'être un composant hérité une fois que la plupart des API seront déplacées vers .NET Standard.

Fondamentalement, si 1.1 devenait LTS, je crains que les problèmes ne soient résolus dans dix-huit mois avec "Eh bien, vous pouvez le faire en utilisant l'API 2.0".

C'est toujours une préoccupation. La réponse est toujours "ça dépend". Les corrections de bogues sont pesées en conséquence et les grandes fonctionnalités sont susceptibles de tomber dans ce seau le plus souvent.

@rohatsu

Je serais plus heureux d'accepter cela s'il y avait une couche d'interopérabilité automatique entre .NET Core et .NET Framework (pas l'actuelle qui peut lever des exceptions lors de l'exécution, et non des appels WebAPI internes faits soi-même) - une sorte de wrapper ("WowNET" ?) Cela nous obligerait à conserver le code dépendant de 4.6 dans des fichiers .dll séparés, mais permettrait d'exécuter l'héritage au détriment des performances (ce qui, dans le cas des applications LOB, n'est pas la principale préoccupation). Pensez-vous que ce serait techniquement possible ?

Un peu comme ça https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-root mais pour .NET Core et .NET Framework. Nous avons fait quelque chose de très similaire lorsque nous avons pris en charge ASP.NET Helios, un shim .NET Framework qui a été utilisé pour booster coreclr dans IIS. Les hacks pour le faire fonctionner étaient assez laids même s'il s'agissait d'un mélange de COM et de structures de passage à la méthode Main via des arguments string [] . Tout techniquement faisable cependant. Je ne sais pas à quelle sorte de fidélité vous vous attendez, car ils ne sont pas le même temps d'exécution et vous ne pouvez pas passer d'objets d'avant en arrière. Vous exécuteriez également 2 GC, 2 tonnes de DLL supplémentaires dans le même processus et je ne suis pas sûr de ce que vous gagnez en faisant quelque chose hors proc.

Je me demande également si ce changement signifie que le framework complet lui-même approche de la fin de sa vie et ne jouera aucun autre rôle important que d'être un composant hérité une fois que la plupart des API seront déplacées vers .NET Standard.

Loin de. .NET Framework évolue et est livré au rythme de Windows car il s'agit d'un composant Windows. Nous venons de publier .NET Framework 4.7 (https://blogs.msdn.microsoft.com/dotnet/2017/04/05/announcing-the-net-framework-4-7/) ainsi qu'un tas de nouvelles fonctionnalités. Le fait est que .NET Core peut et sera livré plus rapidement car il n'est lié à rien d'autre, donc les API, les fonctionnalités d'exécution, etc. y apparaîtront en premier. Cela ne signifie pas que les choses ne finiront pas par arriver à .NET Standard et .NET Framework. Il faudra juste plus de temps pour y arriver. Le fait que .NET Framework se mette à jour sur place est la raison pour laquelle nous sommes si prudents lors du portage des modifications. Tout changement peut casser n'importe quelle application lorsqu'une mise à jour est automatiquement poussée sur un milliard de machines 😉 . Avec .NET Core, le framework est côte à côte, les applications doivent donc s'inscrire à la version la plus récente pour obtenir de nouvelles fonctionnalités ou des correctifs. Il y a juste beaucoup plus de liberté là-bas.

Juste pour peser avec les bibliothèques net4x que nous utilisons actuellement dans ASP.NET Core 1.x, cela ne fonctionnerait pas dans 2.0 : EntityFramework 6. EFCore a juste de nombreuses fonctionnalités manquantes que nous utilisons (par exemple, les crochets d'interception/cycle de vie). Nous sommes donc bloqués sur EF6 pendant un certain temps.

Et selon le message de @PinpointTownes , EF6 ne fonctionne pas avec la version actuelle (en développement) d'ASP.NET Core 2.x.

@nphmuller , vous continuerez à utiliser ASP.NET Core 1.x jusqu'à ce que d'autres dépendances soient déplacées (je ne sais pas combien de choses vous avez besoin d'EF Core et quel est le statut).

@davidfowl Bien sûr, si la fenêtre de support d'ASP.NET Core 1.x ne passe pas pendant ce temps.
La caractéristique principale est l'interception (crochets de cycle de vie). D'autres fonctionnalités manquantes peuvent être contournées plus facilement pour nous. L'interception fait partie de leur carnet de commandes, mais n'est pas liée à une version. Et mon instinct me dit qu'il ne sera pas mis en œuvre avant un moment.

@gulbanana : Je pense qu'en tant que communauté, nous utilisons essentiellement .net core pour utiliser asp.net core, pas pour ses propres mérites.

Parle pour toi. Il y a un certain nombre d'entre nous pour qui le principal avantage de .NET Core est de quitter Windows sur le serveur.

Et, je suppose, tous les sales hippies propriétaires de Mac. 😝

@bradwilson Et, je suppose, vous tous, sales hippies propriétaires de Mac.

Parlez pour vous, certains d'entre nous ne sont pas hippies ;P

Mais oui, échapper à Windows (ou vraiment, IIS et http.sys) est ce que je veux pour .NET Core parallèlement au déploiement xcopy, perf, etc.

L'isolation de l'ancien code dans des services distincts ou le portage vers ASP.NET Core est payant pour des raisons autres que nouvelles et brillantes.

@PinpointTownes est une erreur de référence, que se passe-t-il si vous référencez System.Configuration selon https://github.com/aspnet/Home/issues/2022#issuecomment -299810945 ? EF6 dit qu'il n'a pas de dépendances car tout se trouve dans l'ancien bundle GAC/Full Framework

@benaadams et @PinpointTownes la raison de son échec est que System.Configuration.ConfigurationManager n'est pas le nom de DLL attendu par .NET Framework. Je ne sais pas si le port de System.Configuration est valide.

      "system.configuration.configurationmanager/4.4.0-preview2-25308-01": {
        "dependencies": {
          "System.Security.Cryptography.ProtectedData": "4.4.0-preview2-25308-01"
        },
        "runtime": {
          "lib/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        },
        "compile": {
          "ref/netstandard2.0/System.Configuration.ConfigurationManager.dll": {}
        }

Oui, être capable d'exécuter des serveurs non Windows est génial et un gros tirage... mais sans le noyau asp.net, que feriez-vous dessus ? Même Nancy pour le noyau .net s'appuie sur le noyau asp.net via Kestrel, UseOwin(), etc.

J'ai créé plusieurs microservices qui n'utilisent pas ASP.NET Core. Ce sont des choses comme des processus de travail qui interrogent une file d'attente pour faire son travail.

Ce n'est pas juste, nous suivons des feuilles de route, et vous n'en avez rien dit avant !!
Si vous l'avez déjà dit, nous n'utiliserons pas ASP.NET Core dans notre projet car nous avons besoin de .NET 4.x Libs.
Notre planification comprend la mise à jour de nos projets vers ASP.NET Core 2 en raison des nouvelles fonctionnalités nécessaires.
Nous avons également besoin d'ASP.NET Core 2 pour cibler .NET 4.x. si ce n'est pas possible, qu'en est-il de la prise en charge d'ASP.NET Core 1.x, envisagez-vous également d'y ajouter toutes les nouvelles fonctionnalités ou simplement de corriger des bogues.

Notre planification comprend la mise à jour de nos projets vers ASP.NET Core 2 en raison des nouvelles fonctionnalités nécessaires.

Lesquels?

@PinpointTownes est une erreur de référence, que se passe-t-il si vous faites référence à System.Configuration selon #2022 (commentaire) ?

L'ajout <Reference Include="System.Configuration" /> n'a aucun effet (c'est-à-dire que la même exception est levée), car il semble que cela ne puisse pas être résolu à partir du GAC (pas sûr que ce soit vraiment surprenant, bien que '):

Je ne sais pas si le port de System.Configuration est valide.

Donc la conclusion officielle est... vous ne pouvez pas utiliser une bibliothèque écrite pour .NET Framework 4.x sur .NET Core si elle utilise System.Configuration ?

@PinpointTownes Je ne suis même pas sûr que la version de System.Configuration soit expédiée (celle du paquet). Peut-être que c'est le cas, peut-être que ce n'est pas le cas (c'est une discussion pour commencer sur corefx). Je te dis juste pourquoi ton échantillon s'est cassé comme ça.

Ajouter n'a aucun effet (c'est-à-dire que la même exception est levée), car il semble que cela ne puisse pas être résolu à partir du GAC (pas sûr que ce soit vraiment surprenant, bien que '):

AFAIK, il n'y a pas de support par défaut pour les références GAC dans les projets SDK. Voir https://github.com/dotnet/sdk/issues/987#issuecomment -286307697 pour voir comment l'activer.

La conclusion officielle est donc... vous ne pouvez pas utiliser une bibliothèque écrite pour .NET Framework 4.x sur .NET Core si elle utilise System.Configuration ?

Ma conclusion est que vous devriez ouvrir un problème sur CoreFX avec l'exemple que vous avez fourni ci-dessus.

@davidfowl merci pour la réponse
Certaines fonctionnalités et aides nécessaires sur EF Core sont prévues dans 2.0, en particulier pour les données de mappage (mappages de type autonomes)...
Quoi qu'il en soit, j'ai juste besoin d'avoir une idée claire de la feuille de route d'ASP.NET Core 1.x, notre équipe est confuse et inquiète.

Une chose avec laquelle je me bats personnellement est la différence entre "plate-forme stable" et "nouvelles fonctionnalités". D'une part, nous voulons que la plate-forme soit stable, fiable et compatible, d'autre part, personne ne veut rester sur 1.x car elle n'a pas de fonctionnalités 2.x. Y a-t-il des fonctionnalités super convaincantes dans ASP.NET Core 2.x qui attirent les gens dans cette direction ou est-ce simplement le fait que nous avons plus de fonctionnalités que nous n'en avions dans 1.x (parce que c'est nouveau et brillant) ?

@davidfowl Je pense que signlarR est une de ces fonctionnalités, cela aurait été au moins dans mon projet précédent. Cependant, je pense aussi qu'une grande partie de l'inquiétude est due aux fenêtres de support relativement courtes pour 1.1 (2018?) Si les gens étaient assurés qu'ils pourraient fonctionner sur asp.net 1.1 jusqu'à ce qu'ils soient prêts à passer au noyau, ce qui signifie potentiellement, des années, et également être couvert pour les patchs qui calmeraient un peu les gens.

Je pense aussi que la prise en charge d'asp.net core 1.1 sur .net core 2.0 vaut encore plus la peine d'être soulignée, cela donne aux gens (ce que je pense) un bon chemin de migration : asp.net 5 sur 46 > asp.net core 1.x sur 46 > asp.net core 1.x sur .net core 2.0 > asp.net core 2 sur .net core 2. Ce serait une voie qui réduirait le risque dont beaucoup de gens s'inquiètent.

Je suis cela depuis le premier jour et même après toutes ces discussions et clarifications (merci @davidfowl ) j'ai l'impression que beaucoup d'entre nous sont jetés sous le bus.

Je comprends le raisonnement pour se détacher du framework .NET complet/desktop. Enfer, je suis même d'accord que c'est la façon d'habiliter ASP.NET, MAIS je ne vois pas comment cela est décidé maintenant plutôt que depuis le début.

Bien sûr, nous, les clients, nous plaindrions sérieusement dans les deux scénarios, mais je préférerais être dans le "Je ne peux pas utiliser le nouveau truc brillant" plutôt que de parier sur "Je peux l'utiliser, investir dans une migration lente et remplacer si possible" et juste découvre que c'est faux.

Je ne vois pas comment cela est décidé maintenant au lieu de depuis le début.

A deviner :

Sur .NET Core 1.x, vous ne pouviez pas exécuter les bibliothèques de framework complètes, cela aurait donc été une rupture complète.

Sur .NET Core 2.x, vous pouvez principalement exécuter le framework complet et exécuter les bibliothèques .NET Standard 1.x - 2.0, ce n'est donc pas une rupture majeure.

Tous les problèmes liés à l'exécution des bibliothèques de framework complètes sur .NET Core 2.0 devraient probablement être classés dans dotnet/corefx

Il est clair que le scénario principal est celui des "applications Web modernes sur le cloud", qui n'ont souvent pas beaucoup de dépendances tierces (ou sont "juste du code").

Jusqu'à présent, la plupart des discussions ont porté sur la disponibilité de BCL, mais beaucoup d'entre nous dépendent de composants tiers (intégration de bas niveau avec des sous-systèmes vidéo, audio complexes, par exemple...) qui sont souvent en retard sur le paysage .NET et presque toujours s'appuyer sur des technologies de niveau inférieur qui ne finissent probablement pas par être prises en charge.

Avec ASP.NET Core 1, nous développons nos services modernes, ciblant la norme .NET pour les bibliothèques et choisissant de déployer sur Full .NET ou .NET Core par dépendances de services.

Je pourrais parier là-dessus car dans le cas de la recherche de fonctionnalités/composants non pris en charge, nous pourrions facilement cibler Full .NET. Et le pari était sur la plate-forme à long terme, car rester sur Full .NET s'annonce comme une décision à éviter dans quelques années.

_Sur .NET Core 2.x, vous pouvez principalement exécuter le framework complet et pouvez exécuter les bibliothèques .NET Standard 1.x - 2.0, donc ce n'est pas une rupture majeure._

@benaadams Il y a une grande différence entre pouvoir utiliser la plupart de la BCL et pouvoir utiliser des bibliothèques qui ont été construites pour Full .NET (et pourraient utiliser en interne des fonctionnalités non prises en charge dans .NET Standard 2.0 / type unification).

Je suppose que cette décision n'a aucun impact sur la facilitation de la migration vers ASP.NET Core 2.0 à partir d'ASP.NET 4 ?
Un certain nombre d'applications que je gère pourraient vraiment bénéficier d'une mise à jour vers ASP.NET Core 2.0, mais comme il n'y a pas de prise en charge OWIN/Katana pour ASP.NET Core, je suppose que je dois migrer manuellement et c'est trop de travail. @damianh a suggéré la même chose dans https://github.com/aspnet/AspNetKatana/issues/27

Nous fonctionnons sur le framework complet car nous avons besoin d'EF6 (pour l'espace) et de services d'annuaire et nous attendons SignalR proprement dit (actuellement en utilisant une version non prise en charge mais cela fonctionne). Je n'ai vérifié aucun autre bloqueur depuis un moment, mais il y en a probablement plus.

Si je comprends bien, nous serons désormais empêchés de passer à asp.net core 2.0 et d'obtenir un signal lors de sa sortie.

Nous avons été de la partie depuis dnx, RC1 à RC2 et project json à csproj et finalement nous avons eu l'impression d'être sortis du bois... maintenant pas tellement.

Je peux comprendre que ce changement arrive éventuellement, mais est-ce vraiment le moment de le faire lorsque le noyau asp.net essaie de gagner du terrain? De plus, mon instinct me dit qu'EF Core n'est pas encore assez mature (et certainement pas pour le spatial) et quiconque parie sur le support dans le noyau prend plus de risques en ce qui concerne le portage des bibliothèques... attendre une autre version pour cette transition semble être cela donnerait une certaine stabilité et une chance pour EF Core et d'autres ports de rattraper sans parler du signal r sur le cadre complet.

Je parie que la plupart de l'entreprise exécute le noyau asp.net (ce qui est génial en passant) sur le cadre complet et pourrait bien être dans une position similaire à la nôtre.

Compte tenu de ce passage au train rapide pour ASP.NET Core, cela signifie-t-il que vous allez introduire une version LTS et actuelle, et quelle sera la durée de prise en charge sur ces instances ?

Je suppose que je suis dans le cas chanceux où je travaille sur une solution greenfield qui n'avait aucune exigence pour fonctionner sur netfx, _mais_ c'était toujours agréable d'avoir si c'était possible. La seule chose qui serait un bloqueur pour moi serait les services Windows que je cible netfx, mais il existe un plan pour cela.

J'ai l'impression que ce changement va dans la mauvaise direction. Je comprends que certaines fonctionnalités sont exclusives jusqu'à ce que netstandard rattrape son retard. Mais emprunter cette voie uniquement centrale est une pente glissante vers la création d'un écosystème fracturé.

Ce changement fait une déclaration que je ne suis pas sûr d'aimer : il n'y a pas de problème à cibler uniquement netcoreapp.

Je voulais aussi écrire mon avis.

Je crois qu'il est trop tôt pour abandonner le framework .net. Je ne sais pas quel est le problème de la prise en charge de .net framework + .net core ensemble, mais je pense que cette décision rendra la migration vers AspNet Core un peu plus difficile. Parce que certaines entreprises pensent que : "Commençons AspNet Core avec .net core.. si nous avons de sérieux problèmes (comme une bibliothèque indispensable qui ne le prend pas en charge à l'avenir), nous pouvons toujours revenir au framework .net". Mais maintenant, cela ne sera plus possible et les entreprises hésiteront à commencer avec AspNet Core. De plus, cette décision peut faire baisser la valeur de .netstandard.

@hikalkan

Parce que certaines entreprises pensent que : "Commençons AspNet Core avec .net core.. si nous avons de sérieux problèmes (comme une bibliothèque indispensable qui ne le prend pas en charge à l'avenir), nous pouvons toujours revenir au framework .net".

Vous pouvez toujours utiliser ASP.NET Core 1.1, n'est-ce pas ?

De plus, cette décision peut faire baisser la valeur de .netstandard.

Je ne vois pas pourquoi ce serait le cas. Comme je l'ai déjà dit, nos bibliothèques transversales ciblent toujours .NET Standard ainsi que les API qui doivent fonctionner sur toutes les implémentations .NET.

Bien sûr, ils peuvent utiliser asp.net core 1.1. Mais ce n'est pas gentil de dire : "La dernière version d'ASP.NET Core est 2.x mais vous devez utiliser ASP.NET Core 1.x si vous voulez cibler le framework .net". Ce n'est pas très différent de dire "utiliser MVC 5.x" :)

Je crois que .net core est l'avenir (pas l'avenir, même c'est maintenant !), mais il est tôt pour abandonner .net framework (cette décision sera comprise par la communauté comme .net framework est obsolète).

Vous pouvez toujours utiliser ASP.NET Core 1.1, n'est-ce pas ?

il n'y a pas d'avantage clair. D'abord il n'est pas encore mûr, donc c'est un pari.
Deuxièmement, les développeurs d'ASP.Net Core ne voudront pas écrire dans d'anciens outils et rester en arrière.
Peu de choses m'intéressent.

1. Nous travaillons déjà sur des projets entièrement nouveaux en ASP.Net Core, Dapper, etc.
   Mais dans d'autres projets, notre logique métier est en 4.6 assemblys. Comme je l'ai lu plus haut, nous ne devrions pas avoir de problème pour les référencer. J'espère que j'ai bien compris.
2. Signal R . DirectoryServices, MS Orléans, Azure.
3. peut-être sans rapport avec la conversation ci-dessus, mais je veux follement héberger localement un ASP.Net Core avec Kestrel ou un autre HttpListener en tant qu'application de bureau UWP ou en tant que pont de bureau dans UWP.

Je dois dire que je suis assez déçu de la communication à ce sujet. Je pense que nous pouvons vivre avec la décision, mais elle est sortie de nulle part.

En juillet, mon équipe commence à travailler sur un nouveau projet de 12 à 18 mois qui s'exécutera sur ASP.NET Core 2.0 avec tous les trucs sympas que nous lisons depuis des années dans .NET Core.

Cependant, en attendant, nous avons une application ASP.NET MVC Core 1.0 qui est le centre de notre produit hérité qui sert essentiellement de wrapper pour appeler les bibliothèques .NET Framework.

J'ai confirmé à l'équipe que leur plan était de mettre à niveau l'application vers ASP.NET MVC Core 2.0 et de l'intégrer à la nouvelle application à mesure que nous échangeons les composants .NET Framework. Maintenant, nous sommes coincés avec ASP.NET MVC Core 1.0 qui sera EOL avant de terminer le projet.

Juste avant de donner mon avis, j'aimerais juste avoir des éclaircissements sur une partie.
Aurais-je raison de supposer que si nous voulons continuer à utiliser ASP.NET Core,
nous ne pourrons pas référencer les dll qui ciblent .Net 4.5 ou supérieur et les faire fonctionner comme ils le font actuellement ?

@louislewis2 Non, ce n'est pas correct. Vous pourrez utiliser les bibliothèques net45 - net461 , tant qu'elles restent dans l'espace d'API pris en charge pendant netstandard2.0 . Vous n'aurez pas besoin de recompiler ces bibliothèques.

@bradwilson Merci pour la clarification. Cela me fera sûrement mieux dormir ce soir.
Beaucoup de bibliothèques ne sont pas sous notre contrôle, cela aurait donc été un énorme problème.

Très soulagé maintenant :)

@shanselman @DamianEdwards @davidfowl Pour votre liste d'éléments que nous utilisons et qui n'ont pas encore été portés, il s'agirait d'éléments de la dll system.management. Nous utilisons spécifiquement les identifiants matériels, ceux-ci sont utilisés pour la génération automatique de liens pour Azure Service Bus et l'ensemble de notre serveur de licences et de notre package client. J'imagine que le fait qu'ils ne soient pas l'API actuellement, nous causerait de sérieux problèmes ?

https://github.com/dotnet/corefx/issues/3324
https://github.com/dotnet/corefx/issues/14762

Il s'agit de notre plus gros blocage qui nous permet d'exécuter quelques-unes de nos applications sur le framework complet.

Cela nous met dans une situation délicate.

Je suis en train de porter nos microservices d'ASP.Net 4.5 auto-hébergé en cours sur Kestrel (pour des raisons de compatibilité héritées), vers ASP.Net Core 1.x entièrement auto-hébergé. Cependant, nous devons exécuter ces choses sur le cadre complet, pour l'instant. Et il y a de bonnes raisons à cela.

Nous avons un certain nombre de dépendances Windows matérielles qui font déjà partie de notre infrastructure et ne sont pas susceptibles de changer. Cela inclut l'authentification NTLM, la journalisation du journal des événements, etc. Le problème est qu'il n'y a pas d'alternative de framework complet activement développée. Katana est mort et lent (par comparaison).

Si quelqu'un pouvait m'indiquer un serveur HTTP aussi rapide que Kestrel pour .Net Framework, alors bien sûr. Mais cela n'existe pas. Je dois donc accepter qu'ASP.Net laisse derrière lui les clients de production réels comme moi avec ce changement.

Si la pile a besoin de tous les nouveaux goodies, comme Pipelines et Span, ceux-ci doivent être fournis en tant que bibliothèques netstandard. Quelles API ASP.Net Core 2.x utilise-t-il qui sont dans netcoreapp2.0 qui ne sont pas dans netstandard2.0, et pourquoi ces API ne peuvent-elles pas être transformées en bibliothèques d'extension netstandard2.0 entre-temps ?

Sommes-nous en train de dire sérieusement que MS a passé 2 ans à travailler sur une norme (net) sur l'ensemble de ses frameworks pour se retourner et sortir un produit phare qui n'utilise pas cette norme ?

Je pense que l'équipe GitHub ajoutera la fonctionnalité Pagination pour la section des problèmes à cause de ce problème.

@mattnischan

Je suis en train de porter nos microservices d'ASP.Net 4.5 auto-hébergé en cours sur Kestrel (pour des raisons de compatibilité héritées), vers ASP.Net Core 1.x entièrement auto-hébergé. Cependant, nous devons exécuter ces choses sur le cadre complet, pour l'instant. Et il y a de bonnes raisons à cela.

Vous pouvez continuer à utiliser ASP.NET Core 1.x, n'est-ce pas ?

Si la pile a besoin de tous les nouveaux goodies, comme Pipelines et Span, ceux-ci doivent être fournis en tant que bibliothèques netstandard. Quelles API ASP.Net Core 2.x utilise-t-il qui sont dans netcoreapp2.0 qui ne sont pas dans netstandard2.0, et pourquoi ces API ne peuvent-elles pas être transformées en bibliothèques d'extension netstandard2.0 entre-temps ?

Lorsque des API apparaissent dans .NET Standard qui ne sont pas dans .NET Framework, comment allez-vous les utiliser ?

@stefan2410

Vous pouvez utiliser ASP.NET Core 1.x pour cela, n'est-ce pas ? De quelles fonctionnalités ASP.NET Core 2.0 avez-vous besoin ? Est-ce juste SignalR ?

Conservez l'application telle quelle pendant les deux prochaines années, mais remplacez les bibliothèques .NET Framework par leur équivalent .NET Core lorsque vous avez terminé. Cela garderait notre logique métier, etc. partagée entre les deux applications.
Nous ne pouvons pas le faire car juillet 2018 est la date limite pour la prise en charge d'ASP.NET MVC Core 1.0.

Encore une fois, dans mon monde hypothétique, nous prolongeons la durée de vie de 1.x

Mettez à niveau l'application vers ASP.NET MVC Core 2.0 et intégrez-la à la nouvelle application lorsque nous remplaçons les composants .NET Framework.
Nous ne pouvons pas le faire non plus, car Core 2.0 ne prend pas en charge le .NET Framework, c'est donc tout ou rien.

Avez-vous réellement besoin d'ASP.NET Core 2.0 ? Ou juste .NET Core 2.0 ?

Lorsque des API apparaissent dans .NET Standard qui ne sont pas dans .NET Framework, comment allez-vous les utiliser ?

Notre plan était : attendre qu'ils soient dedans. Vous avez dit plus tôt que ce n'était qu'une question de temps, n'est-ce pas? Retarder le bord saignant d'un montant fixe pour des raisons de stabilité aurait été bien. Bien mieux que de prendre du retard permanent, du moins.

@davidfowl
Je vais passer en ASP.Net core 2.0. Je n'ai pas d'autre solution. Je ne peux pas dire à l'équipe de rester en retrait de l'évolution, nous avons attendu longtemps l'ASP.Net Core.
Dans la mesure où nous n'avons pas de problèmes avec nos références d'assemblages de logique métier 4.6.
J'ai besoin de SignalR, DirectoryServices, pas de problèmes avec les bibliothèques Azure/Amazon, MS Orleans.
Peut-être aussi que cela n'est pas pertinent avec la conversation ci-dessus, mais je souhaite qu'une application de bureau héberge localement un noyau ASP.Net avec Kestrel / HttpListener en tant qu'application de bureau UWP ou en tant que pont de bureau dans UWP.
Nous ne pouvons pas réécrire le code pour XAML et je ne voudrais pas utiliser Electron.

Vous pouvez continuer à utiliser ASP.NET Core 1.x, n'est-ce pas ?

Pour quelle durée ? Je ne vois pas quelque chose comme Event Log arriver à netstandard.

Lorsque des API apparaissent dans .NET Standard qui ne sont pas dans .NET Framework, comment allez-vous les utiliser ?

Est-ce une chose ? netstandard20 semble toujours fonctionner sur net461 selon la documentation. Êtes-vous en train de dire que l'API sous netstandard20 n'est pas assez complète pour implémenter les nouveaux goodies ? Ou existe-t-il un plan pour déplacer netstandard au-delà du cadre qui n'est pas encore divulgué?

Notre plan était : attendre qu'ils soient dedans. Vous avez dit plus tôt que ce n'était qu'une question de temps, n'est-ce pas? Retarder le bord saignant d'un montant fixe pour des raisons de stabilité aurait été bien. Bien mieux que de prendre du retard permanent, du moins.

Les bibliothèques peuvent être écrites au-dessus de la norme. Lorsque les choses dans la norme elle-même doivent changer, il faudra beaucoup plus de temps pour être adoptées dans toutes les implémentations de .NET et cela inclut .NET Framework. Cela peut signifier plusieurs choses :

• .NET Standard évoluera au rythme de la mise en œuvre la plus lente
• .NET Standard évoluera à un autre rythme et .NET Framework sera le dernier à rattraper son retard.

Bien sûr, cela ne signifie pas que les bibliothèques ne peuvent pas être écrites dessus, cela signifie simplement que ces mises en garde doivent être prises en compte lors du choix de la version de .NET Standard que vous souhaitez prendre en charge.

Peut-être aussi que cela n'est pas pertinent avec la conversation ci-dessus, mais je souhaite qu'une application de bureau héberge localement un noyau ASP.Net avec Kestrel / HttpListener en tant qu'application de bureau UWP ou en tant que pont de bureau dans UWP.

ASP.NET Core sur UWP n'est actuellement sur aucune feuille de route, donc je ne peux pas vraiment dire ce qui va se passer ici. HttpListener fait partie de .NET Standard 2.0, donc il y a peut-être une chance que cela fonctionne.

Je veux prendre un moment pour remercier tout le monde pour leurs commentaires et leurs réactions ici. Nous l'apprécions vraiment ainsi que votre patience pendant que nous découvrons la voie à suivre. Sachez que nous n'avions pas l'intention que ce changement soit si difficile, si tardif et sans avertissement. Le recul est de 20/20 et si nous savions ce que nous savions maintenant, nous aurions communiqué les choses plus tôt. Nous ferons plus d'efforts pour aller de l'avant.

Nous avons un plan basé sur les commentaires que nous avons reçus ici que je souhaite partager avec vous avant de le publier sous forme d'annonce plus tard cette semaine avec la version 2.0.0-preview1. Lorsque cela se produira, nous ouvrirons un nouveau sujet pour faciliter la discussion autour de ce plan, mais pour l'instant, continuez à partager vos réflexions et vos commentaires ici :

• La prise en charge d'ASP.NET Core 1.x sur .NET Framework sera prolongée d' au moins un an (jusqu'en juillet 2019). Nous réévaluerons cela chaque année et nous nous engageons à fournir un préavis de 12 mois avant de mettre fin à la prise en charge d'ASP.NET Core 1.x (donc d'ici juillet 2018, nous annoncerons si nous prolongeons de 12 mois supplémentaires jusqu'en juillet 2020) ( Note latérale : est quelqu'un d'autre a paniqué par le fait que nous parlons déjà de 2020 ? Non ? Ok, juste moi. )
• Le nouveau SignalR ciblera et sera entièrement pris en charge sur ASP.NET Core 1.x (à venir plus tard cette année)
• Nous continuerons à mettre à jour ASP.NET Core 1.x pour prendre en charge les nouvelles versions linguistiques, etc., comme nous le faisons pour System.Web
• ASP.NET Core 1.x exécuté sur .NET Core 1.x sera pris en charge jusqu'en juillet 2018 (pas de changement)
• ASP.NET Core 1.x exécuté sur .NET Core 2+ sera pris en charge tant que ASP.NET Core 1.x sur .NET Framework est pris en charge
  
  
  
  • Cela permet de garantir qu'il y a toujours un chevauchement d'un ASP.NET Core pris en charge sur un .NET Core pris en charge pendant que nous prenons en charge l'exécution sur .NET Framework, permettant aux clients de porter au fil du temps tout en restant sur les bits pris en charge.
  
  
• La prise en charge de .NET Core 1.x (en tant qu'environnement d'exécution) ne change pas. Se termine en juillet 2018. Les clients exécutant ASP.NET Core 1.x doivent passer à .NET Core 2.0 ou être sur .NET Framework à ce stade (ou passer à ASP.NET Core 2.0 sur .NET Core 2.0)
• Nous allons porter System.DirectoryServices et System.Drawing vers .NET Core cette année (entièrement pris en charge, multiplateforme, aperçu pour au moins Windows en été)
• La liste des éléments à porter sur .NET Core après cela inclut actuellement ServiceBase (pour prendre en charge les services Windows .NET Core). Pas encore de chronologie autre que la prochaine (les chronologies deviennent évidemment plus concrètes au fur et à mesure que nous travaillons sur la liste). Nous nous appuierons sur cette liste au fur et à mesure en fonction des commentaires des clients.
• Nous ne prévoyons pas actuellement de porter System.ServiceModel (WCF côté serveur) vers .NET Core. Le WCF pour .NET Core peut continuer à être amélioré et avoir des fonctionnalités ajoutées en fonction des commentaires, par exemple le chiffrement des messages HTTP.

@DamianEdwards @davidfowl une grande partie du problème est que cela peut prendre des mois d'efforts de planification et de développement tout en sacrifiant un énorme coût d'opportunité pour s'engager à passer à ASP.NET Core où de nombreuses organisations ne pourront pas partir. .NET 4.x, car c'est la seule plate-forme dont ils peuvent être assurés qu'ils seront en mesure d'exécuter toutes leurs dépendances système.

Jusqu'à présent, MS a commercialisé .NET Core de manière agressive comme l'avenir d'ASP.NET, où il n'est pas clair si le développement d'ASP.NET 4.x s'est arrêté et si tous les futurs efforts de développement vont être investis dans ASP.NET Core. il va y avoir beaucoup de migrations en cours pour maintenir leurs systèmes à jour. Beaucoup de gens vont avoir l'impression d'avoir été jetés sous un bus si, à la fin de tous leurs efforts, ils ont effectivement migré vers une plate-forme EOL. Cela nuira aux deux organisations ainsi qu'aux développeurs/consultants qui ont été les plus grands champions pour lancer le passage à .NET Core. Ils n'ont peut-être besoin de rien d'ASP.NET Core 2.0 maintenant, mais ils voudront certainement avoir une marge de manœuvre pour leurs systèmes et pouvoir accéder à de nouvelles fonctionnalités pour tous leurs efforts.

Je ne comprends pas non plus pourquoi le code "hérité" existant est considéré comme un handicap alors qu'à l'OMI, il devrait être considéré comme l'un des plus grands atouts de .NET, .NET Core serait loin d'être aussi attrayant s'il n'était pas capable d'exécuter les bibliothèques .NET existantes . Java est toujours aussi fort en raison de l'écosystème massif et stable de JVM, qui est plus important que la faiblesse inhérente au langage lui-même.

Je ne pense pas que MS ait même commencé à ressentir le contrecoup de l'abandon du support .NET 4.x qui ne sera pas largement connu jusqu'à ce qu'il soit annoncé, je m'attends à ce que la plupart des développeurs ici suivant activement le développement sur GitHub soient plus intéressés à voir de nouvelles fonctionnalités alors ils sont en interopérabilité et garantissent un chemin de migration fluide pour les bases de code existantes. Je serais très surpris, mais si vous ne recevez pas de chaleur de cette décision après son annonce, alors ce pourrait être la bonne car peut-être qu'il n'y aura pas beaucoup de gens qui en seront blessés.

Serait-ce trop d'efforts de se concentrer sur une version stable/compatible ASP.NET Core 2.0, puis d'annoncer l'avenir de .NET Core uniquement pour les versions suivantes ? Il semble juste que ce soit la bonne chose à faire dans cette situation étant donné que c'était complètement imprévu.

@DamianEdwards merci pour la mise à jour et un plan clair. Je ne suis pas d'accord avec cela, mais j'apprécie quand même que vous l'exposiez.

Il y a encore un énorme écart fondamental ici. Le port vers 1.x est presque entièrement latéral, il y a peu de fonctionnalités pour nous. 2.x est l'endroit où se trouvent certaines mises à niveau intéressantes et nous n'avons toujours aucune garantie que nous pourrons jamais faire ce mouvement. Il y a de fortes chances que nous consacrions beaucoup de temps, d'argent et d'efforts au portage vers 1.x pour y être bloqués à cause de dépendances complètes du framework. Je ne ferai pas ce pari avec notre société. Nous pourrions bien nous retrouver avec moins de support que nous n'en avons actuellement sur ASP.NET 4.x.

À moins que cela ne change, nos applications ne feront pas le voyage vers ASP.NET Core, et toutes nos bibliothèques seront bien pires faute de dogfooding.

J'espère sincèrement que vous reconsidérerez cette décision. J'espère qu'un jour nous pourrons faire profiter Stack Overflow des milliers d'heures personnelles que nous avons consacrées pour aider à développer la plate-forme .NET Core.

@NickCraver

Il y a de fortes chances que nous consacrions beaucoup de temps, d'argent et d'efforts au portage vers 1.x pour y être bloqués à cause de dépendances complètes du framework.

Tout au long de ce fil, vous avez appelé System.DirectoryServices comme l'un des principaux éléments. Je suppose que vous avez des dépendances qui, selon vous, prendront beaucoup de temps à être portées ou qui ne seront jamais portées. Si 2.0 prenait en charge .NET Framework, ces dépendances se déplaceraient-elles en un an ?

2.x est l'endroit où se trouvent certaines mises à niveau intéressantes et nous n'avons toujours aucune garantie que nous pourrons jamais faire ce mouvement.

Lesquels? Ce serait bon à savoir, car nous discutions du portage de certaines choses de grande importance vers ASP.NET Core 1.1 pour faciliter la transition.

À moins que cela ne change, nos applications ne feront pas le voyage vers ASP.NET Core, et toutes nos bibliothèques seront bien pires faute de dogfooding.

Je ne sais rien sur stackoverflow.com mais est-il possible de casser des morceaux (je ne veux pas dire "micro services") afin que ASP.NET Core puisse être utilisé pour certaines parties?

@mythz

Cela nuira aux deux organisations ainsi qu'aux développeurs/consultants qui ont été les plus grands champions pour lancer le passage à .NET Core

Vouliez-vous dire ASP.NET Core ? Ou .NET Core ?

@davidfowl Je voulais dire ASP.NET Core, mais cela affecte également les développeurs qui prévoyaient une migration par étapes depuis ASP.NET Core/.NET 4.x d'abord, puis .NET Core plus tard.

En parlant de cela, j'ai remarqué qu'il n'y a pas de bibliothèques sur ASP.NET Core/.NET Core pour gérer SAML. J'ai besoin de gérer l'authentification unique via un fournisseur d'identité tiers, mais je ne sais pas si cela sera possible.

@davidfowl Je voulais dire ASP.NET Core, mais cela affecte également les développeurs qui prévoient une migration par étapes depuis ASP.NET Core .NET 4.x d'abord, puis .NET Core plus tard.

Je ne vois pas pourquoi ce serait le cas.

Je pense que ce plan serait probablement suffisant pour que mon organisation évite de quitter la plate-forme. L'essentiel est d'avoir une période plus longue avec le support (= correctifs de sécurité) pendant laquelle les dépôts netfx restants peuvent être réécrits ou autrement éliminés. Cependant, tout cela est encore un peu risqué et conceptuellement bizarre. Que se passe-t-il si, dans trois ans, nous voulons créer un site Web capable d'ingérer des documents Excel ou d'intégrer un serveur Web dans une application ? Qu'arrive-t-il aux autres frameworks comme Orleans qui s'appuient sur la norme au lieu de netcoreapp ?

Je ne comprends vraiment pas pourquoi tant de travail a été fait sur netstandard2.0 si cela n'allait jamais être assez bon pour que ASP.NET Core l'utilise réellement.

Que se passe-t-il si, dans trois ans, nous voulons créer un site Web capable d'ingérer des documents Excel ?

Dur à dire. Je ne peux pas parler pour les équipes qui en sont propriétaires, mais peut-être qu'il sera porté sur .NET Core et fonctionnera sur plusieurs plates-formes.

ou pour intégrer un serveur Web dans une application ?

HttpListener fait partie du netstandard 2.0.

Qu'arrive-t-il aux autres frameworks comme Orleans qui s'appuient sur la norme au lieu de netcoreapp ?

C'est aux frameworks de décider s'ils veulent s'exécuter sur .NET Framework, UWP, .NET Core, mono etc. C'est un choix. Orleans n'est pas livré avec .NET Core. ASP.NET Core le fait. Ces produits sont identiques.

Ce qui sera une décision difficile pour nous (et nos clients) ne concerne pas les bibliothèques que j'ai aujourd'hui, mais les bibliothèques dont je ne sais pas si j'aurai besoin dans 6 mois. Il existe une longue liste de bibliothèques et de frameworks qui ne prennent pas encore en charge netstandard . Par exemple, un mois après un projet, nous avons réalisé que nous avions besoin de quelques fonctionnalités dans NHibernate qui n'étaient même pas proches de là dans EF6, sans parler d'EF Core. Alors, quelle serait mon option là-bas - cibler ASP.NET Core 1.x sur .NET complet ?

On dirait que j'ai un ApiPort dans mon avenir.

Alors, quelle serait mon option là-bas - cibler ASP.NET Core 1.x sur .NET complet ?

Oui.

Dur à dire. Je ne peux pas parler pour les équipes qui en sont propriétaires, mais peut-être qu'il sera porté sur .NET Core et fonctionnera sur plusieurs plates-formes.

D'accord, mais il est sûrement du ressort de l'équipe asp.net de décider s'il vaut la peine de fournir un accès à cet écosystème de bibliothèques peut-être non portées.

D'accord, mais il est sûrement du ressort de l'équipe asp.net de décider s'il vaut la peine de fournir un accès à cet écosystème de bibliothèques peut-être non portées.

.NET est grand et ancien, il est impossible que vous ne vous attendiez pas à ce que l'équipe ASP.NET parle au souffle des bibliothèques qui existent dans l'écosystème .NET. C'est irréaliste. Je viens d'apprendre ce qu'était CSOM (https://msdn.microsoft.com/en-us/library/office/jj163123.aspx) dans le cadre de ce fil et je doute qu'il soit porté mais je ne pourrais pas le dire pour Bien sur.

L'extension de la prise en charge d'ASP.NET 1.1 sur .NET Framework permet d'atténuer un peu cela, mais je pense que cela aide également car certaines dépendances devront être isolées pour passer correctement à ASP.NET Core sur .NET Core (qui est l'avenir prévu).

Je laisserai de côté les bibliothèques car ce point a déjà été longuement discuté. Dans notre cas (amilia.com, e-commerce SaaS), l'outillage tiers est déjà un obstacle, nous ne pouvons même pas exécuter ASP.NET Core sur le framework complet pour le moment. Je reconnais que cela ne semble pas être une raison légitime, mais c'est une contrainte avec laquelle nous devons composer.

Nous pourrions, en théorie, remplacer ces outils (c'est-à-dire les profileurs, la surveillance, les serveurs de construction, etc.) par des alternatives prenant en charge .NET Core, mais c'est quelques mois de travail que je préfère consacrer à la résolution de problèmes plus urgents. Nous effectuerons éventuellement la migration vers ASP.NET Core/.NET Core, mais pour le moment, c'est une cible assez mouvante.

Jusqu'à présent, on s'attendait à ce qu'ASP.NET Core puisse continuer à fonctionner sur le framework de bureau, et donc parler de l'étendue de etc etc. Je ne sais pas quel type de feuilles de thé nous étions censés lire pour savoir que ce n'était pas réaliste :/

Par exemple, pour être clair : l'idée qu'ASP.NET Core ne puisse fonctionner que sur .NET Core n'est pas folle en soi, mais nous n'en avons jamais entendu parler auparavant. Toutes les informations publiques étaient qu'il fonctionnait bien sur .NET Framework et rien n'indiquait que cela pourrait devoir changer.

.NET est grand et ancien, vous ne pouvez pas vous attendre à ce que l'équipe ASP.NET parle au souffle des bibliothèques qui existent dans l'écosystème .NET. C'est irréaliste

N'est-ce pas une bonne raison de continuer à prendre en charge .NET 4.x ? Le fardeau de la compatibilité/interopérabilité peut être contenu dans la plate-forme .NET 4.x qui peut être une solution de travail qui pourrait soulager .NET Core de la nécessité d'interagir avec les anciennes bibliothèques et soulager la pression pour porter les bibliothèques .NET populaires existantes vers .NET Core ( pour MS et auteurs externes).

@mythz

N'est-ce pas une bonne raison de continuer à prendre en charge .NET 4.x ? Le fardeau de la compatibilité/interopérabilité peut être contenu dans la plate-forme .NET 4.x qui peut être une solution de travail qui pourrait soulager .NET Core de la nécessité d'interagir avec les anciennes bibliothèques et soulager la pression pour porter les bibliothèques .NET populaires existantes vers .NET Core ( pour MS et auteurs externes).

C'est pourquoi la durée de vie d'ASP.NET Core sur 1.1 a été prolongée (mais pas de manière permanente). Nous allons nous assurer que SignalR fonctionne car cela a été indiqué comme l'une des principales raisons d'utiliser ASP.NET Core 2.0. En même temps, ce n'est pas là où ASP.NET Core veut être à long terme. L'intention était toujours de livrer dans le cadre d'une plate-forme .NET Core unifiée.

@gulbanana

Jusqu'à présent, on s'attendait à ce qu'ASP.NET Core puisse continuer à fonctionner sur le framework de bureau, et donc parler de l'étendue de etc etc. Je ne sais pas quel type de feuilles de thé nous étions censés lire pour savoir que ce n'était pas réaliste :/

ASP.NET Core sur .NET Framework n'a malheureusement jamais été communiqué comme une solution provisoire pour faciliter le portage (c'est quelque chose que nous avons très mal communiqué). Il n'a jamais été conçu comme une plate-forme prise en charge pour toujours, ce qui est la conclusion logique si vous deviez supposer que certaines dépendances ne seront jamais portées.

C'est pourquoi la durée de vie d'ASP.NET Core sur 1.1 a été prolongée (mais pas de manière permanente).

Le problème est de savoir si cela suffit ou non, la version actuelle a été essentiellement EOL avant même qu'une version compatible/stable n'ait été livrée.

Je ne crois pas que la valeur des investissements existants soit prise en compte, qui va vouloir passer par tous les efforts pour migrer vers une plate-forme EOL ? Les développeurs travailleront indéfiniment sur leurs systèmes brownfield existants, on leur dit essentiellement que leurs compétences ASP.NET v4.x actuelles vont devenir obsolètes et qu'ils ne sont pas en mesure de migrer vers le nouveau modèle de développement ASP.NET Core car . La prise en charge de NET 4.x est abandonnée et il serait irresponsable pour eux d'envisager ou de recommander la migration vers une plate-forme sans issue.

@davidfowl

ASP.NET Core sur .NET Framework n'a malheureusement jamais été communiqué comme une solution provisoire pour faciliter le portage (c'est quelque chose que nous avons très mal communiqué). Il n'a jamais été conçu comme une plate-forme prise en charge pour toujours, ce qui est la conclusion logique si vous deviez supposer que certaines dépendances ne seront jamais portées.

Des erreurs se produisent, c'est bien. Le problème est maintenant que de nombreuses personnes ont fait cette hypothèse et n'utilisent donc ASP.NET Core qu'en raison de leur conclusion logique mais erronée. On verra combien je suppose :/

J'attends asp.net core 2/ .net core 2 si longtemps, mais le résultat est tellement déprimé.

@mythz

Je ne crois pas que la valeur des investissements existants soit prise en compte, qui va vouloir passer par tous les efforts pour migrer vers une plate-forme EOL ?

Le même argument ne peut-il pas être avancé à propos d'ASP.NET Core 2.0 en fin de vie sur .NET Framework l'année prochaine lorsque 3.0 sortira ? Si vous dites qu'un an n'est pas suffisant sur ASP.NET Core 1.1, pourquoi suggérez-vous qu'un an est correct sur ASP.NET Core 2.0 ?

Les développeurs travailleront indéfiniment sur leurs systèmes brownfield existants, on leur dit essentiellement que leurs compétences ASP.NET v4.x actuelles vont devenir obsolètes et qu'ils ne sont pas en mesure de migrer vers le nouveau modèle de développement ASP.NET Core car . La prise en charge de NET 4.x est abandonnée et il serait irresponsable pour eux d'envisager ou de recommander la migration vers une plate-forme sans issue.

Qui a appris que les compétences ASP.NET 4.x allaient devenir obsolètes ? Si quoi que ce soit, nous espérons qu'ils ne le sont pas. MVC en particulier vante la compatibilité du concept avec quelques nouvelles fonctionnalités. ASP.NET Core ressemble beaucoup à Katana (et ce n'est pas par erreur). Si vous parlez de Web Forms, qu'en est-il de MVC ?

Je n'ai aucune expérience dans le conseil, mais je conviens que si les dépendances ne sont pas disponibles, je serais d'accord. Soit cela, soit l'application doit être repensée pour en tenir compte.

@xyting pouvez-vous clarifier?

@davidfowl

Le même argument ne peut-il pas être avancé à propos d'ASP.NET Core 2.0 en fin de vie sur .NET Framework l'année prochaine lorsque 3.0 sortira ? Si vous dites qu'un an n'est pas suffisant sur ASP.NET Core 1.1, pourquoi suggérez-vous qu'un an est correct sur ASP.NET Core 2.0 ?

J'étais sous l'hypothèse de longue date que ASP.NET Core 1.1 n'était qu'une solution palliative à ASP.NET Core 2.0 et .NET Standard 2.0, qui serait la version LTS stable et axée sur la compatibilité qui comblera l'écart avec la plupart des la fonctionnalité de base manquante de .NET 4.x - jusqu'à ce que ce fil détruise essentiellement cette hypothèse. Garder la compatibilité .NET 4.x jusqu'à ASP.NET Core 2.0 n'est pas idéal, mais c'est bien mieux que de le terminer à la version actuelle, ce à quoi personne ne s'attendait.

Qui a appris que les compétences ASP.NET 4.x allaient devenir obsolètes ? Si quoi que ce soit, nous espérons qu'ils ne le sont pas.

MS fait avec tout son marketing agressif sur .NET Core avec toutes les nouvelles annonces et fonctionnalités apparemment axées sur ASP.NET Core. L'ancien ASP.NET WebForms/MVC est-il même développé à l'air libre ? Quelle proportion des efforts de développement est investie sur les anciens WebForms/MVC ASP.NET par rapport à .NET Core ? Je n'en ai aucune idée, tout ce que j'ai vu récemment, tous les standups hebdomadaires, les didacticiels vidéo semblent uniquement axés sur ASP.NET Core. Je sais que je ne me sentirais certainement pas à l'aise pour démarrer de nouveaux projets en utilisant l'ancienne technologie ASP.NET WebForms ou MVC.

Si vous espérez qu'ils ne le sont pas, MS devrait certainement mieux communiquer cela avec des feuilles de route claires. Compte tenu de la volatilité d'ASP.NET au cours des dernières années (ce problème en est un exemple parfait), il est impossible de savoir quel est l'avenir sans un engagement et une annonce officiels.

Quelqu'un d'autre pense-t-il qu'il aurait été préférable que la version 1 ne fonctionne jamais sur le framework complet? Je ne m'y attendais pas à cause du nom. Maintenant que c'est le cas et que j'y ai goûté, je suis déçu de le perdre.

Je comprends d'où vous venez là-dessus, vous voulez itérer toute la pile aussi vite que possible. Vous êtes en concurrence avec tout un tas de frameworks Web de champs verts qui contrôlent l'ensemble de la pile et n'ont aucun bagage à traîner. Laisser tomber les bagages de System.Web est l'une des principales raisons pour lesquelles ASP.NET Core est si excitant.

Après avoir dormi dessus, je peux dire que notre utilisation sera bonne, les dépendances dont nous avons besoin devraient toutes fonctionner sur 2.0.

En même temps, ce n'est pas là où ASP.NET Core veut être à long terme. L'intention était toujours de livrer dans le cadre d'une plate-forme .NET Core unifiée.

Bien qu'il ne faille pas un médium pour comprendre que .NET Core est la plate-forme du futur de .NET... si l'intention depuis le début (ou comme vous le dites "toujours") était de coupler ASP.NET Core avec . NET core, cela n'a certainement été communiqué sur aucun support que j'ai jamais vu.

J'ai littéralement vu chaque minute de chaque stand-up ASP.NET (y compris Hanselman et Glenn dépannant Docker pendant 3 heures... parce que je n'ai pas de vie), je lis les blogs, je suis toujours sur Twitter, je vais sur 2+ conférences par an, assister à des groupes d'utilisateurs, etc. et je n'ai jamais entendu dire que cela était l'intention d'ASP.NET Core. Au lieu de cela, j'ai entendu maintes et maintes fois "il fonctionne sur les deux plates-formes" et, à juste titre, les gens ont l'impression que quelqu'un a retiré la chaise de sous eux. J'ai même donné des conférences sur ASP.NET Core et j'ai dit "il fonctionne sur les deux plates-formes" moi-même, et maintenant je me sens coupable pour tous ceux que j'ai conduits dans cette voie. Je dirais que les gens d'ITT sont probablement à la pointe de la technologie et accepteraient le plus ce genre de nouvelles, et il y a beaucoup de réactions négatives ici. Il semble que cela ne fera qu'empirer au fur et à mesure que cette nouvelle se répercutera sur les développeurs et leurs responsables qui ne sont pas aussi branchés et sont probablement plus conservateurs que ceux d'ITT.

Outre le manque de communication et le manque de support pour certains scénarios, je pense qu'une grande partie du contrecoup est simplement due au moment de cette annonce. .NET Core 2 n'est même pas encore RTM et il a déjà été considéré comme la seule voie à suivre à long terme, et il y a essentiellement eu une bombe à retardement mise sur Full Framework pour ASP.NET Core. Je pense que beaucoup de nos peurs pourraient être dissipées une fois que nous aurons quelque chose de tangible avec lequel jouer en plus des nightlies.

Je pense vraiment qu'il doit y avoir une meilleure expérience d'outillage que "l'exécuter et voir si cela fonctionne" lors de la référence aux bibliothèques net461 + de .NET Core 2+ dans VS, car je peux déjà voir ce message de "nous pouvons probablement exécuter la plupart des vos 461+ assemblages aussi !" sera commercialisé à mort. Quelque chose qui pourrait analyser les API manquantes de ce que nous avons référencé, fournir des erreurs de compilation, idéalement même suggérer des nupkgs compatibles s'ils existent (comme System.Configuration dans l'exemple EF6 ci-dessus... et le faire fonctionner :smile:). De toute évidence, tout ne peut pas être analysé au moment de la compilation (le scénario de transaction distribuée mentionné ci-dessus vient à l'esprit comme quelque chose de difficile à analyser à l'avance), mais plus cela peut être le mieux. Quelque chose comme ce qu'Immo a fait ici pour PlatformNotSupportedException et les API net461 manquantes pour netstandard2 seraient bien.

Juste mes 2 centimes. J'espère que j'exagère juste. En fin de compte, beaucoup d'entre nous sont simplement déçus, car nous aimons ASP.NET Core et nous ne voulons rien qui nous empêche de l'utiliser. ❤️

En joignant ma voix aux préoccupations déjà énumérées, nous lançons un nouveau projet ASP.NET MVC le mois prochain et ce sera simplement .NET Framework avec ASP.NET MVC, car le client ne fait pas confiance à Microsoft pour faire ce qu'il faut en ce qui concerne planification à long terme.

L'organisation cliente utilise toujours des déploiements Windows 7 et ce projet est une exception, car la majorité de leurs projets Web sont en fait réalisés sur UNIX avec Java, .NET étant principalement utilisé sur les applications de bureau.

Ce type d'incertitude ne fait que s'accumuler jusqu'à l'histoire brisée de la pile .NET de Windows 8 et de l'UWP, augmentant l'intérêt du CTO de l'organisation pour rechercher des alternatives plus stables à l'avenir de .NET.

Si vous obligez ce type d'organisations à écrire des modules à partir de zéro pour travailler sur ASP.NET Core, je peux également conseiller à nos clients d'adopter quelque chose avec des feuilles de route plus stables, au lieu de perdre la face sur des problèmes que je ne peux pas contrôler.

@davidfowl Il se peut que ce changement fonctionne bien pour 99% des projets. Mais il a été vendu comme "il fonctionne sur les deux plates-formes" et "vous pouvez l'utiliser avec un framework complet si vous le devez". Tout le monde savait que la version complète du framework du noyau asp.net était destinée aux projets qui ne pouvaient pas migrer, et c'était bien. Et les gens ont planifié dans cet esprit.

Ce changement n'est peut-être pas le pire en termes de code, mais il créera très probablement une énorme tempête de merde lorsque les développeurs les plus réguliers verront les nouvelles. Et il ne s'agira pas du code, il s'agira de ce qui a été promis. Et la promesse était "exécuter net ou core, et netstandard pour les combiner tous".

@DamianEdwards @davidfowl Merci d'avoir partagé le plan.

SignalR sur 1.x est un grand soulagement pour remplacer notre version non prise en charge et aussi la nouvelle que ServiceBase est le prochain sur la liste, car nous l'utilisons également actuellement !

Nous dépendons fortement d'EF6 et de l'espace, nous serons donc bloqués sur 1.x jusqu'à ce qu'il ait l'ensemble de fonctionnalités dont nous avons besoin....

Sur une note semi-amusante cependant, cela peut finalement forcer un déploiement plus microservice pour cela. Je ne serai pas impatient d'expliquer pourquoi nos clients LOB ont besoin d'installer plusieurs API supplémentaires sur IIS pour que nos produits fonctionnent....

Je souhaite vraiment que cela puisse être retenu, car cela semble être trop tôt et, comme plusieurs personnes l'ont mentionné, cela générera un contrecoup important lorsque le billet de blog tombera.

De plus, je dois dire que je me sens un peu vendu sur la rivière alors que depuis le début, le sentiment a été que cela fonctionnera sur le cadre complet et que j'ai prêché la même chose à mes collègues. Explique cependant le choix de dénomination déroutant du noyau asp.net.

@shanselman @davidfowl Mon plus gros problème est NHibernate. Même après la sortie d'EF Core, c'est toujours le seul mappeur O/R complet le plus avancé.

@shanselman @DamianEdwards Je suis en train de commencer à penser à mettre à niveau un site d'ASP.NET MVC 4 vers la dernière version (je ne sais pas si c'est 5 ou un). J'ai encore besoin d'exécuter le framework .net complet car je fais référence à la fois aux bibliothèques SyncFusion et Telerik. SyncFusion pour afficher les fichiers PDF et Telerik pour générer des fichiers word .docx. Comme d'autres l'ont souligné, il n'est tout simplement pas raisonnable que la stratégie de Microsoft pour gérer cela soit "essayez et voyez si cela fonctionne". Je ne peux pas garantir que tout fonctionnera en production, car il s'agit d'une si grande base de code de code tiers.

Alors que le support de SyncFusion est généralement très bon, le support de Telerik ne l'est pas et je serais surpris s'ils peuvent le faire fonctionner avec le noyau .net. Je n'ai aucune idée des Apis qu'ils pourraient utiliser et qui ne sont pas pris en charge dans .net core - et en tant qu'utilisateur final, c'est tout l'intérêt du produit tiers, je le branche simplement et il fait ce qu'il doit faire.

Franchement, pour un client qui ne s'occupe pas très souvent de ce genre de choses (je fais surtout du WPF), tout cela est extrêmement déroutant. Il existe trop de versions différentes, avec diverses incompatibilités. Comme quelqu'un l'a souligné, c'est un peu comme UWP XAML - similaire mais complètement incompatible avec WPF XAML.

Pas bon pour les développeurs et juste une autre chose qui fait que les développeurs perdent confiance en Microsoft (l'un des nombreux au cours des dernières années). Il me semblerait qu'ASP.NET devrait certainement fonctionner sur le framework .net complet, car il existe une si grande bibliothèque d'outils que les utilisateurs peuvent avoir besoin d'utiliser sur leur serveur. Dans mon cas, je peux facilement mettre à jour vers une version ultérieure du framework .net si j'en ai besoin pour utiliser les derniers éléments ASP.net si une mise à jour était nécessaire pour la nouvelle fonctionnalité ASP.net.

Quel que soit le message envoyé aux développeurs, il doit être beaucoup plus clair, avant que les gens ne quittent complètement le navire.

...Stéphane

ASP.NET Core sur .NET Framework n'a malheureusement jamais été communiqué comme une solution provisoire pour faciliter le portage (c'est quelque chose que nous avons très mal communiqué). Il n'a jamais été conçu comme une plate-forme prise en charge pour toujours, ce qui est la conclusion logique si vous deviez supposer que certaines dépendances ne seront jamais portées.

Personnellement, je n'ai pas de problème avec les changements énumérés dans ce numéro, je comprends le raisonnement et ils ont du sens, maintenant que j'ai lu beaucoup de réponses ici. Cependant, ce que vous venez de dire met en évidence ce qui est finalement le nœud du problème - une mauvaise communication de Microsoft dans son ensemble (ce que j'apprécie n'est pas votre faute, ni celle d'un individu _spécifique_).

Peut-être qu'il me manque quelque chose, mais il y a plus à "développer à l'air libre" que d'avoir simplement le code sur github pour que tout le monde puisse le parcourir et jouer avec. Ce problème même a été créé parce qu'un jour un changement est apparu dans le code qui a pris les gens par surprise, mais évidemment vous-même et tous les membres de l'équipe .net le saviez et l'avez compris - donc cela a pris du temps. Le problème est que le reste d'entre nous, simples mortels, en avons été complètement aveuglés.

Pire encore, je soupçonne que la majorité des développeurs ne prêtent pas trop d'attention à github pour obtenir leurs connaissances et leurs informations - donc ce changement va surprendre beaucoup plus de gens que ceux qui commentent déjà ici. J'ai seulement découvert ce problème moi-même parce qu'il est apparu sur mon flux RSS de hackernews - ce qui n'est pas ce que j'appellerais ma principale source d'actualités et d'informations.

Quiconque suit les articles de blog sur MSDN saura que 2.0 arrive et ils le verront comme le Saint Graal de combler le fossé entre le noyau asp.net et tout ce qui "manquait" auparavant, mais ils sont complètement inconscients de ce qui est essentiellement un changement de rupture pour certains flux de travail. Il y a eu très peu de détails sur ce qui se passe réellement avec la conception d'asp.net core 2.0. Je soupçonne que plus de détails viendront plus tard cette semaine à Build? On ne peut qu'espérer.

Le .net slack est une autre ressource d'information, mais c'est un peu bruyant pour être tenu au courant de ce qui se passe réellement. C'est formidable pour l'implication des développeurs et pour poser des questions, mais ce n'est guère une source d'informations.

Twitter et les médias sociaux sont une autre source d'informations, mais encore une fois un peu comme ce problème de github au moment où il apparaît là-bas, c'est généralement parce que quelqu'un a soulevé des inquiétudes concernant une décision qui a déjà été prise et a pris les gens par surprise.

Ce n'est pas non plus la première fois que nous rencontrons ce problème. Vous souvenez-vous du fiasco causé par le retour à csproj ? Je ne veux pas entrer dans les débats sur ce changement, mais c'est un autre exemple d'un changement qui s'est produit à la surprise des gens, qui a été si mal communiqué qu'à ce jour, beaucoup de gens ne réalisent tout simplement pas que ce n'est pas le même csproj du "mauvais vieux temps".

Je ne suis pas tout à fait sûr de ce que j'essaie de suggérer ici, mais il manque définitivement quelque chose dans le développement ouvert de .net. Microsoft fait un excellent travail en fournissant des ressources et de la documentation aux développeurs, mais uniquement pour les produits finis et les éléments livrés. La feuille de route, les réunions de planification, tout ce qui décide de la conception et de la direction des cadres semble se faire à huis clos, avec la mention occasionnelle de "partenaires sélectionnés" et autres. Je ne dis pas que chaque réunion devrait être diffusée en continu et diffusée dans le monde entier, mais il pourrait certainement y avoir un meilleur terrain d'entente où les décisions qui sont prises et les justifications qui les sous-tendent sont communiquées le plus tôt possible à la communauté, d'une manière simple pour ceux d'entre nous qui veulent vraiment suivre pour digérer et garder le contrôle. Peut-être un blog dédié sur MSDN (ou ailleurs) qui est mis à jour régulièrement lorsque ces décisions sont prises.

L'un de mes plus gros problèmes avec cela est que lors de presque toutes les conférences de l'année dernière où ASP.NET Core a été présenté, vous l'avez présenté avec une diapositive qui montre le noyau asp.net fonctionnant à la fois sur le framework .net et le noyau .net, juste jetez un oeil à ceci: Explorez le développement Web avec Microsoft ASP.NET Core 1.0 d'Ignite l'année dernière. Vers 7h50, vous verrez le toboggan.

Les plus gros obstacles pour moi sont System.DirectoryServices, ServiceBase, EF6 (EF Core n'est pas prêt), ClosedXML (pour créer des feuilles Excel).

La prise en charge d'ASP.NET Core 1.x sur .NET Framework sera prolongée d'au moins un an (jusqu'en juillet 2019). Nous réévaluerons cela chaque année et nous nous engageons à fournir un préavis de 12 mois avant de mettre fin à la prise en charge d'ASP.NET Core 1.x (donc d'ici juillet 2018, nous annoncerons si nous prolongeons de 12 mois supplémentaires jusqu'en juillet 2020). quelqu'un d'autre a paniqué par le fait que nous parlons déjà de 2020 ? Non ? Ok, juste moi.)

@DamianEdwards Merci pour l'annonce.

À l'heure actuelle, notre société développe des applications d'entreprise pour plusieurs clients utilisant ASP.NET Core 1.1 sur .NET Framework 4.6.2. Apprendre que la prise en charge de ce combo de framework est pris en charge jusqu'en 2019 au moins, et peut-être prolongé jusqu'en 2020, est un énorme soulagement.

Nous allons porter System.DirectoryServices et System.Drawing vers .NET Core cette année (entièrement pris en charge, multiplateforme, aperçu pour au moins Windows en été)

Ce sont les deux seules raisons pour lesquelles nous ciblons .NET Framework en ce moment. Si ceux-ci sont entièrement portés sur .NET Core 2, je suis sûr que nous pourrons porter nos applications sur ASP.NET Core 2 en toute sécurité l'année prochaine.

On dirait que beaucoup de personnes ont enfreint la règle cardinale d'être un développeur MS - ne vous engagez sur aucun produit/fork avant au moins la V2.

mais oui, parlez d'aliéner vos clients d'entreprise ! la raison pour laquelle ils utilisent MS est pour la rétrocompatibilité.

La majorité des personnes qui exécutent ASP.NET ne se soucient pas s'il fonctionne sous Linux. Et s'ils voyaient un article de blog, avec une comparaison de vitesse avec ASPNET Core, ils ne liraient même pas tous les deux au-delà de la multiplateforme s'ils voyaient qu'il ne prenait pas en charge l'ancien .NET.

les lolcats.

Je pense qu'il est utile d'avoir ASP.NET Core 2.0 entièrement exécuté sur net46x dans le but de donner à beaucoup de gens un chemin de migration fluide vers le nouveau monde. Je pense que beaucoup de gens attendaient ASP.NET Core 2.0 et .NET Core 2.0 dans l'espoir que cela comblera de nombreuses lacunes actuelles et permettra une migration. Si ASP.NET Core 2.0 nécessite que tout soit porté sur netcoreapp2.0, cela représentera un ralentissement massif pour les équipes et compromettra peut-être même la faisabilité.

Cependant, cela ne signifie pas qu'il ne peut pas y avoir d'ASP.NET Core 3.0 peu de temps après, qui ne ciblera que netcoreapp2.0 pour toutes les personnes qui travaillent sur tous les nouveaux éléments brillants et qui veulent être sur la voie rapide.

Avoir deux versions d'ASP.NET Core (2.0 et 3.0) côte à côte pourrait vraiment être une bonne chose (pendant au moins un certain temps). Cela pourrait permettre à MSFT d'éliminer plus rapidement la pile MVC 5 actuelle, car la nouvelle version de MVC serait essentiellement ASP.NET Core MVC 2.0, qui fonctionnerait également sur .NET complet.

Je pense qu'il est utile d'avoir ASP.NET Core 2.0 entièrement exécuté sur net46x dans le but de donner à beaucoup de gens un chemin de migration fluide vers le nouveau monde

Qu'est-ce qui le rendrait plus fluide que le portage depuis ASP.NET Core 1.x ?

Je pense que beaucoup de gens attendaient ASP.NET Core 2.0 et .NET Core 2.0 dans l'espoir que cela comblera de nombreuses lacunes actuelles et permettra une migration.

La majeure partie du travail effectué pour rendre les choses compatibles a été effectuée dans .NET Core 2.0 et .NET Standard 2.0. Honnêtement, ASP.NET Core 2.0 n'a pas beaucoup de nouvelles fonctionnalités. On nous dit que nous allons rétroporter SignalR sur ASP.NET Core 1.x (qui est de toute façon post 2.0). Est-ce juste une question de perception ?

Avoir deux versions d'ASP.NET Core (2.0 et 3.0) côte à côte pourrait vraiment être une bonne chose.

C'est ce que nous faisons avec 1.1 et 2.0 (il suffit d'inverser les chiffres).

Cela pourrait permettre à MSFT d'éliminer plus rapidement la pile MVC 5 actuelle, car la nouvelle version de MVC serait essentiellement ASP.NET Core MVC 2.0, qui fonctionnerait également sur .NET complet.

MVC 5 ne disparaîtra jamais, nous ne déconseillons rien. Il sera pris en charge tant que .NET Framework existera. Vous ne pouvez toujours pas exécuter de projets ASP.NET Core à l'intérieur du pipeline intégré IIS (sur System.Web) et il ne fait pas toutes les mêmes choses que MVC 5 sur System.Web donc ce n'est vraiment pas un remplacement pour certains scénarios .

@davidfowl Pourrai- je créer une application ASP.NET Core 1.x, qui cible .NET complet et netcoreapp2.0 afin que je puisse d'abord migrer une application héritée actuelle vers ASP.NET Core avec toutes les dépendances étant net46x et migrer lentement une dépendance après l'autre pour cibler netstandard2.0 jusqu'à ce que tout soit sur netstandard2.0, ce qui me permettrait alors de mettre à niveau l'application ASP.NET Core 1.x vers 2.x (et de supprimer la cible pour net46x dans le cadre de cela) ?

Si oui, je pense que j'ai mal compris le sujet. Je pense que c'est vraiment ce que la plupart des gens recherchent ici.

@dustinmoris oui, vous pouvez le faire. La principale préoccupation des utilisateurs est de savoir ce qui se passe s'ils ne sont pas migrés vers ASP.NET Core 2.x avant la fin du support sur ASP.NET Core 1.x, s'il leur est possible de migrer.

@alexwiese ah ok c'est super, alors vraiment de quoi discutons-nous ici maintenant ? Plutôt que de discuter du framework à cibler, nous devrions discuter de la période de support d'ASP.NET Core 1.x, ce que MSFT pourrait facilement changer s'il le voulait :)

ÉDITER:
@DamianEdwards a écrit ceci un peu plus haut dans le fil :

La prise en charge d'ASP.NET Core 1.x sur .NET Framework sera prolongée d'au moins un an (jusqu'en juillet 2019). Nous réévaluerons cela chaque année et nous nous engageons à fournir un préavis de 12 mois avant de mettre fin à la prise en charge d'ASP.NET Core 1.x (donc d'ici juillet 2018, nous annoncerons si nous prolongeons de 12 mois supplémentaires jusqu'en juillet 2020). quelqu'un d'autre a paniqué par le fait que nous parlons déjà de 2020 ? Non ? Ok, juste moi.)

Cela me semble bon. Engagez-vous pour une année supplémentaire de soutien, puis réévaluez périodiquement. Ça me parait tout à fait logique.

J'ai lu tous les messages de ce fil. Une question reste sans réponse : pourquoi cette décision est-elle prise ? Je ne peux que conclure qu'il était nécessaire en raison d'un problème technique. Si la "confusion" de la dénomination est le problème, Microsoft devrait embaucher un meilleur responsable des relations publiques et arrêter de remuer la merde comme le fait l'équipe dans ce fil.

Quel est donc le problème technique qui a bloqué ASP.NET core 2.0 sur netstandard2.0 ? Rien n'est impossible dans le domaine des logiciels, il est donc impossible que vous ne puissiez pas trouver une solution qui ne soit pas réalisable sur .NET complet (et ne peut donc pas être incluse dans netstandard20). Oui, cela prend du temps et des efforts, mais j'ai l'impression que vous n'avez pas vraiment réalisé les effets secondaires de cette décision pour vos utilisateurs, quel temps/effort ils doivent investir à cause de cela.

Cette décision a un autre inconvénient : ASP.NET Core n'est pas un consommateur de netstandard et n'en est donc pas un pilote. Cela fait du netstandard un suiveur et comme le noyau ASP.NET n'en dépend pas, un suiveur sans grande signification : l'API de .net core 2.0+ est la surface à cibler, car le noyau ASP.NET cible cette surface, pas netstandard2.0.

Et, désolé @davidfowl , je sais que vous voulez bien dire, mais suggérer ASP.NET core 1.x aux gens encore et encore montre que vous n'avez vraiment aucune idée de la situation pour les personnes à qui vous le suggérez : les gens ne peuvent pas migrer à ASP.NET core 1.x parce qu'ils ne savent pas s'il y a un chemin sans heurts sans délai ferme : il se peut qu'ils aient besoin de rester sur cette plate-forme plus longtemps qu'ils ne le pensent actuellement (les dépendances devaient être portées etc.). Cela seul rend la décision de passer à ASP.NET core 1.x une décision basée sur rien d'autre qu'une « promesse » de Microsoft. C'est une API destinée au code Internet. Ils ont besoin de savoir s'ils peuvent exécuter une application créée aujourd'hui également dans les 3 ans, car Microsoft y corrigera les failles de sécurité (pour donner un exemple).

Franchement, je n'ai pas envie de démarrer un autre chaos cluster au sein de l'écosystème .NET : nous avons besoin de stabilité, de fiabilité, de fiabilité : "mon code écrit aujourd'hui fonctionnera dans 5 ans tel quel". oui, je sais que cela semble idiot pour certaines personnes, mais c'est la réalité : il y a déjà plus de logiciels sur cette planète qu'il n'y a de développeurs pour les maintenir et l'écart ne fait que se creuser. Vous ne pouvez pas simplement supposer qu'une organisation décidera d'utiliser ASP.NET Core comme pile Web et espérer que le code écrit à l'aide de celle-ci fonctionnera dans les 5 ans, les organisations ne le font plus : elles savent qu'il existe des piles qui sont fiable et donnez-leur cela : ils savent qu'ils ne seront peut-être pas en mesure de réécrire l'intégralité de l'application dans ce délai, ils ont donc besoin de cette assurance.

Microsoft a montré avec ce fil et, désolé, leur terrible PR autour de cette question, ils ne peuvent pas donner cette assurance. Et peu importe à quel point vous essaierez de donner une tournure à cela dans les prochains jours à \build, nous, de l'autre côté de la clôture, avons appris que Microsoft Marketing != assure que les choses fonctionneront demain.

@FransBouma Je ne pense pas qu'il y ait eu un problème technique, il semble que la motivation de cibler uniquement netcoreapp2.0 est parce que c'est la seule piste que MSFT peut déplacer aussi rapidement qu'ils le souhaitent, ce qui est bon pour nous après tout, car cela signifie qu'ASP.NET Core 2.x peut se déplacer beaucoup plus rapidement que n'importe quelle autre pile Web dans le monde .NET auparavant. Si vous ne pouvez pas vous engager dans ce train rapide, vous pouvez rester plus longtemps sur ASP.NET Core 1.x (actuellement pris en charge jusqu'en 2019)

@FransBouma comme @davidfowl et @shanselman ont mentionné que de nouvelles API sont ajoutées à un rythme rapide dans .NET Core, et ASP.NET Core 2.x en utilisera certaines, d'où le désir de cibler netcoreapp20. S'ils devaient ajouter ces API à netstandard2x, .NET Framework et d'autres plates-formes devraient rattraper leur retard, et ils sont notoirement lents.

Je vais ajouter ma voix sur le côté C'est une bonne chose du débat. Voici pourquoi:

• L'équipe ne fait pas ça juste pour le plaisir. Il y a toute une série de nouvelles fonctionnalités et optimisations prêtes (ou presque prêtes) à être déployées dans .NET Core qui sont incroyablement utiles pour les personnes qui créent des applications Web modernes, des API et des microservices, et qui attendent que ces fonctionnalités atterrissent dans le Windows .NET Framework complet. retarderait la sortie de plusieurs mois.
• La plupart des plaintes que je vois dans ce fil sont une variante de "Je ne peux pas faire X dans .NET Core 2.0" alors que ce que l'écrivain veut dire est _"Je dois changer la façon dont je fais X dans .NET Core 2.0" _. Oui, il faut changer. Non, ce n'est pas une mauvaise chose. Si vous avez une petite fonctionnalité discrète dans votre application ASP.NET MVC qui fait quelque chose avec des fichiers PDF ou DOCX, et que vous ne pouvez vraiment pas trouver une meilleure façon de faire quoi que ce soit (avez-vous essayé ?), alors cassez ça fonctionnalité dans un microservice s'exécutant sur .NET complet sur Windows Server et appelez-le en tant qu'API HTTP à partir de votre application .NET Core. Décomposer des applications et déplacer des fonctionnalités spécifiques dans de petits services autonomes n'est même pas une solution de contournement, _c'est une bonne pratique à usage général._
  
  
  
  • NB Pour autant que je sache, les packages OpenXML prennent désormais en charge .NET Standard, donc travailler avec Word/Excel/quoi que ce soit ne devrait pas être impossible.
  
  
• .NET Core 2.0 n'est même pas encore en préversion publique appropriée, donc se plaindre qu'il n'a pas de support pour LDAP ou tout ce qui semble prématuré. Si RTM arrive au troisième trimestre et qu'il n'y a toujours aucun moyen d'interagir avec AD ou Kerberos ou quoi que ce soit, alors se plaindre (bien que pensez également à migrer vers des systèmes d'authentification modernes basés sur des jetons, car ce n'est plus 2008).
• Il _y a_ une migration en douceur d'ASP.NET MVC 4.5 vers ASP.NET Core 2.0. Il s'appelle ASP.NET Core 1.0 (et je conviens qu'il devrait y avoir une promesse de support à long terme pour 1.0 dans les circonstances). Vous pouvez créer des applications à l'aide de la version 1.0 et les exécuter sur .NET complet dans un pipeline intégré sous IIS 8.5 sur Windows Server 2012 R2 jusqu'à
  
  
  
  • Le .NET complet rattrape son retard et vous pouvez y exécuter ASP.NET Core 2.x, ou
  
  
  • Quelle que soit la technologie tierce dont vous dépendez, elle prend en charge .NET Core (ou peut être remplacée par une technologie équivalente prenant en charge .NET Core).
  
  
• N'oubliez pas que, bien que votre équipe puisse être paralysée par des dépendances externes ou des politiques ou politiques internes de l'entreprise ou tout simplement par l'inertie, il y a des centaines de milliers, voire des millions, de développeurs dans le monde qui cherchent à créer des applications, des services et des API à l'aide d'applications modernes. modèles architecturaux et nouvelles plates-formes technologiques (cloud/edge/IoT/etc), pour lesquels ASP.NET Core 2.0 convient parfaitement. Ils veulent qu'il soit rapide, évolutif et multiplateforme ; ces choses sont importantes pour beaucoup de gens. Demander à Microsoft d'ignorer ce marché en pleine expansion, simplement parce que votre fournisseur de contrôle tiers ou un projet open source n'a pas encore porté son code, est idiot.

@dustinmoris qui suggère que netstandard n'a pas les API pour créer une pile Web rapide. Si c'est le cas, nous avons tous de plus gros problèmes.

@alexwiese comme je l'ai dit, j'ai lu le fil de discussion complet et donc aussi les messages auxquels vous faites référence. Je sais ce qu'ils disent et je comprends leur point de vue, mais la décision prise montre qu'ils n'ont aucune idée de ce que leurs utilisateurs font avec leur contenu. Je construis moi-même un produit, depuis de nombreuses années maintenant, et je sais qu'au bout d'un moment, vous arrivez à un point où vous voulez couper les choses et aller plus vite, sans la vieille crudité qui est dépassée. Mais faire cela a des conséquences, et une chose que j'ai apprise au cours des 14 dernières années, c'est que la rétrocompatibilité est l'une des plus grandes fonctionnalités qu'un produit logiciel puisse avoir : pouvoir l'utiliser et « ça marche » est un point clé pour beaucoup de gens à décider pour votre plate-forme. Vous pensez peut-être que ce n'est pas si important, et c'est très bien, mais il y a beaucoup de gens qui ne peuvent pas le voir de cette façon car leur réalité est différente.

Ce n'est pas que l'équipe principale d'asp.net ne devrait pas agir rapidement, c'est qu'elle le fait d'une manière qui rompt avec les hypothèses de nombreuses personnes lorsqu'elles sont passées à asp.net core 1.x.

@FransBouma Pourquoi pensez-vous avoir une meilleure idée de ce que les utilisateurs de Microsoft font avec les produits de Microsoft que Microsoft ?

@markrendle

L'équipe ne fait pas ça juste pour le plaisir. Il y a toute une série de nouvelles fonctionnalités et optimisations prêtes (ou presque prêtes) à être déployées dans .NET Core qui sont incroyablement utiles pour les personnes qui créent des applications Web modernes, des API et des microservices, et qui attendent que ces fonctionnalités atterrissent dans le Windows .NET Framework complet. retarderait la sortie de plusieurs mois.

Alors, dites-moi, pourquoi ne pas créer ces API super duper en tant que packages .net standard 2.0 et les publier sur nuget ?

Pourquoi pensez-vous avoir une meilleure idée de ce que les utilisateurs de Microsoft font avec les produits de Microsoft que Microsoft ?

Oh je ne sais pas, en lisant les messages de ce fil?

@FransBouma

cela suggère que netstandard n'a pas les API pour créer une pile Web rapide. Si c'est le cas, nous avons tous de plus gros problèmes.

Je ne pense pas que netstandard manque de quoi que ce soit, car netstandard n'est rien de plus qu'une liste de fonctionnalités qui doivent être implémentées par une plate-forme qui souhaite prendre en charge cette norme. En théorie, nous pouvons déplacer netstandard aussi vite que nous le souhaitons, il suffit d'ajouter plus à la spécification, mais en réalité, il n'est pas possible pour toutes les plates-formes de rattraper ces nouvelles spécifications.

La question est donc de savoir si ASP.NET Core 2.x veut s'engager sur netstandard2.0 (le plus élevé actuellement) et ensuite savoir qu'il est bloqué avec tout ce qui y a été défini, ou ASP.NET Core 2.x uniquement engagez-vous sur netcoreapp2.x, qui peut être bien plus que netstandard2.0. Après un certain temps, je suis sûr qu'il y aura à nouveau un nouveau netstandard (3.x?) Qui rattrapera les nouvelles choses brillantes de netcoreapp, mais cela prendra beaucoup plus de temps et pourquoi TOUS les frameworks asp.net devraient-ils être paralysés pour ralentir la progression . C'est plutôt agréable d'avoir une pile ASP.NET Core très rapide tant qu'il y a aussi une seconde qui donne aux gens un support à plus long terme qui adhère à netstandard.

@FransBouma Oh, désolé, je n'avais pas réalisé que la taille de votre échantillon était si grande. 257 commentaires avec un fort biais envers les personnes qui n'aiment pas la décision ? Difficile d'argumenter avec cela.

AVIS DE NON-RESPONSABILITÉ : Je ne suis pas un expert en Big Data.

@davidfowl :

Tout au long de ce fil, vous avez appelé System.DirectoryServices comme l'un des principaux éléments. Je suppose que vous avez des dépendances qui, selon vous, prendront beaucoup de temps à être portées ou qui ne seront jamais portées. Si 2.0 prenait en charge .NET Framework, ces dépendances se déplaceraient-elles en un an ?

Oui, nous avons d'autres choses. Les services System.Directory sont ce que je signale car même l'espace de noms le plus demandé n'est pas prêt. Tous les autres sont moins bien lotis. L'analyseur de portabilité de l'API n'est même pas mis à jour pour VS 2017 où nous pouvons l'exécuter. L'analyseur pour voir si vous pouvez même porter n'a pas été investi et nous abandonnons déjà le support.

Lesquels?

Les pages de rasoir sont énormes, je l'ai mentionné plusieurs fois.

Je ne sais rien sur stackoverflow.com mais est-il possible de casser des morceaux (je ne veux pas dire "micro services") afin que ASP.NET Core puisse être utilisé pour certaines parties?

Non, ce n'est pas vraiment possible. Nous ne rendons pas en 18 ms en effectuant des appels d'API et en ajoutant une surcharge entre les éléments. Je suis heureux de revenir sur l'architecture à tout moment, vous verrez que ce n'est pas vraiment une voie raisonnable.

Je pensais l'avoir expliqué plus tôt mais le revoilà :

Toute API faisant partie de netstandard qui doit évoluer évoluera lentement. Les choses peuvent être construites sur netstandard et peuvent fonctionner n'importe où, et c'est très bien. Au moment où vous avez besoin d'une nouvelle API sur, par exemple, un client http, ou SSL Stream, ou Int, ou String, ou Array, ou LINQ ou l'une des primitives qui existent dans NET Standard, une nouvelle version .NET Standard doit être créée et les implémentations doivent convenir qu'ils le mettront en œuvre. Ce n'est pas la fin du monde car nous possédons la plupart d'entre eux maintenant, mono, .NET Core, .NET Framework, UWP mais il y en a d'autres comme Unity (et probablement d'autres). Chaque vertical .NET a son propre calendrier et son propre cycle de livraison, ils sont chacun leurs propres produits distincts et cela ne peut être ignoré.

Mais maintenant vous avez l'idée, une nouvelle version de netstandard est créée lorsque de nouvelles API sont mises en ligne. Si les bibliothèques veulent utiliser ces nouvelles API, vous perdez immédiatement le souffle du support de toutes les plates-formes. Vous pouvez croiser la compilation et essayer de polyfill mais cela ne s'adapte pas à tous les changements.

J'espère que cela vous donne une idée de ce à quoi pourrait ressembler le processus d'amener les API à netstandard. @terrajobst aurait une meilleure idée de ce qu'est le plan.

@DamianEdwards et @shanselman Qu'en est-il de Service Fabric et des tests unitaires ?

Dans notre cas, nous avons un gros projet de micro-service avec de nombreuses applications SF qui sont des projets principaux mais utilisent .Net Framework 4.5 à 4.6. (quelque chose). SF ne prend actuellement pas en charge netcoreapp, nous avons donc dû utiliser .Net Framework, mais comme nous ne voulions pas prendre de retard, nous avons utilisé le projet .Net Core.

(un autre problème est) Parce que nos services sont .Net Framework et MS Fakes ne sont pas disponibles pour netcoreapp, tous nos tests unitaires sont des projets .Net Framework normaux (ou devrais-je dire hérités). Presque toutes nos librairies sont sur netstandard 1.0 à 1.6.

Encore une fois, nos applications clientes utilisent Xamarin Forms + UWP et nous avons réussi à utiliser netstandard afin que nos bibliothèques soient compatibles.

Cela signifie-t-il que nous sommes bloqués et que nous ne pourrons pas passer à .Net Core 2.0, netcoreapp2.0 et netstandard 2.0 ?

@NickCraver

Les pages de rasoir sont énormes, je l'ai mentionné plusieurs fois.

Je comprends celui-ci, mais je ne peux pas croire que vous allez convertir tout le débordement de pile en pages de rasoir uniquement. Si vous utilisez déjà MVC aujourd'hui, pourquoi ne pas simplement transférer vers des vues régulières et lorsque davantage de dépendances sont en ligne, transférez vers des pages de rasoir. La façon dont les pages de rasoir sont conçues rend trivial le passage d'une action de contrôleur à une page de rasoir.

Oui, nous avons d'autres choses. Les services System.Directory sont ce que je signale car même l'espace de noms le plus demandé n'est pas prêt. Tous les autres sont moins bien lotis. L'analyseur de portabilité de l'API n'est même pas mis à jour pour VS 2017 où nous pouvons l'exécuter. L'analyseur pour voir si vous pouvez même porter n'a pas été investi et nous abandonnons déjà le support.

Assurez-vous simplement d'augmenter cette liste de dépendances afin que nous sachions ce qui est important.

@un Boo

Cela signifie-t-il que nous sommes bloqués et que nous ne pourrons pas passer à .Net Core 2.0, netcoreapp2.0 et netstandard 2.0 ?

Vous vouliez dire ASP.NET Core 2.0 et ? .NET Core 2.0 et .NET Standard 2.0 ne s'appliquent pas vraiment ici.

Oui, vous devrez rester sur ASP.NET Core 1.x.

La majeure partie du travail effectué pour rendre les choses compatibles a été effectuée dans .NET Core 2.0 et .NET Standard 2.0. Honnêtement, ASP.NET Core 2.0 n'a pas beaucoup de nouvelles fonctionnalités. On nous dit que nous allons rétroporter SignalR sur ASP.NET Core 1.x (qui est de toute façon post 2.0). Est-ce juste une question de perception ?

@davidfowl Je pense que vous sous-estimez massivement la peur qui frappe le cœur d'un développeur Windows lorsqu'on vous dit que vous allez devoir migrer des choses. _Surtout_ lorsque la nouvelle pile n'a pas atteint la parité des fonctionnalités avec l'ancienne pile, et on ne sait pas si et quand cela se produira. Il s'agit essentiellement d'annoncer la fin de vie d'ASP.NET Core sur le .NET Framework complet. Et, même si ce n'était probablement pas le plan à long terme, cela a été annoncé comme une fonctionnalité, et les gens pensaient que cela pourrait durer un certain temps. Les feuilles de route changent au moment où nous parlons. Des rencontres auront lieu.

Nous avons des choses horriblement anciennes que nous devons prendre en charge à cause des connecteurs de base de données et des SDK nominalement maintenus. Certains de ces fournisseurs sont beaucoup plus susceptibles de publier une nouvelle API massacrée avec 30 % de fonctionnalités existantes, une interface HTML5 et une nouvelle série de bogues qu'ils ne le sont pour maintenir leurs produits existants. Ou ils pourraient simplement acquérir un concurrent, lancer le produit et le terminer rapidement. Certains de ces fournisseurs sont suffisamment importants pour être reconnaissables. Nous avons beaucoup de bon code, mais une partie de ce code vit également dans les bidonvilles de Windows malgré tous nos efforts car il n'est pas toujours sous notre contrôle. La vieille technologie ne se contente pas de prendre sa retraite avec grâce. Il se cache sous votre lit, dans notre placard et sous votre clavier.

Je suis plus préoccupé par ce mouvement signalant la possible mise à l'écart de .NET Standard que par le reste. .NET Standard semblait initialement être quelque chose qui rapprocherait de plus en plus les différentes implémentations de la parité des fonctionnalités tout en permettant aux consommateurs de migrer vers la plate-forme en évolution et en pleine croissance. Maintenant, cela ressemble à rien de plus qu'une étape importante des fonctionnalités .NET Core. Vous ne pourrez pas (ou ne voudrez pas) cibler les exécutables vers .NET Standard - uniquement les bibliothèques. Et il semble qu'il y aura beaucoup moins de planification impliquée dans .NET Standard, et à la place, il sera simplement approuvé avec tout ce qui a été utilisé dans ASP.NET car il est déjà trop tard pour changer. Ce sera déjà en production, après tout.

D'autres développeurs doivent saupoudrer le code de directives de compilateur, diviser le code en bibliothèques spécifiques à la plate-forme et compiler avec plusieurs cibles. La partie impolie de moi veut que l'équipe ASP.NET Core s'occupe de cela afin que vous soyez intéressé par une meilleure prise en charge de l'exécution et des outils pour les scénarios multi-ciblage et multi-plateforme. Et si votre équipe le veut, nous pourrions l'obtenir. La partie pratique de moi dit qu'au minimum, vous devriez avoir des versions périodiques d'ASP.NET Core qui ciblent la norme .NET. Vous devez de toute façon créer des versions _stables_ réelles. Personne ne va simplement compiler la branche principale de git et la déployer en production. Pourquoi ne pas faire des itérations plus petites du standard .NET et les faire correspondre avec une version ASP.NET balisée ?

De plus, y aura-t-il un nouvel ASP.NET pour le bureau ? Toute la fanfare donnait l'impression qu'ASP.NET Core était le seul ASP.NET. Maintenant, il semble que vous n'obtiendrez rien de nouveau sur ASP.NET à moins que vous ne soyez sur .NET Core. Et cela va changer beaucoup de stratégies commerciales. Il y a beaucoup de confusion avec les feuilles de route.

MVC 5 ne disparaîtra jamais, nous ne déconseillons rien. Il sera pris en charge tant que .NET Framework existera.

Oui, nous sommes tout à fait conscients que les vieux trucs y resteront. C'est généralement le cas, et nous l'apprécions. Mais la question de savoir si de nouvelles choses entreront dans le cadre "complet" est très importante. Nous devons savoir où vont les choses. Nous ne voulons pas prendre le train jusqu'au bout et seulement ensuite réfléchir à la façon d'aller de l'avant. Nous devons également nous soucier de nos passagers. Et la disparité entre .NET Core et .NET Framework laisse beaucoup de gens incertains quant à l'avenir. Il y a un an et demi, j'ai posé une question sur le moment où une partie particulière de la fonctionnalité allait être prise en charge dans .NET Core. J'ai même demandé s'il serait accepté si j'y travaillais personnellement. La communication a été rare. Je n'ai toujours aucune idée de ce qui va lui arriver. Ce type d'incertitude sur les scénarios et les délais pris en charge fait une énorme différence dans le code que nous écrivons. Même en sachant quelles sections de l'infrastructure de bureau sont de faible priorité, les utilisateurs auraient amplement le temps de migrer au lieu d'attendre les mises à jour de statut.

En bref, je soutiens ce que vous faites et les objectifs qui le sous-tendent. Et je sais que c'est dur quand on arrive ici et qu'on se plaint de décisions que tu as prises pour une très bonne raison. Mais beaucoup de gens ne vont pas sauter dans le train des pionniers parce qu'ils ne le peuvent pas, et d'autres ne le feront pas parce qu'ils ne savent pas où il va.

@davidfowl je suppose. Comment appelle-t-on un projet principal (nouveau) avec .Net Framework ? Quoi qu'il en soit, d'après ce que j'ai compris, le netstandard vNext ne le supportera pas.

@markrendle Nous sommes de vrais clients. Nous disons aux gens que les choses ne fonctionneront pas. Je connais mon architecture mieux que vous, donc les commentaires arrogants n'aident pas. A vos points :

L'équipe ne fait pas ça juste pour le plaisir. Il y a toute une série de nouvelles fonctionnalités et optimisations prêtes (ou presque prêtes) à être déployées dans .NET Core qui sont incroyablement utiles pour les personnes qui créent des applications Web modernes, des API et des microservices, et qui attendent que ces fonctionnalités atterrissent dans le Windows .NET Framework complet. retarderait la sortie de plusieurs mois.

Personne n'est contre qu'ils soutiennent également ces choses. Nos plaintes concernent universellement la suppression du support, et non l'ajout conditionnel de nouvelles fonctionnalités.

La plupart des plaintes que je vois dans ce fil sont une variante de "Je ne peux pas faire X dans .NET Core 2.0" alors que ce que l'écrivain veut dire est "Je dois changer la façon dont je fais X dans .NET Core 2.0". Oui, il faut changer. Non, ce n'est pas une mauvaise chose. Si vous avez une petite fonctionnalité discrète dans votre application ASP.NET MVC qui fait quelque chose avec des fichiers PDF ou DOCX, et que vous ne pouvez vraiment pas trouver une meilleure façon de faire quoi que ce soit (avez-vous essayé ?), alors cassez ça fonctionnalité dans un microservice s'exécutant sur .NET complet sur Windows Server et appelez-le en tant qu'API HTTP à partir de votre application .NET Core. Décomposer des applications et déplacer des fonctionnalités spécifiques dans de petits services autonomes n'est même pas une solution de contournement, c'est une bonne pratique à usage général.

C'est tellement loin de la base que je ne sais pas par où commencer. Nos pages seraient beaucoup plus lentes et plus chères en "micro-services". Nous prendrions beaucoup plus de temps dans GC que dans les rendus de page avec une telle configuration. Cela suppose également que la dépendance complète du framework n'est pas une partie essentielle de chaque rendu de page. Mauvaise hypothèse.

.NET Core 2.0 n'est même pas encore en préversion publique appropriée, donc se plaindre qu'il n'a pas de support pour LDAP ou tout ce qui semble prématuré. Si RTM arrive au troisième trimestre et qu'il n'y a toujours aucun moyen d'interagir avec AD ou Kerberos ou quoi que ce soit, alors se plaindre (bien que pensez également à migrer vers des systèmes d'authentification modernes basés sur des jetons, car ce n'est plus 2008).

On nous a dit qu'ils ne seraient pas là. Regardez le stand-up. Ou regardez GitHub où il est étiqueté "Future". Nous nous plaignons maintenant parce que cette mauvaise décision aura été expédiée au troisième trimestre.

Il y a une migration en douceur d'ASP.NET MVC 4.5 vers ASP.NET Core 2.0. Il s'appelle ASP.NET Core 1.0 (et je conviens qu'il devrait y avoir une promesse de support à long terme pour 1.0 dans les circonstances).

Un soutien à long terme ne signifie pas que ce n'est pas une impasse. Nous pouvons encore facilement être bloqués sur 1.x lorsqu'il arrive en fin de vie. Dans ce cas, nous aurions eu un support plus long sur le cadre complet.

Le .NET complet rattrape son retard et vous pouvez y exécuter ASP.NET Core 2.x

Il cible netcoreapp , cela n'arrivera pas.

... ou Quelle que soit la technologie tierce dont vous dépendez, elle prend en charge .NET Core (ou peut être remplacée par une technologie équivalente prenant en charge .NET Core).

Ces bibliothèques échappent souvent au contrôle et au budget temps des gens. Même les bibliothèques de Microsoft ne sont pas mises à niveau . Je me bats actuellement avec l'équipe SQL pour mettre à niveau leurs packages afin qu'ils fonctionnent sur le nouveau système de projet car install.ps1 fonctionne. Si nous ne pouvons même pas obtenir ces correctifs simples, nous sommes foutus avec des ports netstandard .

N'oubliez pas que, bien que votre équipe puisse être paralysée par des dépendances externes ou des politiques ou politiques internes de l'entreprise ou tout simplement par l'inertie, il y a des centaines de milliers, voire des millions, de développeurs dans le monde qui cherchent à créer des applications, des services et des API à l'aide d'applications modernes. modèles architecturaux et nouvelles plates-formes technologiques (cloud/edge/IoT/etc), pour lesquels ASP.NET Core 2.0 convient parfaitement. Ils veulent qu'il soit rapide, évolutif et multiplateforme ; ces choses sont importantes pour beaucoup de gens. Demander à Microsoft d'ignorer ce marché en pleine expansion, simplement parce que votre fournisseur de contrôle tiers ou un projet open source n'a pas encore porté son code, est idiot.

Dire que c'est idiot est rabaissant, grossier et déplacé. C'est notre vie. Ce sont nos applications. Ce sont les choses que nous avons passé des années ou des décennies à créer et tout à coup, avant la sortie, nous découvrons que les perspectives sont limitées dans le temps pour nous, dur. Beaucoup d'incertitudes sont introduites, c'est le moins qu'on puisse dire. Ce n'est pas vraiment quelque chose que vous voulez dans votre carrière.

chaque point a un sens, mais rappelez-vous que dans cet univers tout ira dans l'état qui demande le moins d'énergie, alors assurez-vous que cet état est celui où vous voulez aller, car nous y irons d'une manière ou d'une autre.
Donc, si vous voulez atteindre un certain état, assurez-vous qu'il nécessite moins d'énergie que celle nécessaire pour rester là où nous sommes maintenant.

Je viens de lire tout ce fil après que quelqu'un l'ait mentionné comme un aparté dans IRC - je n'ai pas encore vu d'annonce officielle à ce sujet - et je suis profondément déçu.

J'ai regardé .NET Core, je m'implique et je convertis de petits projets de .NET Framework à .NET Standard / .NET Core afin d'acquérir une certaine expérience avec le nouveau SDK et le runtime, et d'exécuter ces projets sur macOS et Linux .

Ma grande cible est un service Web de grande entreprise qui utilise un tas de composants qui ne sont pas [encore] disponibles dans .NET Core 1.0 ou 1.1. Cela inclut, juste au dessus de ma tête:

• Active Directory ( System.DirectoryServices ), utilisé pour l'authentification et la gestion des utilisateurs
• Entity Framework 6 ( EntityFramework ), car EF Core ne prend pas encore en charge la plupart des fonctions que nous utilisons.
• OData ( Microsoft.Data.Services / System.Data.Services ) v1-3, la bibliothèque client Javascript que nous utilisons ne supporte pas (encore) la v4 et WebAPI OData est beaucoup plus complexe à mettre en place.
• IIS Management ( System.Web.Management ) et .NET Remoting ( System.Runtime.Remoting ) pour la capacité du service Web à se mettre à niveau - bien que cela puisse être extrait vers une application autonome.
• Signal R
• IHttpHandler s et IHttpModule s personnalisés, qui devraient être adaptés à l'équivalent d'ASP.NET Core, probablement une sorte de middleware
• Tout un tas de choses personnalisées utilisant l'extensibilité d'ASP.NET WebAPI.
• Je pense que nous pourrions même utiliser Microsoft.TeamFoundationServer.ExtendedClient sur le serveur, qui ne prend en charge que net46, possède des assemblages natifs et a environ 0% de chances de fonctionner sur .NET Core 2.0.
• etc.

En raison de la taille et de la complexité de ce service, toute migration vers .NET Core devrait être progressive et, selon toute vraisemblance, nous devrons peut-être utiliser de nouvelles API ASP.NET-Core-2.0, je ne sais pas pourtant, nous ne sommes pas allés aussi loin.

La suppression de la possibilité d'exécuter ASP.NET Core sur le .NET Framework signifie que les migrations doivent être effectuées à grande échelle si ASP.NET Core 1.x n'est pas un tremplin viable. Nous perdons instantanément l'étape de "exécuter un nouveau framework sur un ancien runtime" avant "exécuter un nouveau framework sur un nouveau runtime". Il s'agit d'une stratégie de gestion du changement horrible pour tout grand système.

Cela ne me dérangerait pas tellement si la prise en charge de .NET Framework était abandonnée une fois que .NET Core était à ou proche de la parité, mais il est encore assez loin derrière pour toute application suffisamment avancée, et je ne pense pas que 2.0 soit le bon endroit pour faire un tel un changement de rupture.

@davidfowl

Je comprends celui-ci, mais je ne peux pas croire que vous allez convertir tout le débordement de pile en pages de rasoir uniquement. Si vous utilisez déjà MVC aujourd'hui, pourquoi ne pas simplement transférer vers des vues régulières et lorsque davantage de dépendances sont en ligne, transférez vers des pages de rasoir. La façon dont les pages de rasoir sont conçues rend trivial le passage d'une action de contrôleur à une page de rasoir.

De nombreuses bibliothèques, etc. partagées entre les applications sont en jeu ici. Stack Overflow est composé de nombreuses applications (le site Web principal est presque entièrement une seule application, mais en tant qu'entreprise : nous avons de nombreuses choses liées et communicantes.

Assurez-vous simplement d'augmenter cette liste de dépendances afin que nous sachions ce qui est important.

Ouais, je fais ça. Mais ce ne sera pas la dernière dépendance, juste le plus gros bloqueur puisque nous ne pouvons même pas nous connecter à certaines applications sans cela. C'est un briseur de premier écran. Je vais essayer de faire l'analyseur de portabilité complet sur nos applications cette semaine (après un lancement ce matin), mais je crains que ce ne soit plus déprimant. Cela aiderait si l'analyseur était même mis à jour pour l'outillage actuel avant que des mouvements comme celui-ci ne soient même envisagés.

Les données aident, je vais essayer d'obtenir plus de données - à moins qu'il n'y ait aucune chance que cette décision change. Si c'est le cas, merci de nous le dire pour que je n'y investisse plus de mon temps.

Juste pour mémoire : OData est une autre bibliothèque qui ne prend pas encore en charge netcoreapp.

En fait, il est même toujours basé sur System.Web (vous devez l'utiliser via le middleware OWIN dans ASP.NET Core) et ils ont promis un support (voir https://github.com/OData/WebApi/issues/939).

Cela vaut toujours la peine d'être mentionné. Surtout qu'il vient de Microsoft.

EDIT: @yaakov-h était 2 min plus rapide, donc +1 pour sa mention d'OData

Je suis toujours là pour répondre pour plusieurs raisons

• ça me tient à cœur
• Le sommeil est pour les faibles 😆
• Je dois appeler le FUD parce que quelqu'un sur Internet se trompe

@NickCraver

De nombreuses bibliothèques, etc. partagées entre les applications sont en jeu ici. Stack Overflow est composé de nombreuses applications (le site Web principal est presque entièrement une seule application, mais en tant qu'entreprise : nous avons de nombreuses choses liées et communicantes.

Cela signifie simplement que vous ne pouvez pas utiliser les pages Razor, ASP.NET Core 2.0 a beaucoup de petites choses, mais il n'y a pas de grandes fonctionnalités ou de correctifs qui ne sont pas également rétroportés vers 1.x. La chose EOL est très réelle et personnellement, je ne pense pas que ASP.NET Core 2.0 prenant en charge .NET Framework pendant une autre année aiderait. Nous discutons vraiment d'un changement de direction ici, soit nous prenons en charge .NET Framework pour toujours, soit non, il n'y a vraiment pas d'intermédiaire.

@dustinmoris n'est pas que ça. est aussi un problème d'attentes. Votre cas d'utilisation peut ne pas être le même que tout le monde.

Je développe des applications aspnetcore 1.* et j'utilise le bureau .NET comme environnement d'exécution (LOB pour l'entreprise).

Et je comprends quelle est la différence entre .net core runtime, netstandard, etc. (juste pour être sûr que ce n'est pas un commentaire sur un malentendu à ce sujet)

Ma migration a d'abord été vers le noyau aspnet (ciblant le bureau .net) car le flux/vision/etc, le consolider, et APRÈS le déplacer vers le noyau .net (si possible), était le scénario décisif dans le choix aspnetcore.

Ce problème est juste un peu inattendu, car aspnetcore 1.* a toujours été commercialisé comme "exécuté sur les deux frameworks", sans aucun avertissement concernant sa prochaine suppression (version ou année).
Je m'attendais à un cycle obsolète -> obsolète au moins, ou simplement à des fonctionnalités non prises en charge (c'est ok).

La bonne partie de .net (et aspnet comme choix pour la pile Web) est que je peux tirer parti de la base de code et des bibliothèques existantes.
Certains sont internes, pas de réel retour sur investissement pour les migrer, lorsque la cible (.net core/netstandard) est trop fluide.
Certains sont externes et difficiles à modifier. Si ceux-ci ne fonctionnent pas dans la fermeture netcoreapp2, je ne peux pas les utiliser.

De plus, mon idée était de consolider netstandard2 non netcoreapp2 .
Comment puis-je commencer à évaluer la migration de libs vers netstandard2, si ce n'est pas encore le cas ? Est difficile d'évaluer la migration sur la base des éléments de prévisualisation et des promesses (et les dernières années ont réduit ma confiance dans la stabilité des promesses)

Je comprends que c'est un scénario différent de entièrement greenfield, mais aussi si greenfield j'aimerais réutiliser certaines bibliothèques, car j'ai besoin d'interagir avec le système existant (excel/pdf/etc), pas de tout réécrire à partir de zéro.
Ou ajoutez des microservices en tant que rpc simplement parce que c'est la dernière tendance, parce que cela rend les choses plus compliquées (c'est un choix judicieux que je veux évaluer et faire, ne pas être obligé d'envelopper les bibliothèques existantes). J'ai besoin de fournir de la valeur (le flux de développement aspnetcore est agréable et productif), pas seulement de changer d'architecture.

Dans mon évaluation personnelle de l'écosystème, pour mon cas d'utilisation, la disponibilité du noyau .net et/ou de la bibliothèque netstandard est atm trop faible (tout le monde n'utilise pas uniquement les paquets gratuits nuget.org oss). Donc, si j'ai besoin de migrer vers une nouvelle pile, je dois également évaluer d'autres piles (coût/bénéfice/avenir/confiance/etc)

Je n'écris pas seulement une application Web TODO, j'utilise .NET parce que j'ai des années de choses prêtes, donc je peux changer une chose (dans ce cas aspnetcore, et laisser le reste tel quel pour cette itération).
Tout changer est une recette pour un désastre dans mon scénario, et quand je dois le faire, je dois vraiment commencer à évaluer s'il est plus logique de migrer vers une autre pile (comme java/node) où lib existe.

Une migration en douceur prend du temps, j'aime la vision du futur noyau aspnet. mais si je n'ai pas de chemin clair (ou si je doute à ce sujet), c'est difficile à vendre en interne.

Cela dit, laissez derrière vous le bureau .net, peut être un bon pari pour l'équipe aspnet d'aller plus vite et de choisir plus de nouveaux utilisateurs (ou de ne pas perdre de courant vers node/java).
Mais à coup sûr, cela va compliquer la vie des développeurs sur un anneau plus lent, et c'est l'appel de l'équipe aspnet (leur produit).
Mon avis est de ne pas faire cela et de travailler dur pour prendre en charge fw, car en tant que développeur, j'ai besoin de confiance et de stabilité, et les dernières années étaient un peu trop fluides dans l'écosystème .net (pas seulement netcore/project.json, mais avant aussi, et le marketing/évangéliste n'a pas aidé à réduire la confiance)

@yaakov-h

Si vous décidez de porter vers ASP.NET Core (1.x ou 2.x), vous aurez besoin d'un autre processus. ASP.NET Core ne s'exécute pas sur System.Web, vous ne pouvez donc pas effectuer de port progressif dans le même projet.

Cela ne me dérangerait pas tellement si la prise en charge de .NET Framework était abandonnée une fois que .NET Core était à ou proche de la parité, mais il est encore assez loin derrière pour toute application suffisamment avancée, et je ne pense pas que 2.0 soit le bon endroit pour faire un tel un changement de rupture.

Il n'y a pas de bon moment pour le laisser tomber. Il n'a jamais été conçu pour atteindre la parité avec .NET Framework et il est tout à fait possible que vous ayez des dépendances qui ne seront jamais portées. Compte tenu de cela, ma question serait la suivante : reconcevez-vous l'application ou avez-vous réellement besoin de rester sur .NET Framework pour toujours ?

@davidfowl qui dépend entièrement de nos dépendances en amont. À ce stade, nous resterions sur .NET Framework pour toujours.

Il est intéressant de noter que la plupart des versions tierces ont déjà des versions netstandard disponibles. Ce sont en grande partie les dépendances Microsoft qui nous maintiennent sur .NET Framework, et certaines d'entre elles semblent être semi-abandonnées (par exemple OData)

@NickCraver Je ne veux pas être rabaissant ou insultant. Je comprends qu'il s'agit d'un changement tardif, et c'est frustrant pour toute partie de la communauté qui en est affectée, et si j'étais affecté par cela, je ferais probablement des histoires aussi. Je ne le suis pas (où je travaille, nous sommes toujours sur ASP.NET WebAPI 5.2.3), donc mon point de vue sur la situation est moins émotionnel.

Regardez les choses de cette façon : si vous deviez commencer à partir de zéro pour créer le prochain Stack Exchange (quel qu'il soit) aujourd'hui, les éléments contenus dans netcoreapp20 que l'équipe ASP.NET Core ne voudrait pas utiliser ( comme UTF8Strings et Pipelines et les primitives à faible allocation, asynchrones et _rapides (je suppose un peu là-bas)) le rendent plus attrayant pour vous que le .NET complet ? .NET Core 2.0 n'aurait-il pas généralement plus de sens que .NET 4.7.1 complet ? Si vous deviez choisir entre des piles Web capables d'évoluer et de s'adapter rapidement aux changements, et des piles Web irrévocablement liées à une technologie sous-jacente lente avec près de deux décennies de code hérité à prendre en charge, que choisiriez-vous ?

@ZigMeowNyan

Je suis plus préoccupé par ce mouvement signalant la possible mise à l'écart de .NET Standard que par le reste. .NET Standard semblait initialement être quelque chose qui rapprocherait de plus en plus les différentes implémentations de la parité des fonctionnalités tout en permettant aux consommateurs de migrer vers la plate-forme en évolution et en pleine croissance. Maintenant, cela ressemble à rien de plus qu'une étape importante des fonctionnalités .NET Core. Vous ne pourrez pas (ou ne voudrez pas) cibler les exécutables vers .NET Standard - uniquement les bibliothèques. Et il semble qu'il y aura beaucoup moins de planification impliquée dans .NET Standard, et à la place, il sera simplement approuvé avec tout ce qui a été utilisé dans ASP.NET car il est déjà trop tard pour changer. Ce sera déjà en production, après tout.

Ce sont en fait de très bons points et quelque chose à considérer. Vous devez comprendre que cela n'a rien à voir avec la mise à l'écart de .NET Standard, c'est juste de la physique. Si chaque plate-forme .NET évolue à son propre rythme, l'utilisation de la dernière norme .NET signifie que les frameworks plus lents obtiennent les choses moins souvent. C'est quelque chose qui devrait être intériorisé par tout le monde. Cela ne le rend pas moins utile, c'est juste la nature de la bête. La seule façon de supprimer ce fardeau est d'avoir une seule implémentation et un seul calendrier de livraison, ce qui réduit considérablement les endroits où .NET pourrait s'exécuter.

D'autres développeurs doivent saupoudrer le code de directives de compilateur, diviser le code en bibliothèques spécifiques à la plate-forme et compiler avec plusieurs cibles. La partie impolie de moi veut que l'équipe ASP.NET Core s'occupe de cela afin que vous soyez intéressé par une meilleure prise en charge de l'exécution et des outils pour les scénarios multi-ciblage et multi-plateforme. Et si votre équipe le veut, nous pourrions l'obtenir. La partie pratique de moi dit qu'au minimum, vous devriez avoir des versions périodiques d'ASP.NET Core qui ciblent la norme .NET. De toute façon, vous devez créer de véritables versions stables. Personne ne va simplement compiler la branche principale de git et la déployer en production. Pourquoi ne pas faire des itérations plus petites du standard .NET et les faire correspondre avec une version ASP.NET balisée ?

Nous faisons la même chose, rappelez-vous, nous ciblons toujours netstandard pour un tas de nos bibliothèques et celles-ci contiennent des ifdefs. D'autres cependant, ciblent netstandard afin de nous préparer à tirer parti des nouvelles API dans la période 2.x.

En bref, je soutiens ce que vous faites et les objectifs qui le sous-tendent. Et je sais que c'est dur quand on arrive ici et qu'on se plaint de décisions que tu as prises pour une très bonne raison. Mais beaucoup de gens ne vont pas sauter dans le train des pionniers parce qu'ils ne le peuvent pas, et d'autres ne le feront pas parce qu'ils ne savent pas où il va.

Question honnête (c'est moi qui pose la question, pas Microsoft), préférez-vous la compatibilité aux nouvelles fonctionnalités ? Si oui, pourquoi choisir ASP.NET Core ?

Juste une autre réflexion rapide : pour chaque thread comme celui-ci, il existe un thread équivalent mais opposé où un groupe de personnes différent, mais tout aussi important, s'est tout aussi fâché parce qu'une concession à la prise en charge de "l'ancien" .NET a été faite.

Il est intéressant de noter que la plupart des versions tierces ont déjà des versions de netstandard disponibles. Ce sont en grande partie les dépendances Microsoft qui nous maintiennent sur .NET Framework, et certaines d'entre elles semblent être semi-abandonnées (par exemple OData)

😞

@markrendle

• La plupart des plaintes que je vois dans ce fil sont une variante de "Je ne peux pas faire X dans .NET Core 2.0" alors que ce que l'écrivain veut dire est "Je dois changer la façon dont je fais X dans .NET Core 2.0" . Oui, il faut changer. Non, ce n'est pas une mauvaise chose. Si vous avez une petite fonctionnalité discrète dans votre application ASP.NET MVC qui fait quelque chose avec des fichiers PDF ou DOCX, et que vous ne pouvez vraiment pas trouver une meilleure façon de faire quoi que ce soit (avez-vous essayé ?), alors cassez ça fonctionnalité dans un microservice s'exécutant sur .NET complet sur Windows Server et appelez-le en tant qu'API HTTP à partir de votre application .NET Core. Décomposer des applications et déplacer des fonctionnalités spécifiques dans de petits services autonomes n'est même pas une solution de contournement, c'est une bonne pratique à usage général.
NB Pour autant que je sache, les packages OpenXML prennent désormais en charge .NET Standard, donc travailler avec Word/Excel/quoi que ce soit ne devrait pas être impossible.<<

Comme d'autres l'ont déjà dit, changer l'architecture de notre joli design n'est pas un bon plan. Dans notre cas, nous partageons le code entre notre test d'application WPF et le serveur. Plus on crée de différences entre celles-ci plus c'est compliqué à maintenir.

Je peux vous assurer que j'ai passé beaucoup de temps à rechercher les meilleurs outils à utiliser pour la génération PDF, DocX et c'est loin d'être aussi simple que de le faire avec Open XML. Nous utilisons une bibliothèque tierce car il y a des dizaines de milliers de lignes de code qu'ils ont développées et nous n'avons pas à développer/maintenir/tester. Exactement.

La gestion des versions .net est devenue très compliquée. Je ne sais pas si à un moment donné dans le futur ASP.net pourra être utilisé sur le framework .net complet ? Parce que j'ai besoin de partager du code entre le serveur et mes applications de bureau, cela signifie-t-il que je ne pourrai jamais avoir la dernière version d'ASP.Net ? Ce n'est pas un problème à court terme, mais à plus long terme avec les améliorations de sécurité, etc., je ne veux pas être trop éloigné de la dernière version. Je suis sûr qu'il y en a beaucoup d'autres dans mon bateau où vous avez besoin d'une forme de compatibilité avec le cadre complet.

Pour clarifier ce que je fais, c'est que j'ai trois de mes propres bibliothèques qui sont partagées entre diverses applications WPF et mon serveur. Je n'aurais absolument aucune idée à ce stade de l'API que j'utilise qui peut ou non être disponible dans le noyau.net. Et puis, dans ces bibliothèques, j'utilise des versions de bureau complètes des outils WPF de Telerik et de SyncFusion pour générer des docx et des pdf. Certaines ou toutes les fonctionnalités utilisées par ces outils peuvent ou non être disponibles dans .net core. Essayer de développer des applications basées sur peut ou non est extrêmement difficile. Microsoft a un cadre de base brillant dans .net, et bien que je comprenne le raisonnement derrière .net core. Microsoft semble avoir oublié l'importance de la rétrocompatibilité.

Stéphane

@markrendle

Oh, désolé, je n'avais pas réalisé que la taille de votre échantillon était si grande. 257 commentaires avec un fort biais envers les personnes qui n'aiment pas la décision ? Difficile d'argumenter avec cela. AVIS DE NON-RESPONSABILITÉ : Je ne suis pas un expert en Big Data.

Aucune idée de ce que je t'ai fait, mais il n'y a pas besoin de se plaindre ou de se plaindre de bas niveau comme ça. Vous savez très bien que ce fil n'est qu'un exemple.

@stefanolson

La gestion des versions .net est devenue très compliquée

Je pense que c'est l'une des rares choses sur lesquelles nous sommes tous d'accord.

Nous cherchons à porter vers .Net Core x.
Nos plus gros problèmes concernent :
NewRelic (pas de plan .Net Core, nous devons donc trouver un alt)
NH (où EF Core n'a pas les fonctionnalités).
ServiceBase (on dirait qu'il arrive sur .Net Core 2 en été)

Il semble certainement que nous devions cibler Core 1.0 dans l'intervalle et attendre les mises à niveau NH, EF ou faire preuve de créativité.

Cela signifie simplement que vous ne pouvez pas utiliser les pages Razor, ASP.NET Core 2.0 a beaucoup de petites choses, mais il n'y a pas de grandes fonctionnalités ou de correctifs qui ne sont pas également rétroportés vers 1.x. La chose EOL est très réelle et personnellement, je ne pense pas que ASP.NET Core 2.0 prenant en charge .NET Framework pendant une autre année aiderait. Nous discutons vraiment d'un changement de direction ici, soit nous prenons en charge .NET Framework pour toujours, soit non, il n'y a vraiment pas d'intermédiaire.

C'est un peu plus grand que les pages Razor, cela signifie qu'il n'y a aucune raison de bouger . Il n'existe tout simplement aucun scénario (actuel) dans lequel les deux existent :

1. Nous serons soutenus tout le temps
2. Il y a une mise à niveau réelle de l'autre côté

Le fait est qu'ASP.NET Core n'est pas vraiment utile sans l'écosystème . Avoir un contrôleur qui restitue le texte est génial, mais pas utile pour autant de scénarios. Nous avons besoin des API. Nous avons besoin des bibliothèques. Nous avons besoin de l'écosystème, c'est pourquoi nous avons choisi .NET en premier lieu .

Ce changement vient d'un framework qui supporte pleinement nos cas d'utilisation aujourd'hui à un qui n'est clairement pas prêt. Ce n'est même pas près d'être prêt. Et un aperçu pour tester s'il est prêt n'est même pas généralement disponible. Une migration pour comprendre les promesses de ce qui sera prêt n'est pas disponible. Nous misons sur tout un tas de promesses et beaucoup seront brûlées. C'est la pire façon possible de commercialiser ces choses : trop prometteuses et trop livrables (l'expérience globale).

Je pense que ASP.NET Core est génial. Vous faites des trucs géniaux. J'ai eu la chance d'aider avec certains d'entre eux. Mais ce commutateur à ce stade est mauvais. Si toutes les choses que nous pensons être portées sont en fait portées dans la période 2.x, alors c'est parfait. Effectuez ensuite la modification dans 3.x. Porter avant qu'une alternative ne soit prête et fixer une date limite pour tuer la ligne de vie EOL est mauvais. Dire aux gens de porter vers une maintenance -> version EOL est mauvais.

S'il vous plaît, ne faites pas ce changement maintenant. .NET est meilleur que cela. Montrez que vous vous souciez de vos utilisateurs autant que tout le monde ici se soucie de vous. Nous ne serions pas ici si nous ne voulions pas aider.

@FransBouma Vous (devriez) savoir très bien que Microsoft dispose de vastes bases de données de télémétrie, de commentaires et d'autres données sur ce que les gens font avec leur technologie qui donnent une image beaucoup plus claire que n'importe quel nombre de fils de discussion GitHub Issues, et je ne pense pas que mon souligner que c'était plus sarcastique que

Oh je ne sais pas, en lisant les messages de ce fil?

La gestion des versions .net est devenue très compliquée. Je ne sais pas si à un moment donné dans le futur ASP.net pourra être utilisé sur le framework .net complet ? Parce que j'ai besoin de partager du code entre le serveur et mes applications de bureau, cela signifie-t-il que je ne pourrai jamais avoir la dernière version d'ASP.Net ? Ce n'est pas un problème à court terme, mais à plus long terme avec les améliorations de sécurité, etc., je ne veux pas être trop éloigné de la dernière version. Je suis sûr qu'il y en a beaucoup d'autres dans mon bateau où vous avez besoin d'une forme de compatibilité avec le cadre complet.

L'histoire du partage de code sur différents runtimes .NET est .NET Standard. Vos bibliothèques doivent essayer de cibler cela sur le code partagé entre .NET Core et .NET Framework.

Microsoft semble avoir oublié l'importance de la rétrocompatibilité.

Le problème est qu'ASP.NET Core n'a jamais été conçu pour être rétrocompatible... C'est pourquoi il y a eu un tel changement de paradigme par rapport à ASP.NET 4.x. Il semble que si la rétrocompatibilité est le bit le plus important pour vous, il serait préférable d'utiliser ASP.NET 4.x sur .NET Framework. Cela est pris en charge dans un avenir prévisible et fera l'objet d'un correctif de sécurité tant que Windows sera en vie.

Même si ce n'était pas censé l'être, la version 1.0 était très rétrocompatible ! Il soutenait tout le vaste héritage de l'écosystème, et nous l'apprécions. Il semblait à l'époque que personne ne devait donner son gâteau ou s'abstenir de le manger.

@NickCraver

C'est un peu plus grand que les pages Razor, cela signifie qu'il n'y a aucune raison de bouger. Il n'existe tout simplement aucun scénario (actuel) dans lequel les deux existent :

Peux-tu élaborer?

Le fait est qu'ASP.NET Core n'est pas vraiment utile sans l'écosystème. Avoir un contrôleur qui restitue le texte est génial, mais pas utile pour autant de scénarios.

Il peut le faire très vite aussi 😉

Je pense que ASP.NET Core est génial. Vous faites des trucs géniaux. J'ai eu la chance d'aider avec certains d'entre eux. Mais ce commutateur à ce stade est mauvais. Si toutes les choses que nous pensons être portées sont en fait portées dans la période 2.x, alors c'est parfait. Effectuez ensuite la modification dans 3.x. Porter avant qu'une alternative ne soit prête et fixer une date limite pour tuer la ligne de vie EOL est mauvais. Dire aux gens de porter vers une maintenance -> version EOL est mauvais.

Je ne comprends pas pourquoi 2.x (support) et 3.x (drop) sont meilleurs que 1.x (support) et 2.x (drop). Pouvez-vous s'il vous plaît m'expliquer cela? Comment cela fait-il une différence?

Quelques recommandations de la session //BUILD 2017 pour ceux qui s'inquiètent de la prise en charge à long terme des variantes ASP.NET :

• T6009 Mises à jour des formulaires Web ASP.NET
  
  
  
  • c'est-à-dire qu'ils développent encore des plates-formes Web .NET complètes
  
  
• T6072 Prise en charge d'ASP.NET Core : Qu'est-ce qu'un LTS ?
  
  
  
  • Ce qui, je suppose, est frénétiquement mis à jour en ce moment :grimacing:
  
  

@davidfowl :

Comment cela fait-il une différence?

Parce que vous avez promis que certaines des API manquantes les plus importantes seront livrées après la version 2.0 ?

@yaakov-h

Parce que vous avez promis que certaines des API manquantes les plus importantes seront livrées après la version 2.0 ?

Dites-moi lesquels dans ASP.NET Core ?

@davidfowl System.DirectoryServices, System.Drawing ont été mentionnés ci-dessus.

Question honnête (c'est moi qui pose la question, pas Microsoft), préférez-vous la stabilité et la compatibilité aux nouvelles fonctionnalités ? Si oui, pourquoi choisir ASP.NET Core ?

Je pense que c'est une très bonne question. Si le framework .NET complet donne à chacun tout ce dont il a besoin aujourd'hui, pourquoi est-il si désireux de migrer vers une pile complètement différente ? Si .NET Core et ASP.NET Core auraient été nommés différemment, sans .NET int le nom, alors je pense que beaucoup moins de gens discuteraient des problèmes de migration. Personne ne se plaint de ne pas pouvoir migrer vers une pile Web Go ou Node.js plus rapide.

@davidfowl être rétrocompatible avec ASP.NET MVC 5.x est une chose, être rétrocompatible avec le framework .net en est une autre. L'abandon du framework .net est une grande chose...

Je ne comprends pas pourquoi 2.x (support) et 3.x (drop) sont meilleurs que 1.x (support) et 2.x (drop).

Parce que 2.x arrive très bientôt comme nous le comprenons.

@davidfowl System.DirectoryServices, System.Drawing ont été mentionnés ci-dessus.

Ceux-ci n'ont rien à voir avec ASP.NET Core 1.x ou 2.x et s'exécuteront sur les deux lorsqu'ils seront en ligne.

Comme je l'ai dit, je suis juste ici pour appeler le FUD et ça en fait partie. Ce fil est devenu si gros que personne ne peut voir les faits dans certaines des réponses.

@FransBouma Vous (devriez) savoir très bien que Microsoft dispose de vastes bases de données de télémétrie, de commentaires et d'autres données sur ce que les gens font avec leur technologie qui donnent une image beaucoup plus claire que n'importe quel nombre de fils de discussion GitHub Issues, et je ne pense pas que mon souligner que c'était plus sarcastique que

La télémétrie @markrendle n'est pas magique. Vous ne pouvez pas mesurer pourquoi ppl/dev ne changent pas, ou pourquoi ils ont basculé sur une autre pile, ou l'importance de leur projet et combien ils aiment la pile (et aident les autres, avec des conseils ou oss), ou ce qu'ils font.

Ce fil est exactement cela, un feedback.

Je ne comprends pas pourquoi 2.x (support) et 3.x (drop) sont meilleurs que 1.x (support) et 2.x (drop). Pouvez-vous s'il vous plaît m'expliquer cela? Comment cela fait-il une différence?

@davidfowl temps.
le temps de s'installer un peu. le temps d'évaluer les choses. le temps de changer une chose à la fois. il est temps d'utiliser des packages netstandard2 avec un truc rtm. il est temps de déplacer nos bibliothèques vers netstandard2 (plus facile) au lieu de netstandard1 (plus difficile). Il est temps de changer une chose à la fois, pour moi, surtout.
Vous faites aspnet, mais mon produit n'est pas seulement aspnet, c'est une combinaison de beaucoup de bibliothèques et de compromis et de l'écosystème.

Parce que 2.x arrive très bientôt comme nous le comprenons.

Qu'est-ce que cela a à voir avec cela? Et si le 2.0 arrivait en fin d'année ou en janvier ? Cela ferait-il une différence? Qu'y a-t-il dans la version 2.0 qui rend la version 1.x inutile ?

@yaakov-h Ils ont été mentionnés ici où @shanselman a dit (c'est moi qui souligne)

AD - Totalement, c'est une lacune SI vous souhaitez appeler LDAP directement. Vous pouvez certainement vous authentifier contre Windows Auth MAINTENANT. Nous prévoyons d'avoir spécifiquement l'espace de noms DirectoryServices pour Core 2.0 vers l'été
Dessin - Totalement, c'est une lacune. Nous prévoyons de l'avoir pour Core 2.0 vers la période estivale . Jusqu'à cela, ces options netstandard existent également ImageSharp, ImageResizer, Mono options, etc.

@davidfowl , il ne s'agit pas de version, mais de date et de maturité du noyau .net et de son écosystème.

@hikalkan

Je suis désolé, je comprends cela d'un point de vue de très haut niveau mais pas d'un point de vue technique. Ce n'est peut-être pas une discussion technique ?

@enricosada

le temps de s'installer un peu. le temps d'évaluer les choses. le temps de changer une chose à la fois. il est temps d'utiliser les packages netstandard2 avec une chose rtm. il est temps de déplacer nos bibliothèques vers netstandard2 (plus facile) au lieu de netstandard1 (plus difficile). Il est temps de changer une chose à la fois, pour moi, surtout.
Vous faites aspnet, mais mon produit n'est pas seulement aspnet, c'est une combinaison de beaucoup de bibliothèques et de compromis et de l'écosystème.

Pourquoi cela fait-il une différence avec ASP.NET Core 2.0 en particulier ? Vous bénéficierez de cet avantage de la plate-forme, indépendamment de ce que ASP.NET Core choisit de faire.

@markrendle, quelqu'un me donne un calendrier, car les saisons s'étendent sur un trimestre entier (il peut y avoir 3 mois à partir d'autre chose dans le même trimestre) et sont particulièrement déroutantes pour nous, les habitants de l'hémisphère sud.

@enricosada Vous pouvez obtenir énormément d'informations utiles à partir de la télémétrie et d'autres sources de données (analyses Web, données de recherche, commentaires directs des clients). Bien plus que ce que vous pouvez obtenir des foules en colère sur GitHub (aussi justifiée que soit la colère de chaque individu).

@yaakov-h Eh bien, le RTM actuellement projeté pour .NET Core 2.0 (et donc ASP.NET Core 2.0) est le calendrier Q3, qui est juillet/août/septembre), et l'été dans l'hémisphère nord est principalement juillet/août/septembre , donc c'est fondamentalement la même chose.

Vous pouvez obtenir énormément d'informations utiles à partir de la télémétrie et d'autres sources de données (analyses Web, données de recherche, commentaires directs des clients).

Je me demande cependant quelle est la fiabilité de cette télémétrie - du moins la partie automatisée - pour les déploiements en entreprise. (Puisque c'est de là que la majorité du contrecoup semble provenir.)

Je ne comprends pas pourquoi 2.x (support) et 3.x (drop) sont meilleurs que 1.x (support) et 2.x (drop). Pouvez-vous s'il vous plaît m'expliquer cela? Comment cela fait-il une différence?

@davidfowl Time. Et une annonce appropriée. Si le message était plus clair, les gens ne seraient pas aussi surpris.

@davidfowl Time. Et une annonce appropriée. Si le message était plus clair, les gens ne seraient pas aussi surpris.

Je comprends, mais je ne pense pas que cela ferait une différence dans votre capacité à porter quoi que ce soit vraiment. La même politique EOL existe toujours.

Ok, après avoir eu du mal à comprendre ce problème, je voulais apporter quelques idées à ceux qui luttent comme moi et ont également des questions.

donc si vous comprenez bien, nous aurons éventuellement netstandard remplaçant net framework.

Supposons donc que netcore n'existe pas et que le noyau aspnet est basé sur netstandard. cela signifie que les fonctionnalités viendront plus lentement.

Exemple:
2017 asp.net veut la fonctionnalité A.
2018 netstandard implémente la fonctionnalité A. nous obtenons la fonctionnalité A sur ns.

Ce que l'équipe dit, c'est que le netcore n'est pas basé sur le netstandard, donc :
2017 asp.net veut la fonctionnalité A
L'équipe aspnet 2017 implémente la fonctionnalité A. Asp.Net Core obtient la fonctionnalité A sur netcore.
2018 netstandard implémente la fonctionnalité A. nous obtenons la fonctionnalité A sur ns.

Ainsi, cette décision apporte en fait plus de "flexibilité et de rapidité" à l'équation. Une version plus rapide pour qui peut les utiliser, des commentaires, etc. Je pense que c'est un excellent ajout à la paix lente du cadre net. La fonctionnalité sera vraiment mature lorsqu'elle atteindra la Nouvelle-Écosse.

Si avoir netcore basé sur netstandard 2 signifie que les fonctionnalités sont publiées 1 an (ou n'importe quel délai) plus tard, les gens diront toujours qu'ils veulent cela ? C'est le scénario auquel nous sommes habitués avec NET Framework .

C'est un paradis pour l'équipe aspnet, pouvoir expédier des choses sans dépendre de quelqu'un d'autre, et c'est aussi une excellente nouvelle pour les clients qui peuvent obtenir ces choses rapidement. Si vous ne pouvez pas aller avec les trucs rapides, s'en tenir à la version précédente est un compromis raisonnable (et une motivation pour vous/les dépendances à mettre à niveau.)

Les auteurs de bibliothèques doivent toujours viser netstandard, et si vous le pouvez, ne vous inquiétez pas du tout.
Si vous avez besoin de quelque chose qui n'est pas sur netstandard (peut-être des pages de rasoir (?)), alors vous devez cibler netcore, dans le scénario 1, les pages de rasoir peuvent même ne pas exister. Je ne vois pas en quoi cela peut être mauvais, je dirais que c'est juste.

La question est donc de savoir quelle dépendance vous avez actuellement qui vous empêche de passer de NET Framework à Net Core ?
Je suis peut-être le seul ici, mais je ne m'attendais pas à ce que le noyau aspnet fonctionne sur NET Framework pour toujours, il était évident pour moi qu'il s'agissait d'une étape de "transition". Tous mes développements qui ont actuellement besoin de NET Framework sont splited . (et non, ce ne sont pas des microservices, c'est bien plus simple que ça).

la prise en charge 2.x et la suppression 3.x ne sont pas différentes de la prise en charge 1.x et de la suppression 2.x. Je vais deviner ici et dire que les gens ne comprennent pas clairement le scénario, alors j'espère que cela en clarifiera au moins certains.

@NickCraver , vous avez dit que vous vouliez que Microsoft revienne sur cette décision. Quelle serait votre suggestion, pour ne pas avoir un netcore isolé et avoir des versions de fonctionnalités plus lentes ? (question honnête)

@davidfowl Je pense qu'il peut y avoir un subtil problème caché avec la proposition actuelle qui inquiète les développeurs.
Si vous avez la fonctionnalité A pour asp.net (avec netcore), vous pouvez commercialiser et expédier (et cocher une case gestion/pm) et être "paresseux" pour l'implémenter sur netstandard, si je ne me trompe pas c'est ce que "pari" sur incertain est arbitré ici.
Ainsi, dans mon exemple précédent, netstandard implémente la fonctionnalité A peut être en 2019, ou 2020, ou jamais au lieu de 2018. <-- cela ressemble à un problème possible (?) ai-je raison ? Microsoft peut-il s'engager à quelque chose ici ?

Bien que nous puissions tous différer quant à savoir si nous aimons l'annonce, merci en effet à @davidfowl @DamianEdwards et @shanselman pour avoir passé du temps à discuter. C'est une preuve supplémentaire d'un engagement et d'une ouverture accrus.

Je suis sûr que certains argumenteront sur le timing, etc., mais c'est un progrès.

Exemple:
2017 asp.net veut la fonctionnalité A.
2018 netstandard implémente la fonctionnalité A. nous obtenons la fonctionnalité A sur ns.

Ce que l'équipe dit, c'est que le netcore n'est pas basé sur le netstandard, donc :
2017 asp.net veut la fonctionnalité A
L'équipe aspnet 2017 implémente la fonctionnalité A. Asp.Net Core obtient la fonctionnalité A sur netcore.
2018 netstandard implémente la fonctionnalité A. nous obtenons la fonctionnalité A sur ns.

ce qu'ils auraient dû faire c'est :
L'équipe aspnet 2017 construit la fonctionnalité nécessaire dans lib X, qui prend en charge netstandard2.0. De cette façon, aspnet fonctionne sur tout ce sur quoi .netstandard s'exécute, et les utilisateurs peuvent ensuite l'exécuter sur .net full, car lib X est également utilisable sur .NET full (c'est juste une installation de nuget).

Au lieu de cela, ils ne le font pas, ils forcent lib X à être le noyau .NET uniquement (sinon, pourquoi ce fil/décision en premier lieu). Si la lib X est tellement avancée qu'elle a besoin des fonctionnalités CoreCLR, Microsoft doit se demander pourquoi ces fonctionnalités avancées ne sont pas portées sur le CLR complet .NET.

Dans l'ensemble, cela ressemble à de la politique où MS a besoin d'un noyau .NET/aspnet à évolution rapide pour fournir aux clients Azure une pile qui peut être utilisée dans des conteneurs sur azur afin qu'elle soit en concurrence avec les conteneurs basés sur JVM/NodeJS sur AWS ou Google cloud. De leur point de vue commercial, je peux même comprendre cela. Mais ce que cela montre, c'est que MS n'a aucune priorité concernant .NET full pour avancer plus rapidement, car il ne met pas assez de ressources sur .NET full pour suivre le rythme de .NET core. Regardez le nombre d'API ajoutées à .NET complet au cours des 2 dernières années. Cela vous indique-t-il qu'une grande équipe travaille là-dessus?

Non.

Microsoft vend un grand système de base de données, SQL Server Enterprise. Il est livré avec des fonctionnalités de cryptage sophistiquées. Non pris en charge sur le noyau .NET. Amusez-vous à vendre .NET core 2.0 aux entreprises qui sont les clients potentiels de ce système de base de données coûteux.

Vous voudrez peut-être vous déplacer « rapidement », mais à moins que vous ne compreniez parfaitement la destination vers laquelle vous vous dirigez, il est utile de prendre une minute ou deux pour le décider en premier.

Plus j'y pense, plus je pense que le problème que la plupart des gens ont, c'est qu'ils ont l'impression que nous coupons le cordon entre .net et asp.net.
Actuellement, nous avons asp.net, asp.net core (.net) et asp.net core (core). Vous pouviez donc choisir si vous vouliez aller sans, peu ou pas de noyau.

Étant donné que la gestion des versions est mal communiquée, les gens ont le sentiment que ce n'est que la dernière partie qui innove et avance, tandis que asp.net et asp.net core (.net) sont bloqués.
Comme nous n'avons aucun moyen de valider si une bibliothèque fonctionnera dans netstandard2.0 sans essayer, il devient très risqué d'aller avec le cœur complet sur un nouveau projet. Ils se retrouvent donc avec le noyau asp.net (ancien) ou asp.net (également ancien).
Et comme les deux sont anciens, il est logique d'utiliser system.web et l'ancien asp.net. Puisqu'ils le savent et que le noyau asp.net est de toute façon EOL, pourquoi s'en soucier.

Nous nous retrouvons donc avec seulement le courageux qui choisit le noyau, et le reste va avec l'ancien mais stable system.web. Et nous serons à jamais coincés avec un écosystème encore plus fracturé.

PS : Je formule cela comme avec le sentiment actuel. Ce noyau asp.net 1.x est "ancien et obsolète" par rapport à 2.x. Non pas que ce soit un fait, mais c'est ce que les gens pensent.

@davidfowl

Si chaque plate-forme .NET évolue à son propre rythme, l'utilisation de la dernière norme .NET signifie que les frameworks plus lents obtiennent les choses moins souvent.

Cela se produit déjà, et nous sommes d'accord avec cela. Le document Versions est généralement rempli avec _vNext_. Et c'est bien. Plutôt que d'attendre que toutes les plates-formes soient à parité avant d'incrémenter la norme, je préfère voir la norme définie quelques versions à l'avance et regarder les plates-formes rattraper leur retard. Les gens peuvent même participer à la définition et à la mise en œuvre. Et si ASP.NET Core ciblait la norme pour ses versions, dès qu'une plate-forme et une architecture implémenteraient cette nouvelle norme, le package serait disponible. De nouvelles versions standard peuvent arriver via des mises à jour ou des packages VS.

La façon dont il est présenté, bien que .NET Standard ne semble pas être un effort planifié par la communauté. Il s'agit plutôt d'un instantané des contrats mis en œuvre qui ont passé l'examen. Et si les projets majeurs ne le ciblent pas, il n'y aura pas autant de planification pour ses sorties.

On fait la même chose

Oh super. La misère partagée est la meilleure des misères. Les fichiers csproj et sln avec les éléments de plate-forme/config sont vraiment ennuyeux, d'ailleurs, car les combinaisons de construction ne sont pas toujours déclarées - elles sont déduites. Ainsi, VS pourrait penser que j'ai plus de combinaisons de construction qu'il n'en existe réellement, car il suppose que chaque combinaison possible est importante. Et je dois avoir des sections supplémentaires dans le fichier qui ne seraient pas nécessaires si je pouvais simplement déclarer les combinaisons plate-forme/config. Comme la façon dont vous pouvez utiliser des fonctions comme Substring dans les éléments csproj PropertyGroup pour simplifier les propriétés personnalisées, mais ces conditions sont utilisées pour déterminer les configurations de construction, vous devez donc avoir les valeurs de chaîne complètes là-dedans. Ce genre de choses ne devrait pas être aussi compliqué qu'il l'est.

Question honnête (c'est moi qui pose la question, pas Microsoft), préférez-vous la compatibilité aux nouvelles fonctionnalités ? Si oui, pourquoi choisir ASP.NET Core ?

Personnellement, non. Tant qu'il y a un moyen de faire ce que je dois faire, cela ne me dérange pas de réécrire le code tant que ce n'est pas une entreprise énorme avec peu d'avantages ou un PITA à tester. Je choisirais donc ce qui a le plus d'élan et de potentiel. Mais je dois travailler avec des projets sur plusieurs technologies - Win32, COM, CORBA, ADO.NET, plusieurs moteurs de création de rapports, diverses API Web, des navigateurs intégrés comme CEF/Firefox/IE (pas de bord, bien sûr, car il n'est pas pris en charge) et plusieurs choses spécifiques au fournisseur que j'éviterai de faire honte. J'implémente ce que je peux en tant que plugin, mais je suis marié au plus petit dénominateur commun sur l'exécutable hôte, pour la plupart. Traiter avec autant de technologies est ennuyeux, mais elles sont statiques. C'est comme ça que beaucoup de trucs de bureau/serveur sont. Tant qu'on me donne les outils pour interagir, je peux me débrouiller. Mais moins je me souviens de frameworks obsolètes, mieux c'est.

ASP.NET, cependant, fait partie de la pile Web, et la pile Web est quelque chose qui, selon moi, doit rester à jour. Il a un cas d'utilisation différent, et on s'attend malheureusement à utiliser la nouvelle plate-forme pour le travail Web à moins qu'il n'y ait une bonne raison de ne pas le faire, ou une base de code incompatible importante. J'essaie de tenir cela à jour car les normes Web changent rapidement et de manière significative. La plupart des gens qui suivent le rythme du Web s'en tiennent aux technologies les plus récentes, et la mise en œuvre des nouveautés sur des piles plus anciennes peut être plutôt pénible. Surtout dans la situation où ASP.NET est en concurrence avec PHP et Node, je dois garder une pile plus moderne pour attirer les talents et l'intérêt. J'aimerais faire moins de travail sur le Web, mais malheureusement, c'est la nouvelle attente de l'interface utilisateur. J'espérais que m'en tenir à la norme me permettrait d'avoir le meilleur des deux mondes, mais cela semble être une offre à durée limitée.

donc si vous comprenez bien, nous aurons éventuellement netstandard remplaçant net framework.

Non ce n'est pas correct. Je ne sais pas comment vous avez tiré cette conclusion. .NET Standard sera toujours un sous-ensemble de chacun des runtimes qui le prennent en charge.

Je veux jeter des trucs fous ici parce que ça a été mentionné plusieurs fois. Ce que je m'apprête à dire n'a aucune incidence sur ce qui va se passer, ce ne sont que des spéculations à ce stade. Plusieurs personnes ont demandé pourquoi nous voulions cibler .NET Core au lieu de .NET Standard.

• Nous avons identifié les chaînes comme l'une des principales choses que nous aimerions essayer de résoudre dans .NET Core, il y a des tonnes d'idées mais l'une d'entre elles est d'avoir la chaîne en utf8 par défaut (des tonnes de problèmes de compatibilité mais suivez-moi ici).
• Une autre chose que nous aimerions corriger est la possibilité de prendre des tranches bon marché de tableaux/chaînes, n'importe quel morceau de mémoire contiguë. Nous avons ajouté Span<T> et envisageons Buffer<T> pour représenter cela. Cela peut signifier que String et Array implémentent de nouvelles interfaces qui permettent de prendre une tranche nécessitant une allocation 0.
• Cela conduit à de nouvelles méthodes sur String qui permettent un fractionnement qui n'alloue pas un tableau à chaque fois.
• Cela conduit à des surcharges de Int, UInt etc (TryParse) qui prennent Span<char> et Span<byte> .
• Cela conduit à de nouvelles routines d'encodage qui prennent Span<byte> .
• Buffer<T> et Span<T> vous permettent de représenter la mémoire de manière uniforme et nous souhaitons mettre à niveau la pile réseau pour permettre le passage de tampons pré-épinglés qui prennent Span<T> ou Buffer<T> .
• Kestrel implémentera HTTP2 dans la période 2.x (visant actuellement à 2.1) et cela nécessite de nouvelles API sur le flux SSL pour faire ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
• Le client Http sur .NET Core prend en charge le streaming duplex, il permettra d'implémenter des points de terminaison de streaming sur http dans signalr sur une seule requête http non websocket.
• Nous avons dérivé les implémentations de l'analyseur d'en-tête de HttpClient et System.Net.Http et les avons renommés (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) afin que nous puissions les améliorer et faites-les prendre en charge à la fois .NET Framework et .NET Core. .NET Core a une copie de ces améliorations qui n'a pas été récupérée car il n'est pas nécessaire de les améliorer (nous ne pouvions pas les consommer).
• Il existe un tas de nouvelles primitives de threading qui nécessitent une nouvelle API qui éclairera de nouveaux scénarios si nous sommes en mesure de les consommer (https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+ author%3Adavidfowl+label%3Aarea-System.Threading), ce ne sont que quelques-unes des choses que j'ai personnellement déposées.

Sans la possibilité de reviser les primitives de base, nous sommes encouragés à les bifurquer et à créer des choses qui leur ressemblent mais qui n'en sont pas. C'est la raison pour laquelle nous avons notre propre petit BCL dans ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Ce n'était qu'un vidage aléatoire de choses que je peux nous voir faire à court terme et qui affectent des éléments très fondamentaux de .NET.

@FransBouma

NET full pour avancer plus rapidement, car il ne met pas assez de ressources sur .NET full pour suivre le rythme de .NET core. Regardez le nombre d'API ajoutées à .NET complet au cours des 2 dernières années. Cela vous indique-t-il qu'une grande équipe travaille là-dessus?

Ce n'est tout simplement pas vrai. Les choses sont continuellement portées sur .NET Framework, mais comme nous le savons tous, le risque est considérablement plus élevé que d'apporter ces mêmes modifications dans .NET Core. Ne détestez-vous pas tous qu'une mise à jour de .NET Framework casse votre application ? Nous aussi, nous inventons toutes sortes de processus pour l'atténuer, vous ne croiriez pas l'étau qu'il exerce sur l'ingénierie pour le maintenir. Nous parvenons toujours à faire des fonctionnalités malgré tout cela. Cela dit, il ne se déplacera jamais aussi vite que .NET Core, c'est un composant Windows qui est livré selon le calendrier Windows.

Je comprends, mais je ne pense pas que cela ferait une différence dans votre capacité à porter quoi que ce soit vraiment. La même politique EOL existe toujours.

@davidfowl Correct. Mais la façon dont vous l'encadrez signifie quelque chose. Sans parler du moment où il est communiqué , si jamais. Cela ne donnera pas nécessairement plus de temps aux gens pour faire le travail proprement dit, mais cela leur donnerait plus de temps pour réfléchir et prendre la bonne décision (pour eux).

Actuellement, si vous avez commencé à porter vers/à utiliser ASP.NET Core sur .NET Framework, il semble que vous ayez trois choix :

1. Portez tout votre code et vos dépendances vers .NET Core et passez à ASP.NET Core 2.x.
   
   
   
   • Ce serait la solution optimale, mais cela pourrait nécessiter des tonnes de travail, et pour certains, cela pourrait même être hors de leur contrôle à cause de bibliothèques tierces.
   
   
2. Restez sur ASP.NET Core 1.x et .NET Framework et espérons que vous pourrez faire 1. avant qu'il ne soit plus pris en charge.
   
   
   
   • C'est assez risqué. Dans un an (ou deux, ou trois ? Qui sait ?), vous pourriez courir le risque de fonctionner sur une plate-forme non prise en charge.
   
   
3. Revenir à ASP.NET 4.x
   
   
   
   • Bien que cette alternative vous laisse en charge, vous allez "revenir en arrière" et annuler le travail que vous avez déjà commencé. Et aussi, avouons-le; cette plate-forme ne recevra pas beaucoup d'amour à l'avenir.
   
   

Si vous l'aviez su à l'avance et que vous pouviez le planifier, je pense que 1. et 2. sont des alternatives décentes. Le problème est que les deux alternatives ont pas mal d'inconnues. Qu'en est-il de la bibliothèque A ? Et la bibliothèque B ? La bibliothèque A sera-t-elle un jour portée ?

À l'heure actuelle, je pense que beaucoup de gens se sentent obligés de faire un choix, sans avoir une idée claire de ce que ces choix impliquent réellement.

@khellang (dans votre solution hypothétique)

1. Passer à ASP.NET Core 2.0 sur .NET Framework
   
   
   
   • C'est assez risqué. Dans un délai d'un an, vous pourriez risquer de fonctionner sur une plate-forme non prise en charge.
   
   

@davidfowl

Question honnête (c'est moi qui pose la question, pas Microsoft), préférez-vous la stabilité et la compatibilité aux nouvelles fonctionnalités ? Si oui, pourquoi choisir ASP.NET Core ?

Réponse honnête :
Faveur : la stabilité et la compatibilité sont primordiales. Les nouvelles fonctionnalités sont agréables, mais lorsqu'elles débarquent, elles ne doivent tout simplement pas casser l'écosystème existant.
Pourquoi ASP.NET Core : Tout simplement parce qu'il fonctionne sous OS X et Linux.

Un écosystème comme .NET (ancien et/ou noyau) ou encore Java est choisi par les entreprises. Et lorsqu'ils prennent leur décision, ils consacrent beaucoup d'efforts au développement de code pour cette plate-forme / cet écosystème.

Maintenant, un de nos clients, par exemple, a déjà beaucoup investi dans ASP.NET Core. Sur la base des annonces précédentes et des idées vendues de .NET Core, le code a été écrit. Ce nouveau code (ASP.)NET Core que nous avons (douloureusement) écrit avec une équipe au cours du développement initial de (ASP).NET Core, à commencer par sa création, est un ensemble de serveurs et de bibliothèques clientes, avec un certain nombre de la logique métier.
Et ce code, en plus de fonctionner sur un serveur Linux, fournissant des services, est actuellement également utilisé dans un ensemble d'applications très anciennes qui parlent à ces services, et ce sont un sacré mélange de WPF / Windows Forms / C++/CLI et normal C++ (y compris les trucs DirectX).

Et maintenant, vous coupez simplement l'investissement de nos clients dans quelques années-homme d'efforts dans le code .NET Core pour les applications existantes, car il sera impossible de réutiliser le nouveau code .NET Core dans les applications réelles. (les nouveaux serveurs et bibliothèques de logique métier ont été construits pour).

Pour revenir à la question : une entreprise choisirait .NET Core comme ".NET, maintenant aussi pour XPlat", tout en s'attendant à la même compatibilité et stabilité que .NET nous a donné au cours des 17 dernières années. Et, pour être franc, c'est la seule raison de .NET Core. Si vous ne vouliez pas cela, vous utiliseriez Node.js ou même Java. Les deux sont beaucoup plus matures et XPlat que .NET Core maintenant.

Et, juste pour élaborer un peu plus: .NET Core était cool et rapide au début avec project.json et tout. Et puis, pour des raisons de "compatibilité avec .NET", project.json nous a été retiré au profit de Msbuild et .csproj à nouveau. Et maintenant, les avantages de cette "compatibilité avec .NET" sont également supprimés, au profit de... quoi exactement ?

@gingters

Tout d'abord, super réponse !

Pourquoi ASP.NET Core : Tout simplement parce qu'il fonctionne sous OS X et Linux.

Sur cette base, il semble que MVC 5 en mono soit ce que vous vouliez vraiment, n'est-ce pas ?

Pour revenir à la question : une entreprise choisirait .NET Core comme ".NET, maintenant aussi pour XPlat", tout en s'attendant à la même compatibilité et stabilité que .NET nous a donné au cours des 17 dernières années. Et, pour être franc, c'est la seule raison de .NET Core. Si vous ne vouliez pas cela, vous utiliseriez Node.js ou même Java. Les deux sont beaucoup plus matures et XPlat que .NET Core maintenant.

Et, juste pour élaborer un peu plus: .NET Core était cool et rapide au début avec project.json et tout. Et puis, pour des raisons de "compatibilité avec .NET", project.json nous a été retiré au profit de Msbuild et .csproj à nouveau. Et maintenant, les avantages de cette "compatibilité avec .NET" sont également supprimés, au profit de... quoi exactement ?

C'est essentiellement le nœud du problème. D'après votre évaluation :

Ce nouveau code (ASP.)NET Core que nous avons (douloureusement) écrit avec une équipe au cours du développement initial de (ASP).NET Core.

Vous vouliez vraiment juste le .NET Framework existant sur Linux avec la bonne vieille compatibilité ASP.NET 4.x. Est-ce un résumé juste?

Faveur : la stabilité et la compatibilité sont primordiales. Les nouvelles fonctionnalités sont agréables, mais lorsqu'elles débarquent, elles ne doivent tout simplement pas casser l'écosystème existant.

.NET Core est en fait une plate-forme plus stable que Desktop car il permet une exécution côte à côte là où Desktop ne le fait pas.

Si vous souhaitez utiliser des fonctionnalités plus récentes dans la prochaine version de Desktop, vous devez mettre à niveau l'ensemble de la machine vers cette nouvelle version et cela affecte tout sur cette machine, pas seulement l'application qui souhaite utiliser les nouvelles fonctionnalités. Ce qui est bien si vous avez un serveur dédié à un seul usage ; mais pas si vous avez de nombreuses applications exécutées sur le même serveur qui se mettent à niveau à des rythmes différents (ou ne se mettent jamais à niveau du tout !)

@davidfowl a écrit :

C'est aux frameworks de décider s'ils veulent s'exécuter sur .NET Framework, UWP, .NET Core, mono etc. C'est un choix. Orleans n'est pas livré avec .NET Core. ASP.NET Core le fait. Ces produits sont identiques.

Dans le cas d'Orléans, nous prenons en charge .NET Standard 1.5 dans nos versions "2.0 Technical Preview", mais nous attendons .NET Standard 2.0 pour pouvoir créer une version stable. À l'heure actuelle, je ne vois aucun obstacle pour nous - ma préoccupation concerne uniquement les divergences futures. Cette divergence doit cependant se produire à un moment donné.

👍 Un immense merci d'être resté pour répondre aux questions de tout le monde, @davidfowl & co !

NET full pour avancer plus rapidement, car il ne met pas assez de ressources sur .NET full pour suivre le rythme de .NET core. Regardez le nombre d'API ajoutées à .NET complet au cours des 2 dernières années. Cela vous indique-t-il qu'une grande équipe travaille là-dessus?

Ce n'est tout simplement pas vrai. Les choses sont continuellement portées sur .NET Framework, mais comme nous le savons tous, le risque est considérablement plus élevé que d'apporter ces mêmes modifications dans .NET Core. Ne détestez-vous pas tous qu'une mise à jour de .NET Framework casse votre application ? Nous aussi, nous inventons toutes sortes de processus pour l'atténuer, vous ne croiriez pas l'étau qu'il exerce sur l'ingénierie pour le maintenir. Nous parvenons toujours à faire des fonctionnalités malgré tout cela. Cela dit, il ne se déplacera jamais aussi vite que .NET Core, c'est un composant Windows qui est livré selon le calendrier Windows.

cela ignore le fait que vous pouvez publier les bibliothèques dont vous dépendez en tant que packages netstandard2.0 afin que aspnet puisse également s'exécuter sur .net full. De plus, apporter des modifications à .NET complet n'est pas sans risque, mais s'il vous plaît, ne donnez pas l'impression qu'il s'agit d'un tas de code terriblement organisé où un changement peut tout faire s'effondrer.

Nous parvenons toujours à faire des fonctionnalités malgré tout cela.

Oui, c'est le cas de tous les autres développeurs .NET ;) Une fois que vous publiez quelque chose, vous êtes coincé avec cette API, nous avons tous cela. Vous voulez cependant prendre un raccourci (comme l'équipe ASPNET l'a fait plusieurs fois auparavant !) et vous déplacer sans ce fardeau. Mais cela ne va pas voler à la fin.

Cela dit, il ne se déplacera jamais aussi vite que .NET Core, c'est un composant Windows qui est livré selon le calendrier Windows.

Je pense que nous avons ici le nœud du problème, n'est-ce pas? L'équipe principale de .NET peut faire ce qu'elle veut sans communiquer avec le mastodonte "WinDiv". Pourquoi Microsoft ne résout-il pas cette merde de politique interne en interne et s'assure-t-il que .NET full + .NET core sont versionnés/se déplacent correctement sans la politique Windows ?

Btw, toujours intéressé par la façon dont vous vendriez l'API de chiffrement de SQL Server Enterprise aux utilisateurs de .NET core 2.0.

Aussi, je dois ajouter; Je suis assez impressionné par la durée de ce fil, avec autant de personnes impliquées, tout en restant civil ❤️ Ce n'est pas quelque chose que vous voyez tous les jours sur Internetz 👏 Peut-être que l'écosystème .NET OSS grandit après tout ? 😉

cela ignore le fait que vous pouvez publier les bibliothèques dont vous dépendez en tant que packages netstandard2.0 afin que aspnet puisse également s'exécuter sur .net full.

De plus, apporter des modifications à .NET complet n'est pas sans risque, mais s'il vous plaît, ne donnez pas l'impression qu'il s'agit d'un tas de code terriblement organisé où un changement peut tout faire s'effondrer.

Il est grand et existe depuis longtemps. Comme tout système hérité, certaines parties sont meilleures que d'autres. Cela ne rend pas le code moins fiable, mais cela rend certaines parties pratiquement impossibles à modifier. Il y a tellement d'histoires amusantes que les vétérans peuvent vous raconter sur la façon dont les corrections de bogues dans un domaine ont brisé des scénarios obscurs dans des applications dans d'autres parties. C'est emmêlé, c'est ce qui arrive quand les limites de dépendance ne sont pas bien définies. Vous n'avez même pas besoin de me croire, allez simplement parcourir referencesource.microsoft.com. Les mises à jour sur place sont la raison pour laquelle nous devons ajouter un commutateur de configuration pour chaque changement potentiellement cassant à .NET Framework. C'est de la physique, ça ne peut pas aller aussi vite.

Oui, c'est le cas de tous les autres développeurs .NET ;) Une fois que vous publiez quelque chose, vous êtes coincé avec cette API, nous avons tous cela. Vous voulez cependant prendre un raccourci (comme l'équipe ASPNET l'a fait plusieurs fois auparavant !) et vous déplacer sans ce fardeau. Mais cela ne va pas voler à la fin.

Nous aimons les raccourcis ! Les développeurs sont paresseux 😄 . Nous souhaitons également véritablement améliorer notre .NET Core sans perturber ce que représente .NET Framework. Peut-être aurions-nous dû le renommer en quelque chose d'autre, comme Sparkle 😄 .

Je pense que nous avons ici le nœud du problème, n'est-ce pas? L'équipe principale de .NET peut faire ce qu'elle veut sans communiquer avec le mastodonte "WinDiv". Pourquoi Microsoft ne résout-il pas cette merde de politique interne en interne et s'assure-t-il que .NET full + .NET core sont versionnés/se déplacent correctement sans la politique Windows ?

Lisez mon autre réponse sur la physique.

Btw, toujours intéressé par la façon dont vous vendriez l'API de chiffrement de SQL Server Enterprise aux utilisateurs de .NET core 2.0.

Ce n'est pas mon domaine d'expertise, je laisserai quelqu'un d'autre répondre.

@khellang lol c'est parce que les problèmes de GitHub n'ont pas encore attiré les trolls détestant MS. Actuellement, Twitter est leur support pour cela où il n'y a pas encore de vote négatif :)

@davidfowl

Vous vouliez vraiment juste le .NET Framework existant sur Linux avec la bonne vieille compatibilité ASP.NET 4.x. Est-ce un résumé juste?

Non, pas vraiment. Notre client avait besoin de services complets nouveaux / brillants (micro), pour compléter ses applications de bureau Windows .NET 4.x existantes (elles étaient 3.5 lorsque nous avons commencé).

Lorsque vous êtes passé en version bêta avec tous les éléments brillants de Core, nous avons commencé à écrire le nouveau code serveur pour le tout nouveau MVC au-dessus d'ASP.NET Core, ainsi que le DTO, la logique métier et les bibliothèques clientes, qui sont également en cours. utilisé en parallèle dans les applications de bureau 4.6 existantes pour communiquer avec les tout nouveaux serveurs.

En outre, certains des tout nouveaux serveurs ASP.NET Core ne fonctionnent pas uniquement sur Linux, mais également en tant que services Windows avec Topshelf (en plus du framework 4.6 complet).

Donc, le fait est que beaucoup d'investissements ont été faits, et maintenant nous semblons être coincés avec .NET Core 1, car passer à 2 (et perdre netstandard) signifierait également que nous ne pouvons pas réutiliser les assemblages dans le application de bureau existante (pour laquelle les services et les bibliothèques associées ont été créés).

Donc, la chose la plus importante pour nous serait de pouvoir toujours utiliser les nouvelles bibliothèques (ASP).NET Core que nous écrivons dans les applications de bureau .NET 4.6 (car c'est pour cela qu'elles ont été conçues), tout en pouvant rester sur un support Version .NET Core tant que la version de bureau .NET est prise en charge, sur laquelle le code peut s'exécuter.

Ainsi, tant que .NET Core 1. est pris en charge comme .NET 4.6, et qu'il existe un chemin de mise à niveau linéaire vers un .NET Core x lorsque .NET 5 sort, et que le code .NET Core x est capable de s'exécuter sur . NET 5, alors tout va bien.

@gingters Utilisez -vous des fonctionnalités .net qui ne sont pas dans netstandard2.0 sur les services asp.net ?

Sinon, les bibliothèques devraient fonctionner. Mais je suppose que vous parlez de choses qui ne sont pas dans netstandard2.0.

@davidfowl Les dll c++/cli fonctionneront-elles sur netcoreapp 2.0 ? Nous avons d'anciens assemblages C++/CLI tiers qui ne seront pas remplacés de sitôt.

@davidfowl a écrit :

ASP.NET Core 2.0 n'a honnêtement pas beaucoup de nouvelles fonctionnalités

Dans ce cas, pourquoi ce changement hautement disruptif maintenant ?

@qrli C++/CLI ne fonctionne pas sur CoreCLR. Voici un aperçu des raisons pour lesquelles il ne sera pas pris en charge : https://github.com/dotnet/coreclr/issues/659#issuecomment -91341753

Donnez 4 ans de support à 1x (portage autant que possible à partir de 2x) et allez-y et vite avec 2x. Une citadine pour la circulation lente en ville et une Ferrari pour les autoroutes. Nous avons beaucoup de concurrence en dehors du monde .net.
Si ASP.Net Core réussit, je suis sûr que MS fournira les ressources nécessaires pour prendre en charge le 1x pendant 4 ans. La plupart du temps, la culture changera.

@ idg10 Ce n'est vraiment pas le cas. 2.x est à peu près 1.x avec des éléments de performance qui ne sont disponibles que dans le noyau. Je pense que la seule caractéristique majeure est Razor Pages.

Donc, être sur la version 1.x ne signifie pas que vous êtes sur une version obsolète. Mais cela n'a pas été très bien communiqué.

Dans ce cas, pourquoi ce changement hautement disruptif maintenant ?

Je suppose que cela le résume à peu près https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

@hallatore
Je sais que cela fonctionne, comme il le fait _maintenant_. Nous pouvons rester sur 1 pour l'instant. Le problème avance. Lorsque nous voulons (ou pire : avons besoin) de mettre à niveau vers les bibliothèques (ASP).NET Core 2 (c'est-à-dire lorsque 1 est hors service et qu'une faille de sécurité critique est corrigée), nous sommes confrontés au problème que nous ne pouvons pas mettre à niveau, car cela rendrait impossible l'utilisation de nos bibliothèques nécessitant les packages mis à niveau dans les applications de bureau .NET.

Modifier/ajouter : à moins qu'il n'y ait un nouveau framework .NET complet capable d'exécuter les nouvelles bibliothèques .NET Core fixes qui se trouvent sur un chemin de mise à niveau linéaire pour l'application de bureau héritée existante.

@gingters Je ne suis pas sûr de comprendre.

Si vos bibliothèques de bureau fonctionnent avec netstandard2.0, elles doivent également fonctionner sur le noyau. (s'ils invoquent des trucs wpf, etc., ils ne le feront pas bien sûr)
Si tel est le cas, vous devriez pouvoir utiliser asp.net core 2.0.

Si vos bibliothèques de bureau se bloquent sur le noyau parce qu'elles utilisent des éléments qui ne sont pas dans netstandard2.0. Ensuite, je vois pourquoi vous devez rester sur 1.x. Et je vois pourquoi le court EOL est un problème.

Est-ce que 1.x serait un choix plus facile/meilleur si vous saviez que 2.x ne contiendrait que des éléments de performance de base (ce qui signifie que 1.x n'est pas obsolète par rapport à 2.x). Et que 1.x recevra des correctifs et sera pris en charge pendant * ans ?

@hallatore C'est l'inverse. Ancienne application : mélange de Windows Forms, WPF, C++/CLI, C++ normal, DirectX, millions de lignes de code, etc. pp, fonctionnant sur le framework complet 4.6.

Sur .NET Core : Nouvelles bibliothèques de logique métier (utilisant également d'autres bibliothèques, c'est-à-dire la version .NET Core de Serilog), bibliothèques d'abstractions + services + bibliothèques clientes pour ces services. Les services doivent s'exécuter sur Linux et en tant que services Windows (actuellement Topshelf sur le framework .NET 4.6 complet, dès que la prise en charge du service Windows atterrit dans Core, cela pourrait cependant être modifié).

Désormais, la nouvelle logique métier et les abstractions ainsi que les bibliothèques clientes de service sont également consommées à partir des applications .NET 4.6. Cela signifie que nous ne sommes pas capables de les mettre à niveau, car ils devront fonctionner sur le framework .net complet aussi longtemps que l'application de bureau le fera (ce qui, nous pouvons le supposer, durera à peu près aussi longtemps qu'un bureau pourra vivre, à moins que le framework complet disparaît en général).

@gingters Vous pouvez toujours avoir les projets de bibliothèque partagée dans votre solution ciblant netstandard _min(usable)_ et consommer ces bibliothèques à partir de votre code ASP.NET Core 2.0 ainsi que les empaqueter pour les utiliser à partir de WPF, Xamarin, UWP, peu importe.

il est vraiment triste que vous, les gars de la SEP, n'ayez toujours pas compris. vous pensez toujours que ce n'est qu'un problème d'écart d'api. vous pensez toujours que les gens peuvent simplement modifier leur code et cela fonctionnera sur netcoreapp ... je pensais que vous compreniez bien mieux les entreprises que google.

Sur cette base, il semble que MVC 5 en mono soit ce que vous vouliez vraiment, n'est-ce pas ?

@davidfowl Je veux dire, allez. C'est une réponse dédaigneuse et franchement insultante. Quelqu'un chez MS peut-il confirmer qu'un seul développeur est encore affecté à Framework ASP ? Je n'essaie pas d'être un imbécile ici, mais il semble que parfois la communauté est méprisée.

Il n'y a aucune raison sous le soleil que je considère .Net Core et ASP.Net Core comme étant le même produit. Il n'y a eu aucun message pour le soutenir. Surtout si l'on considère que Mono est passé sous l'aile de Microsoft _après_ l'annonce de .Net Core. Il a toujours été présenté comme la version xplat plus petite et plus agile de .Net. Non seulement cela, mais nous nous souvenons tous de l'époque où ASP.Net Core était en fait ASP.Net 5 et allait fonctionner partout. Heck, ce changement remonte à un peu plus d'un an et demi seulement.

L'histoire HTTP auto-hébergée dans netstandard20 "utilise-t-elle effectivement Kestrel 1.x" ? Je ne suis pas sûr que les gens de Nancy vont s'en soucier énormément, et moi non plus. sort.

@davidfowl

Il est grand et existe depuis longtemps. Comme tout système hérité, certaines parties sont meilleures que d'autres. Cela ne rend pas le code moins fiable, mais cela rend certaines parties pratiquement impossibles à modifier. Il y a tellement d'histoires amusantes que les vétérans peuvent vous raconter sur la façon dont les corrections de bogues dans un domaine ont brisé des scénarios obscurs dans des applications dans d'autres parties. C'est emmêlé, c'est ce qui arrive quand les limites de dépendance ne sont pas bien définies.

Je pense que c'est un commentaire intéressant. Je me souviens d'avoir regardé un enregistrement d'une session de conférence NDC plus ancienne avec @davidfowl et @DamianEdwards en train de trier le cruft hérité d'ASP.NET 4 que vous vouliez vraiment laisser derrière vous - c'était vraiment fascinant de jeter un coup d'œil à l'intérieur de cette boîte noire de code.

Mais je pense que ce commentaire reflète également les préoccupations que beaucoup d'entre nous ont avec nos propres bases de code. Nous maintenons de grands systèmes hérités, souvent mal conçus avec des limites de dépendance médiocres. Il est pratiquement impossible de réécrire certains de ces systèmes pour .NET Core. L'entreprise ne permettra tout simplement pas le risque d'un tel changement.

Je ne sais pas quelle est la bonne réponse. Mais je sais que pour nos propres applications, nous utiliserons le framework complet et ASP.NET4/MVC5 dans un avenir prévisible (nous avons encore une partie de WebForms qui ne sera pas réécrite avant un certain temps !). J'espère voir MVC5 obtenir un peu d'amour maintenant qu'il est _enfin_ déplacé vers GitHub - je suis même prêt à donner de mon temps et de mes efforts pour l'améliorer (par exemple, un meilleur support asynchrone, des améliorations de performances, etc.).

Les entreprises @qrli ont toujours .NET 4.5 complet à exécuter sur leurs fermes Web Windows Server 2008 R2 IIS 7.5. Personne ne leur enlève ça.

@mattnischan

L'histoire HTTP auto-hébergée dans netstandard20 "utilise-t-elle effectivement Kestrel 1.x" ? Je ne suis pas sûr que les gens de Nancy vont s'en soucier énormément, et moi non plus.

HttpListener fait partie de netstandard20 donc aussi netcore20 rien n'est enlevé sur ce front en allant netcore20.

HttpListener fait partie de netstandard20 donc aussi de netcore20.

Et je suppose que je peux m'attendre aux mêmes requêtes par seconde à partir de HttpListener ?

@markrendle Vrai. Pour le moment.

Mais que suggéreriez-vous lorsqu'une autre bibliothèque utilisée par nos éléments partagés (c'est-à-dire serilog, newtonsoft, autofac, etc.) supprime la prise en charge de netstandard_min (utilisable), (peut-être simplement parce qu'ils estiment que c'est trop d'efforts pour prendre en charge les deux mondes) et un problème de sécurité critique a été détecté dans la dernière version qui prend toujours en charge le framework complet ?

@mattnischan

HttpListener fait partie de netstandard20 donc aussi netcore20.

Et je suppose que je peux m'attendre aux mêmes requêtes par seconde de HttpListener ?

Ok alors, Nancy est .NETStandard 1.6 donc vous pouvez l'utiliser sur Core 2.0 et utiliser Kestrel 2.0. Mieux?

@gingters Je suggérerais de traverser ce pont quand vous y arriverez.

Ne laissez jamais l'avenir vous déranger. Vous l'affronterez, s'il le faut, avec les mêmes armes de la raison qui vous arment aujourd'hui contre le présent.
_~ Marc Aurèle_

Ce n'est pas un mantra aussi utile lors de la livraison d'un logiciel qui n'a pas de budget de maintenance et qui doit être utilisé en grande partie inchangé pour les années à venir.

S'il doit être en grande partie inchangé pour les années à venir, alors pourquoi importe-t-il ce qui arrivera aux bibliothèques dont il dépend dans ces années à venir ?

@markrendle Supposons maintenant que vous êtes tenu, par la loi (au moins dans certains pays), de fournir des protocoles d'urgence pour exactement ces cas, avant qu'une version de l'application ne soit expédiée, car elle pourrait être utilisée dans des environnements où la vie des gens pourrait être en jeu .

Vous voulez donc un serveur Web aussi rapide que Kestrel, et votre seule exigence spécifique est qu'il ne s'agisse pas de Kestrel ?

Ok alors, Nancy est .NETStandard 1.6 donc vous pouvez l'utiliser sur Core 2.0 et utiliser Kestrel 2.0. Mieux?

@markrendle @benaadams Non, je pense que vous comprenez mal, et encore une fois, n'essayez pas d'être un imbécile, soulignant simplement qu'il existe d'autres clients de morceaux d'ASP.Net Core qui ne sont pas tout. J'aimerais juste héberger notre plate-forme de production au-dessus de Kestrel 2.0 lors de sa sortie, et notre plate-forme de production pourrait être sur Framework pendant un certain temps. Je ne peux pas cibler netcoreapp20.

Nancy est peut-être netstandard16 mais cela n'a pas d'importance car je ne peux pas utiliser Kestrel 2.0 sauf sur Core 2.0. Je me rends compte que c'est spécifique, et peut-être que la réponse est vraiment "alors écrivez votre propre serveur Web qui fonctionne sur un framework aussi rapide que Kestrel 2. Kestrel est uniquement pour ASP.Net". Mais je détesterais que ce soit le message.

@gingters @gulbanana Je ne comprends pas comment une application livrée avec un ensemble fixe de dépendances va se casser parce qu'un projet open source cesse de prendre en charge une version arbitraire du framework sous-jacent à une date future putative.

@mattnischan Oui, j'ai compris ce que vous vouliez dire et supprimé ce commentaire :)

@stefanolson

Parce que j'ai besoin de partager du code entre le serveur et mes applications de bureau, cela signifie-t-il que je ne pourrai jamais avoir la dernière version d'ASP.Net ?

Si vous ciblez .NET Standard avec vos bibliothèques, vous pouvez les utiliser à la fois dans Desktop et Core. Pour les bibliothèques ciblant .NET Standard, vous disposez alors d'une prise en charge universelle des plates-formes : Desktop, Core, Mono, Unity, UWP, Tizen, etc.

Une application ASP.NET est un exécutable ; le point final, ce n'est pas une bibliothèque. La sortie finale, l'application/l'exécutable ASP.NET doit s'exécuter sur une plate-forme. Finalement, l'une de ses bibliothèques de plate-forme sera consommée par l'application ASP.NET, il n'y a donc aucun avantage à ce qu'elles ne soient pas la même cible que la plate-forme.

.NET Core est une bonne plateforme car elle a une large couverture multiplateforme ; peut être installé côte à côte avec Desktop et peut être mis à niveau indépendamment application par application ; plutôt que la machine entière et chaque application.

Certains articles ont des utilisations à l'extérieur; donc Wyam utilise Razor pour la génération de sites statiques ; Razor est actuellement .NET Standard 1.3, donc le consommer en dehors de Core n'est actuellement pas un problème.

Il y a quelques cas limites mentionnés ci-dessus :

Utilisation de bibliothèques qui ne prennent pas en charge l'ensemble de fonctionnalités .NET Standard 2.0. Beaucoup d'entre eux sont, espérons-le, des lacunes qui peuvent être comblées - et au début de ce numéro, les États membres demandaient quelles étaient ces lacunes afin de pouvoir les hiérarchiser.

Exécution d'une WebApp intégrée dans, par exemple, une application UWP ; cependant, si Desktop était toujours pris en charge mais passait à la version 4.7.1, vous seriez toujours dans la même situation car UWP ne prend actuellement pas en charge 4.7.1 et au moment où il le ferait, ASP.NET nécessiterait 4.7.2, puis 4.7. 3 etc. Ce serait une tâche de Sisyphe car les autres plates-formes ne l'attraperaient jamais ; donc ce serait juste un travail occupé sans grand intérêt ?

Oui, j'ai compris ce que tu voulais dire et j'ai supprimé ce commentaire :)

Pas de soucis, bon monsieur. 👍

@davidfowl

Comment les versions d'accélération d'ASP.NET Core affectent-elles cela ? Si nous abandonnions la prise en charge de .NET Framework dans la version 3.0 (comme les gens semblent le faire dans ce fil), ne seriez-vous pas dans la même impasse malgré tout ? Votre application ASP.NET Core 2.0 serait portée en cours d'exécution sur le framework pendant un an et lorsque la version 3.0 sortira, vous ne pourrez pas effectuer la mise à niveau. Vous pourrez quand même le faire avec ASP.NET Core 1.1.x qui s'exécute sur .NET Framework et est pris en charge même lorsque ASP.NET Core 2.0 est sorti.

Le simple fait de dire (si je comprends bien) que "parfois, nous avions besoin de rompre avec le .net complet, pourquoi pas tout de suite" manque un point important. Je suis sûr que beaucoup de gens attendaient la sortie du core 2.0. Parce qu'il a publiquement promis de nombreuses améliorations dans la compatibilité avec le .net complet. Tant d'auteurs de bibliothèques attendent également de commencer la migration vers le noyau. Donc je suppose qu'après la sortie du noyau 2.0, nous aurons beaucoup plus de bibliothèques migrées sur Core. Et donc, lier le noyau asp.net au noyau 3.0 serait beaucoup moins frustrant pour l'écosystème qu'il ne l'est actuellement. Parce qu'au moment de la version 3.0, cela devrait moins empêcher les choses de migrer vers le noyau.
En ce moment c'est une catastrophe.

Auparavant, j'évaluais le démarrage de la migration de notre framework (histoire très similaire à ce que @benaadams a décrit) vers le noyau core/asp.net en deux étapes : migrer la partie Web (qui est maintenant sur mvc/webapi) vers le noyau asp.net et rester plein .net, puis migrez tous les autres éléments sur le noyau lorsque toutes les dépendances auront des implémentations correspondantes pour le noyau. Actuellement, ce qui nous bloque, c'est le fournisseur Oracle ADO et le fournisseur Postgres ADO (il pourrait y avoir d'autres incompatibilités dans corefx que nous n'avons pas encore creusées). Maintenant, ce plan est mort. Nous devons donc nous asseoir et attendre la migration des dépendances en abandonnant toutes les nouvelles choses dans le monde Core. Et tout cela est uniquement dû au fait que quelqu'un dans la SP a décidé que nous avions besoin d'une plate-forme "avançant rapidement".

@markrendle L'application ne va pas casser juste à cause de ça. Le problème est différent :
Parce que .NET Core 2 a abandonné la prise en charge du framework complet (où il fonctionnait bien dans la version 1, et c'est de Microsoft où vous ne vous attendez pas à ce qu'une fonctionnalité élémentaire aussi basique soit abandonnée lors de la mise à jour vers une nouvelle version), également votre les dépendances peuvent supprimer la prise en charge de ce scénario plutôt tôt que tard.
Quelqu'un trouve un problème de sécurité critique dans l'une des bibliothèques utilisées, et aucune mise à jour n'est publiée pour la version sur laquelle vous êtes bloqué, car les versions plus récentes ne prennent plus en charge votre environnement d'exécution. Maintenant, puisque votre application est utilisée dans un environnement très réglementé, vous devez fournir un plan d'urgence qui explique exactement ce que vous ferez lorsqu'un problème de sécurité critique est détecté et comment déployer ce correctif pour empêcher les gens de se blesser ou pire. Un "eh bien, nous ne pouvons rien faire" entraînera la révocation de votre allocation pour expédier cette demande.

@gingters Écoutez, le fait est que vous devez faire vos choix technologiques en fonction des informations actuellement disponibles et de la nature du marché sur lequel votre entreprise opère. Avec la meilleure volonté du monde, vous ne pouvez pas tenir compte de toutes les éventualités, même si les bureaucrates et les régulateurs du monde voudraient prétendre que vous le pouvez. Que se passe-t-il si Microsoft est acquis dans le cadre d'une OPA hostile par Apple et que .NET est entièrement abandonné au profit de Swift ? Que se passe-t-il si le cryptage fort est rendu illégal dans l'un des pays que vous vendez et que toutes les piles logicielles qui incluent SHA256 sont interdites ? Et si Nicolas ou James ou _insert-name-of-Autofac-maintainer-here_ décidaient de déménager sur Mars et de devenir des cultivateurs d'humidité ? Et si les pôles magnétiques s'inversent et que chaque bit de données enregistrées numériquement est effacé ?

En tant que réponse réelle à la question de savoir ce que vous, en tant qu'entreprise, dites que vous ferez en cas de détection d'un problème de sécurité critique dans JSON.NET (par exemple), en l'absence d'une mise à jour officielle disponible, le seul la réponse possible est "nous allons bifurquer et corriger JSON.NET", ce qui, je suppose, est déjà la réponse à la question de savoir ce que vous feriez si James Newton-King devenait indisposé pour une raison quelconque. Dans mon expérience précédente de travail sur ce type de marchés, il y avait des accords de dépôt fiduciaire pour le code source vers des packages propriétaires pour ce type d'éventualité ; que faire des packages open source est trivial par rapport à cela.

Et tout cela est uniquement dû au fait que quelqu'un dans la SP a décidé que nous avions besoin d'une plate-forme "avançant rapidement".

"aller vite" pourrait être exagéré ; selon le calendrier de publication précédent de Full Framework, il pourrait être préférable de dire "sans ajouter de délai supplémentaire de 1 à 2 ans" dans l'expédition. C'est une quantité folle de temps dans le monde du Web.

Les choses évoluent rapidement et la plateforme doit rester pertinente.

@davidfowl et @DamianEdwards Je pense que toute cette confusion vient du fait que ASP.NET Core 1.x peut s'exécuter sur .NET Framework. Cela a créé l'hypothèse qu'ASP.NET Core était l'évolution d'ASP.NET 4/MVC5 ; faire migrer les gens vers lui en pensant qu'ils en tireraient tous les avantages (rapidité et nouvelles fonctionnalités) tout en gardant la rétrocompatibilité.

Alors peut-être que la réponse à long terme/permanente à ce problème est de re-promouvoir ASP.NET 4/MVC5 comme la réponse pour les personnes recherchant une compatibilité descendante avec un support à long terme (et peut-être proposer également d'apporter de petites améliorations).

Ensuite, ASP.NET Core peut se concentrer sur une nouvelle plate-forme qui rompt avec le passé pour offrir d'énormes avantages, pour ceux qui peuvent faire le saut.

Dans cette optique, (ASP).NET (Framework) et (ASP).NET Core seront deux routes parallèles et également valables que les clients pourront choisir. Et je pense que c'est ainsi que les choses auraient dû être depuis le début.

@markrendle Oui, c'est hypothétique, mais la bureaucratie est malheureusement une réalité. Et oui, vous ne pouvez pas (et n'avez pas besoin de) tenir compte de toutes les éventualités. Juste pour ceux que vous pouvez anticiper.

Et maintenant, nous avons la situation où a) la suppression d'une plate-forme complète (framework complet .NET), qui était très bien prise en charge dans .NET Core 1, n'était pas quelque chose que vous pouviez anticiper. Cependant, puisque c'est arrivé maintenant, vous pouvez b) anticiper la baisse de la prise en charge de la v1 dans vos autres dépendances avec un "oui, je peux tout à fait voir que cela se produira plutôt tôt que tard".

Et oui, les correctifs de bifurcation et de rétroportage sont l'une des solutions possibles, mais c'est quelque chose que vous voulez éviter autant que possible. Si l'équipe .NET Core avait dit quelque chose comme "Hey. Regardez, nous n'avons pas l'intention de fonctionner sur un framework complet, ne vous fiez pas à cela", ou mieux encore, n'avait jamais rendu cela possible en premier lieu, toute cette discussion ne serait pas nécessaire car le client n'aurait tout simplement pas choisi d'investir dans de nouveaux éléments en plus de .NET Core en premier lieu.

@gingters Je pensais que nous étions au point où vous étiez satisfait d'exécuter vos bits Web ASP.NET Core sur .NET Core 2.x ou version ultérieure, et d'utiliser .NET Standard 2.x pour partager des bibliothèques entre Core et Full/UWP/quoi que ce soit . Parce que si ces bibliothèques devaient abandonner la prise en charge de .NET Standard 2.x au profit de .NET Core 2.x uniquement, elles abandonneraient également la prise en charge de .NET complet, et vous êtes arrosé de toute façon.

@markrendle Jusqu'au point où nous avons un problème critique dans l'un des bits ASP.NET Core que nous devons utiliser dans les éléments partagés après que 1x ne soit plus pris en charge.

@gingters heureusement c'est open source et vous pouvez subvenir à vos besoins (ou payer un tiers) si besoin est !

@markrendle non. les projets purement hérités sont morts. les projets d'entreprise sont généralement une base de code big mix qui contient du code/des bibliothèques datant d'il y a des décennies à de nouvelles versions. être netcoreapp signifie uniquement que vous avez supprimé la possibilité de mélanger. nous ne pouvons donc plus passer à votre nouvelle version sophistiquée, mais nous verrouiller sur l'ancienne version. et les collègues anti-ms me diront avec plaisir "je vous l'avais dit..." et nous pousseront ensuite à migrer vers les solutions google.

Je ne plaide pas pour soutenir netfx pour toujours. mais je pense fermement que netfx devrait être pris en charge par le noyau asp.net pendant au moins 2 ans à partir de maintenant. non seulement 1.x mais aussi 2.x.

@qrli Ces "projets d'entreprise ... une base de code big mix qui contient du code / des bibliothèques datent d'il y a des décennies à de nouvelles nouveautés". sont tout ce qui ne va pas avec les projets d'entreprise et doit s'arrêter. Se plaindre qu'une nouvelle technologie vous empêche de jeter plus de morceaux de boue dans une grosse boule de désespoir maintenue avec des cales, du fil de mise en balles et du déni, c'est comme se plaindre qu'une nouvelle machine de découpe laser industrielle est dotée de dispositifs de sécurité qui vous empêchent de vous pencher et de couper parties importantes de vous-même.

@benaadams

"aller vite" pourrait être exagéré ; selon le calendrier de publication précédent de Full Framework, il pourrait être préférable de dire "sans ajouter de délai supplémentaire de 1 à 2 ans" dans l'expédition. C'est une quantité folle de temps dans le monde du Web.

Les choses évoluent rapidement et la plateforme doit rester pertinente.

Il s'agit d'une limitation politique/organisationnelle et non technique. Regardez comment la JVM / Java évolue. S'ils bougent du tout. Toujours d'actualité, bien plus que .NET ne l'est aujourd'hui. Donc, « aller vite » n'est pas la raison pour laquelle les gens choisissent Java/JVM. Au contraire. Ils choisissent Java/JVM parce qu'il n'a pas tous les inconvénients associés à "l'évolution rapide": c'est une plate-forme stable et fiable, où votre investissement n'est pas gaspillé en 1-2 ans.

Je ne sais pas, si MS veut déplacer .net rapidement, il le fera rapidement. Ils en sont propriétaires, ils peuvent décider quoi faire. Mais les pouvoirs en place ne donnent pas grand-chose à ce sujet : .net full est « assez bon » pour ce qu'il est actuellement.

MS a dormi au volant pendant de nombreuses années et maintenant, tout d'un coup, des choses comme les performances et la pression de la mémoire sont importantes (elles le sont, sans aucun doute), tandis que dans les investissements terrestres JVM dans ces aspects particuliers d'un temps d'exécution ont été faits pour beaucoup ans et ça paye.

Je ne sais pas quelle est la solution, à court terme, mais à long terme, laisser .NET divisé en deux grands départements (.net complet avec windows, .net core avec devdiv) sans terrain d'entente/objectifs autres que le même employeur n'augure rien de bon pour nous, étrangers.

Bien que de nombreux points soient soulevés ici et que chacun essaie de s'assurer qu'il comprend les points de vue des autres, des solutions telles que "les grandes entreprises ne devraient pas être comme ça" ne vont pas aider. Même si vous pouviez les convaincre de cela, il leur faudrait 20 ans pour arrêter d'être comme ça, parce que ce sont de grandes entreprises .

@kolectiv C'est vrai, mais accepter que les entreprises ne vont pas soudainement cesser d'être des entreprises ne signifie pas que vous devez activement encourager/permettre ce type de comportement.

Cela ne devrait pas non plus signifier que _mes_ applications doivent s'exécuter plus lentement et coûter plus cher à héberger.

Exécution d'une analyse de portabilité sur nos bibliothèques très utilisées qui ciblent toujours .NET 4.x sur ASP.NET Core 1.x (EF6, NHibernate, NServiceBus) et l'homme, ces bibliothèques ne sont même pas près de pouvoir cibler netstandard20 .

Lib | %
---------- | ---------
EF6 | 62,74
Hiberner | 67,39
NServiceBus | 65,68

Et encore d'énormes lacunes dans les API manquantes. EF Core a toujours un grand écart avec EF6, et nous utilisons toujours NHibernate lorsqu'il existe des fonctionnalités majeures qui n'existent pas dans EF6. NServiceBus que nous utilisons sur tout projet qui fait de la messagerie.

Ouf.

@markrendle

Ces "projets d'entreprise ... une base de code big mix qui contient du code / des bibliothèques datent d'il y a des décennies à de nouvelles nouveautés". sont tout ce qui ne va pas avec les projets d'entreprise et doit s'arrêter. Se plaindre qu'une nouvelle technologie vous empêche de jeter plus de morceaux de boue dans une grosse boule de désespoir maintenue avec des cales, du fil de mise en balles et du déni, c'est comme se plaindre qu'une nouvelle machine de découpe laser industrielle est dotée de dispositifs de sécurité qui vous empêchent de vous pencher et de couper parties importantes de vous-même.

Ouais mec, disons à ces satanées entreprises et grandes organisations de faire les choses différemment, coupez le fil ! arrêtez l'inondation de boue! Cela les fera se réveiller et écouter. Oh, attendez, cela n'aidera pas, car ils le savent déjà, mais doivent travailler avec beaucoup de choses dont vous ne vous souciez pas ou que vous ignorez pour votre propre argument.

Écoutez, personne ne dit "nouvelle technologie : mauvaise !". Il s'agit de rechercher de nouvelles technologies sans se rendre compte des conséquences qui en découlent. Nous aimons tous travailler avec les éléments les plus récents et ne pas avoir à nous soucier du vieux cru, qui veut ça ? La réalité raconte cependant une autre histoire. Si vous n'avez qu'à travailler avec les derniers morceaux et que vous n'avez pas à vous soucier de la vieille merde, tant mieux pour vous ! Malheureusement, nous, tristes drones de travail dans les tranchées, devons vivre avec une réalité différente. Cela vous conviendrait si vous reconnaissez au moins que pour BEAUCOUP de gens, la réalité n'est que cela, ils ne peuvent pas la changer, ils ne peuvent pas créer un avenir différent, c'est ce avec quoi ils doivent travailler.

@markrendle Je ne suis pas tout à fait sûr de ce que vous suggérez? Abandonner nos 15 millions de lignes de code C# fonctionnel et tout réécrire ? Nous envisagions de passer (lentement) à netstandard 2.0 et, espérons-le, d'avoir accès à des choses comme Span, etc., mais des problèmes comme celui-ci me font douter que ce soit sage.

Nous aimerions le support de Linux, mais cela ressemble plus à une divergence. J'avais supposé que netstandard allait aller de l'avant avec l'implémentation la plus avancée, puis des choses comme le framework se rattraperaient, mais au moins nous saurions que ce serait le cas.

@FransBouma Alors on devrait tous souffrir parce que les Entreprises veulent faire des bêtises ? Je ne devrais pas avoir de belles choses parce que les projets du secteur public de plusieurs millions de dollars ne sont pas encore prêts pour eux ? Comment ça marche?

@markrendle Qu'y a-t-il de stupide à vouloir garder le code fonctionnel?

Ils choisissent Java/JVM parce qu'il n'a pas tous les inconvénients associés à "l'évolution rapide": c'est une plate-forme stable et fiable, où votre investissement n'est pas gaspillé en 1-2 ans.

Et vous pouvez utiliser System.Web pour toujours ; il est intégré à Windows, ce qui signifie qu'il ne disparaîtra probablement jamais. Vous n'obtenez pas beaucoup de stabilité et de fiabilité que cela.

ASP.NET Core 1.x -> ASP.NET Core 2.x ; toutes les API sont à peu près les mêmes, le principal changement est la suppression de la prise en charge de .NET Framework. Ça change même semver pour la pause 😱

ASP.NET Core 1.x s'exécute sur .NET Core 2.x et .NET Framework, prend en charge .NET Standard 2.x (via .NET Core 2.x) ; et a la même apis que ASP.NET Core 2.x, c'est donc la version de tremplin.

ASP.NET Core 2.x est la version de pause. Il prend toujours en charge .NET Standard 2.x (via .NET Core 2.x) et peu de choses ont changé en termes d'API entre ASP.NET Core 1.x et ASP.NET Core 2.x ; mais abandonne .NET Framework.

Une alternative pourrait-elle être :

• ASP.NET Core va de l'avant et travaille vers quelque chose comme netstandard3.0 (pourrait être 2.x) et version netstandard plus rapide. Comme une fois par trimestre.
• La prochaine version de NetFx pourrait sauter à nouveau pour prendre en charge netstandard3.x chaque fois que la prochaine version est. Il n'aurait même pas besoin d'être la norme la plus récente.

Cela peut être une mauvaise idée car tout ce qui est utilisé n'a peut-être pas besoin de faire partie de netstandard, mais au moins ASP.NET Core 2.x ciblerait une norme que les autres frameworks utiliseront éventuellement.

Juste cracher. Je suis sûr que cela a été soulevé.

@bencyoung Je suggère simplement qu'il est un peu égoïste d'insister pour que le monde entier tourne autour de vos 15 millions de lignes de code C # fonctionnel (qui ne va pas cesser de fonctionner, d'ailleurs). Vous ne pouvez donc pas utiliser ASP.NET Core 2.0. Vous avez toujours le framework ASP.NET complet pour Windows uniquement, qui a un support hérité qui le traverse comme Brighton à travers le rock. Il y a donc un nouveau jouet avec lequel vous ne pouvez pas jouer car il n'est pas économiquement viable pour vous de porter votre code et de refactoriser/réarchitecter votre application. C'est nul, mais beaucoup de choses aussi. Mais si Microsoft évite tout ce qui ne fonctionnera pas pour les bases de code héritées préexistantes de deux décennies qui incluent probablement encore des composants COM écrits en VB 6.0, alors dans 20 ans, ils seront Micro Focus.

@adamhathcock C'est ce à quoi je pensais que netstandard était destiné - une approche d'unification, plutôt qu'un plus petit dénominateur commun. Il peut se déplacer aussi vite qu'il le souhaite, mais ce serait un engagement que le framework .NET finirait par rattraper. Finalement, il y aurait un netstandard qui était essentiellement le framework .NET moins les éléments spécifiques à la plate-forme, puis il serait unifié

La prochaine version de NetFx pourrait sauter à nouveau pour prendre en charge netstandard3.x chaque fois que la prochaine version est.

Une mise à jour de .NET Framework est une mise à jour forcée pour chaque machine de la planète exécutant Windows (principalement).

Une mise à jour .NET Core est une mise à jour que vous choisissez d'effectuer pour une application individuelle .

Ce sont des bêtes très différentes.

Eh bien, une chose facile à faire serait d'arrêter de créer un lien vers cette page à partir de la toute première page de la documentation ASP.NET Core .

(Ou ajoutez simplement une ligne "Ne choisissez pas .NET Framework si vous souhaitez continuer à utiliser ASP.NET Core!".)

ils seraient un engagement que le framework .NET finirait par rattraper.

Il y a https://github.com/aspnet/Home/issues/2022#issuecomment -299609207

notre promesse est généralement la suivante : si le type est partagé entre .NET Framework et .NET Core, nous avons l'intention de transférer les membres nouvellement ajoutés vers .NET Framework. Dans de très rares cas, cela pourrait ne pas être possible, mais l'enjeu est qu'ils sont automatiquement pris en compte.

Mais au moment où il rattrape son retard, ASP.NET sera passé à la prochaine version de .NET Standard et ce ne sera jamais la bonne version de .NET Framework pour ASP.NET ; ce serait toujours derrière.

@markrendle non, ce ne sont pas de grosses boules de boue. grand mélange ne signifie pas qu'ils sont mal architecturés. ils sont modulaires. c'est que de nombreux modules sont des codes testés au combat écrits il y a longtemps par des personnes vraiment intelligentes ou achetés à des tiers. certains sont en c, d'autres en fortran, d'autres en c++/cli, etc. pour migrer ou réécrire, nous devons les comprendre, lire des articles, rassembler plus de données de test réelles, retester la nouvelle version. cela demande des efforts mais de telles tâches ne sont jamais budgétées, mais à nous de décider. les gens d'affaires ne se soucient pas que nous utilisions .net core ou non, mais ils veulent que les fonctionnalités soient réalisées. et pour les tiers, nous devons les exhorter ou rechercher un remplacement.
donc, cela peut prendre quelques années dans la pratique.

@benaadams

Et vous pouvez utiliser System.Web pour toujours ; il est intégré à Windows, ce qui signifie qu'il ne disparaîtra probablement jamais. Vous n'obtenez pas beaucoup de stabilité et de fiabilité que cela.

ASP.NET Core 1.x -> ASP.NET Core 2.x ; toutes les API sont à peu près les mêmes, le principal changement est la suppression de la prise en charge de .NET Framework. Ça change même semver pour la pause 😱
ASP.NET Core 1.x s'exécute sur .NET Core 2.x et .NET Framework, prend en charge .NET Standard 2.x (via .NET Core 2.x) ; et a la même apis que ASP.NET Core 2.x, c'est donc la version de tremplin.
ASP.NET Core 2.x est la version de pause. Il prend toujours en charge .NET Standard 2.x (via .NET Core 2.x) et peu de choses ont changé en termes d'API entre ASP.NET Core 1.x et ASP.NET Core 2.x ; mais abandonne .NET Framework.

Oui, et voyons quelles sont vraiment les options :) ASPNET Core 1.x est une impasse : vous pouvez le porter, mais votre code ne peut pas passer au noyau .net si vous dépendez de bibliothèques qui sont .net complètes aujourd'hui et peut ne pas être porté sur .net core/standard à la fin du support. Choisir ASP.NET core 1.x maintenant n'est judicieux que si vos dépendances sont déjà sur netstandard2.0/.netcore, vous pouvez alors passer à asp.net core 2.x sans problème, sachant que vous n'êtes pas dans une impasse.

Votre suggestion de choisir system.web comme alternative à nginx et à une pile JVM si vous voulez avoir de la stabilité est un peu faible, vous ne pensez pas ? :) Il s'agit d'options pour une grande organisation que choisir comme plate-forme. À moins qu'ils ne créent une application complètement nouvelle et qu'ils n'aient pas à fonctionner avec des dépendances extérieures (rares), ils prendront probablement le pari sûr, et pourquoi ne le feraient-ils pas ? S'il s'agit alors de system.web ou JVM/nginx, le choix est assez simple.

Ce sont les petites choses. J'ai déjà martelé dessus: les fonctionnalités de chiffrement des entreprises de serveur sql. Vous n'allez pas les utiliser sur le noyau .net car ils ne sont pas là. Oracle? Nan. Donc, si vous souhaitez utiliser asp.net core et ces fonctionnalités, vous devez utiliser .net full et asp.net core 1.x. Mais que se passe-t-il si ces fonctionnalités ne sont pas portées/disponibles lorsque la prise en charge d'asp.net core 1.x prend fin ? (et qui veut parier la ferme sur une plateforme qui est déjà en 'mode QFE' ?) Retour à system.web ?

Il me semble qu'une partie du problème est qu'ASP.NET est directement à l'origine de l'évolution de .NET Core. Je suppose que c'est une chose interne à Microsoft, mais vraiment la plate-forme et une bibliothèque spécifique ne devraient pas être si étroitement couplées.

Si quelque chose de nouveau doit être ajouté à une version de .NET, il doit être mis à la disposition de tous via un netstandard bump (avec vNext), puis ASP.NET mis à jour pour l'utiliser lors de sa sortie. C'est la position privilégiée d'ASP.NET qui cause ce problème, je pense. Cela peut être inévitable car les groupes de développeurs au sein de Microsoft sont les mêmes...

En tant qu'auteur de logiciels HPC qui utilisent fortement .NET, nous avons également implémenté notre propre analyse d'allocation zéro, etc., sans modifier la plate-forme sous-jacente. Bénéficierions-nous de Span, etc.? Absolument! Pouvons-nous passer à .NET Core ? Pas pour longtemps. Verrons-nous Span etc ajouté à .NET Framework ? Cela semble difficile à dire maintenant sans que ce soit un engagement netstandard...

@markrendle Bien sûr, mais quel est notre plan de transition ? Je ne peux pas en voir un qui ne touche pas des chemins non pris en charge. Si les modifications étaient dans netstandard et que ASP.NET Core les utilisait, nous saurions au moins qu'il y avait un chemin à travers finalement ....

@markrendle Je ne sais pas qui sont les utilisateurs prévus du noyau asp.net. mais ce que j'ai vu, ce sont principalement des utilisateurs de .net qui ont un gros investissement dans .net et une grande base de code héritée (pas mauvaise). si nous ne sommes pas les utilisateurs prévus, je ne vois pas les gars de node.js/python/go donner une merde à .net, peu importe à quel point nous pensons que .net est bon.
si ce n'est pas pour l'entreprise mais pour mes propres projets, je n'utiliserai pas asp mais plutôt nancy. les entreprises ont besoin d'une garantie et d'un soutien stables. et ils / nous payons beaucoup d'argent pour cela.

La solution simple à ce problème serait que Microsoft fasse une distribution Windows uniquement de CoreCLR qui prend en charge la gamme complète de bibliothèques .NET Framework.

Le côté personnel en moi est cool de jouer avec .NET Core sur le PI sur Ubuntu, mais le côté commercial n'a même pas envisagé .NET Core car .NET Framework fait tout ce dont nous avons besoin et .NET Core n'est qu'un problème en comparaison. La plupart de ces problèmes concernaient l'outillage et la configuration de tout le monde afin que ces douleurs disparaissent enfin, mais il manque encore tellement de fonctionnalités ... EF Core n'est même pas près d'être assez moelleux pour remplacer EF6 ou NHibernate et ils ont gagné ne fonctionne pas non plus sur .NET Core 2. Le manque de WCF (hôte) pour les services SOAP est assez lourd, car c'est ce que nous faisons toute la journée dans la communication d'entreprise, mais pourrait probablement être atténué grâce à une conception intelligente et à l'utilisation de .NET Core et .NET Framework dans plusieurs applications. Les AppDomains ne sont pas non plus facilement remplacés bien que ce soit le moindre de mes problèmes. Le passage d'ASP.NET MVC 5 à MVC Core a été étonnamment facile pour une réécriture, mais le passage à .NET Core empêche VS de coopérer, affichant toutes les erreurs.

Des choses amusantes comme l'hébergement d'ASP.NET Core dans WPF seront également impossibles.

Cela n'aurait même pas d'importance si la distribution Windows CoreCLR était une source fermée, car elle n'est pas très différente de .NET Framework aujourd'hui.

Maintenant, excusez-moi pendant que je pleure tranquillement et supprime mes branches expérimentales qui ont été migrées vers ASP.NET Core.

Votre suggestion de choisir system.web comme alternative à nginx et à une pile JVM si vous voulez avoir de la stabilité est un peu faible, vous ne pensez pas ?

C'est la fin extrême ;)

S'il s'agit alors de system.web ou JVM/nginx, le choix est assez simple.

Ouais, si vous pouvez utiliser JVM, vous utilisez ASP.NET Core 2 car vous n'avez pas de bloqueurs et il a une bonne interopérabilité et p/invoking :)

si les apis sont "à peu près les mêmes", pourquoi ne gardez-vous pas une numérotation de version 2x pour tous, mais en ayant la possibilité de sélectionner "netstandard" ou "netcore"?

Parce que ce sont les internes qui changent ; et l'utilisation des modifications apportées aux bibliothèques d'exécution, jit et standard. Pour un utilisateur, ils apparaissent essentiellement les mêmes car c'est là que la compatibilité est entre ASP.NET 1.x et 2.x ; sur la surface exposée de l'api, pas sur les composants internes "voici comment c'est fait".

Il me semble qu'une partie du problème est qu'ASP.NET est directement à l'origine de l'évolution de .NET Core.

Comme d'autres personnes. Vous pouvez faire une requête api sur dotnet/corefx comme je l'ai fait par exemple pour ValueTask ; qui a ensuite évolué en Task-likes et fait maintenant partie de C#7.

Dès que votre API est incluse dans .NET Core, vous pouvez commencer à l'utiliser (si vous optez pour des nightlies et que vous voulez vous assurer que l'API est correcte) ; ou à la prochaine version de coreclr/corefx si vous voulez accrocher 6 mois.

puis ASP.NET mis à jour pour l'utiliser lors de sa sortie.

Maintenant, il faut attendre 2 ans. Ce n'est pas vraiment pratique; car l'API aura besoin d'être affinée par l'utilisation ; et grâce à l'utilisation, plus de découvertes se produiront. C'est comme ajouter une étape de compilation de 2 ans à votre cycle de développement.

En tant qu'auteur de logiciels HPC qui utilisent fortement .NET, nous avons également implémenté notre propre analyse d'allocation zéro, etc., sans modifier la plate-forme sous-jacente. Bénéficierions-nous de Span, etc.? Absolument! Pouvons-nous passer à .NET Core ? Pas pour longtemps.

Votre logiciel HPC est-il directement suspendu aux requêtes Web ? À première vue, il pourrait y avoir des files d'attente pilotées par des requêtes Web, mais il s'exécute dans un processus séparé et ne devrait donc pas être affecté par ce changement ?

Verrons-nous Span etc ajouté à .NET Framework ?

Oui

@benaadams

Mais au moment où il rattrape son retard, ASP.NET sera passé à la prochaine version de .NET Standard et ce ne sera jamais la bonne version de .NET Framework pour ASP.NET ; ce serait toujours derrière.

Ce qui est tout à fait correct et acceptable, s'il y a au moins 1 chevauchement de version (c'est-à-dire que si vous restez sur le dernier framework complet, il y a encore au moins une version officiellement prise en charge (ASP).NET Core qui s'exécute dessus).

Microsoft créerait une distribution Windows uniquement de CoreCLR qui prend en charge la gamme complète des bibliothèques .NET Framework.

Ou un ensemble de bibliothèques .NET Standard 2.0 ; afin qu'ils puissent s'exécuter sur .NET Core, qui ne s'exécute que sur Windows qui couvre l'écart de l'api ?

@benaadams ouais c'est l'idée, bien que cela ne fonctionnera pas pour tout ce qui lance PlatformNotSupportedException

@qrli S'il est modulaire, vous pouvez mettre à niveau les modules qui peuvent être mis à niveau maintenant et laisser le reste à plus tard.

À moins que par "modulaire" vous ne vouliez dire "il s'agit d'une application IIS System.Web ASP.NET monolithique massive comprenant des dizaines de bibliothèques différentes interopérant via PInvoke et COM", auquel cas, c'est une grosse boule de boue.

Existe-t-il une liste définitive des assemblages concernés et de ceux qui ne le sont pas ? Il a été mentionné que Microsoft.Extensions.* est sûr et Microsoft.AspNetCore.Razor.Runtime (supposé) aussi, grâce à quoi Microsoft.AspNetCore.Html.Abstractions doit également rester sur netstandard . Y a-t-il autre chose dans le Microsoft.AspNetCore.* qui reste sur netstandard ?

@bencyoung Mon plan de transition recommandé consiste à migrer divers composants au fil du temps vers des services autonomes ciblant .NET Core 2.x (ou tout ce qui fonctionne le mieux dans tout l'univers des outils de développement pour ce composant particulier), en utilisant ces services à partir de votre code hérité sur une limite d'API standard utilisant HTTP ou un bus de messages, jusqu'à ce que vous ayez une architecture de système distribué appropriée.

@markrendle Cependant, tout n'appartient pas à un système distribué. À titre d'exemple concret : une grande partie de la raison pour laquelle Stack Overflow rend les pages si rapidement est qu'il n'est pas distribué. Bien que la latence de notre réseau soit de 0,017 ms, cela ajouterait un peu de coût de réseau, de sérialisation, de désérialisation et de GC à notre application. Diviser un système en plusieurs services n'est pas une réponse universelle. C'est compliqué, coûteux et négatif pour de nombreux scénarios également. Cela peut être une bonne chose, mais cela peut aussi être une mauvaise chose trop compliquée.

@markrendle mon problème n'est pas celui de la migration vers les services, c'est que certains des éléments fondamentaux de l'infrastructure de service utilisent des API qui ne figurent pas sur la feuille de route pour netstandard20 ou même netstandardbanana . Pour nous, .NET Core ne concerne pas les applications greenfield, mais les systèmes greenfield entiers. System.DirectoryServices est un exemple mais pour d'autres, c'est WCF, et plus d'autres, c'est System.Data et le truc SqlClient, et pour nous, System.Messaging .

Je suis tout à fait d'accord pour utiliser .NET Core quand je le peux. Jusqu'à présent, cela n'incluait aucun projet client, nouveau ou non, ils sont tous bloqués sur quelque chose .

@NickCraver Je ne veux pas être facétieux ou quoi que ce soit, et je sais que la vraie raison pour laquelle les pages SO s'affichent si rapidement est que vous et les autres personnes qui les construisez êtes incroyables, mais les résultats de recherche Google qui incluent des liens vers vos pages s'affichent aussi rapidement que vos pages, et vous _savez_ qu'elles proviennent d'un gros système distribué compliqué. Les pages Amazon s'affichent assez rapidement, même chose. Je suis optimiste sur le fait qu'ASP.NET Core se dirige vers un avenir où il peut être utilisé pour construire des systèmes de la même manière que ceux construits, avec les mêmes performances, et je pense qu'il a de meilleures chances d'y arriver s'il se libère de le cycle de mise à jour tournant sur une petite île de .NET complet.

@jbogard Je vois similaire, mais ce sera très différent lorsque .NET Core 2.0 sera sorti.

Soupir.

@jbogard

filetstandardbanane

citation du fil

Le principal problème avec cela, pour moi et mon équipe, est qu'il n'y avait aucune indication que ce chemin était l'avenir prévu. Je comprends que personne ne connaît l'avenir, mais j'entends que nous devons casser tout ce qui repose sur le framework .net complet (dll de fournisseur de composants, sdks de services de paiement, sdks HSM) dans leurs propres services et introduire ce nouveau saut STINGS. Ce n'est tout simplement pas quelque chose dont ce site avait besoin et maintenant nous devons soit introduire plus de complexité dans les opérations de développement, soit refaire la partie de l'application Web dans MVC 5.

Nous avons opté pour le noyau asp.net pour la vitesse de Kestrel et la nouvelle API sophistiquée. Il aurait été bien de pouvoir peser plus précisément les options par rapport à l'absence d'un chemin de mise à niveau facile compte tenu de nos dépendances.

Ajout à @ jabrown85
ASP.NET Core a été une montagne russe d'émotions jusqu'à présent.
Après l'atterrissage de csproj, j'ai finalement dit "c'est prêt maintenant" et j'ai considéré comme une évidence de commencer quelque chose de nouveau et de vérifier ce qui peut être mis à niveau. Après cette annonce, c'est plutôt : "Est-ce que .NET Core prend définitivement en charge le scénario ou devrions-nous rester en sécurité et rester avec MVC5 ?"

Les pertes sont faibles jusqu'à présent, une seule application écrite en ASP.NET Core qui gère les tâches administratives de l'application MVC 5 principale, mais elle sera bloquée sur 1.x pour toujours car l'application principale utilise NHibernate.

L'ordinateur @markrendle dit non

Ce serait bien s'il y avait une feuille de route pour .NET complet -> netstandard. Certaines des pièces fondamentales indiquent simplement "Non pris en charge" par ApiPort. Je vais exécuter une analyse plus complète des projets clients sur ASP.NET Core 1.x pour voir ce qui manque.

mais il sera bloqué sur 1.x pour toujours car l'application principale utilise NHibernate.

Ça ne devrait pas être le cas, NHibernate n'est pas mort, n'est-ce pas ?

@benaadams étonnamment non. Il y a quelques choses qu'il fait que EF6 n'a vraiment pas d'équivalent. Nous utilisons par défaut EF6 mais il y a des cas où nous devons emprunter la route NH.

@benaadams officiellement non, il y a des pauses où il semble presque mort mais généralement il y a un commit tous les quelques jours. ApiPort rapporte une couverture de 72,26% pour .NET Standard mais je ne suis pas vraiment convaincu qu'il sera porté (du moins dans un avenir proche).

En lisant les commentaires, je suis préoccupé par la direction générale que prend ce projet. Pendant longtemps ASP.NET était un bon choix pour une technologie stable et solide. Cependant, je n'ai pas le même sentiment maintenant. Il existe de nombreuses technologies « se déplacer rapidement et casser des choses », mais c'est une toute autre catégorie.
J'espère que Microsoft sera en mesure de répondre à ces préoccupations et d'aligner les attentes de chacun.

Il ne s'agit pas de logiciels d'entreprise ou non. De nombreuses applications Python 2.x sont utilisées aujourd'hui et toutes ne sont pas "d'entreprise". De plus, tous les nouveaux projets n'utilisent pas Python 3 (presque 9 ans après la sortie de Python 3.0 !).

Quelqu'un peut-il résumer l'ensemble du fil dans un article de blog ?

J'ai lu les plus de 300 commentaires lors de mes déplacements / déjeuners et ... il me semble toujours que je ne comprends toujours pas complètement.

Ce que j'obtiens c'est :

• Le .NET Framework complet ne sera pas pris en charge sur .NET Core 2
• Chaque dépendance dépendra de netcoreapp2.0 au lieu de netstandard2.0
• Si je veux quelque chose comme DirectoryServices ou Drawing, je dois supprimer Full Framework et passer à 2.0

Le reste m'a en quelque sorte manqué... un emploi du temps chargé et tout.

@MaximRouiller

Si je veux quelque chose comme DirectoryServices ou Drawing, je dois supprimer Full Framework et passer à 2.0

Non, si vous souhaitez une bibliothèque qui ne prend pas en charge .net core, vous ne pourrez pas du tout utiliser AspNet Core 2.0+.

@MaximRouiller , ce qu'ils viennent de faire, c'est que les projets principaux d'Asp.Net ne pourront pas référencer les assemblages de framework complets, ce qui le rendra inutile pour beaucoup, sinon la plupart, ils disent que des assemblages comme system.drawing et Directoryservices seront portés sur le nouveau netstandar ou je ne sais pas, encore, les anciens assemblages ne fonctionneront pas à moins que quelqu'un ne les porte, donc, c'est à peu près inutile pour beaucoup car certains assemblages sont hérités et ne seront jamais portés. En conclusion, quiconque utilisait .net core avec la version complète du framework .NET vient de se faire avoir et doit revenir à MVC 5.

@davidfowl Merci pour cette liste au fait. C'est le très important "alors qu'est-ce qu'on en retire ?" pièce nécessaire pour que les gens équilibrent le coût/bénéfice dans leur esprit.

Si vous ne l'avez pas déjà fait, lisez la liste afin d'être informé des deux côtés. Je tiens toujours à ce que 2.x soit une version de transition (avec des avantages justifiables pour l'entreprise pour justifier réellement le déménagement), et 3.x étant là où se trouvent les gains. Même s'il est sorti 2 jours plus tard. J'apprécie vraiment la perspicacité de tous les côtés.

@davidfowl tu as dit :

Les bibliothèques peuvent être écrites au-dessus de la norme. Lorsque les choses dans la norme elle-même doivent changer, il faudra beaucoup plus de temps pour être adoptées dans toutes les implémentations de .NET et cela inclut .NET Framework. Cela peut signifier plusieurs choses :
.NET Standard évoluera au rythme de la mise en œuvre la plus lente
.NET Standard évoluera à un autre rythme et .NET Framework sera le dernier à rattraper son retard.

Mais pourquoi est-ce le cas ? Ne pouvez-vous pas publier .NET Standard vNext et faire en sorte que .NET le rattrape quelque temps plus tard (quelques mois à un an plus tard) ? Cela signifie que les personnes qui sont à la pointe de la technologie et qui veulent le dernier ASP.NET Core peuvent héberger dans .NET Core, et les personnes qui ont besoin de .NET pour leur code hérité peuvent éventuellement utiliser cette version d'ASP.NET Core une fois que .NET aura rattrapé son retard. à la version .NET Standard qu'il utilise. Je ne comprends pas pourquoi .NET Standard doit être accéléré aussi rapidement que l'implémentation la plus basse.
Ici aussi, nous parlons d'implémentations officielles de la norme, mais il y aura d'autres implémentations qui ne seront pas mises à jour en même temps que la norme.
De cette façon, vous ne laissez personne derrière vous. Bien sûr, ils mettent un peu plus de temps à bénéficier des dernières fonctionnalités s'ils sont en .NET, mais ils ne sont pas bloqués pour toujours.

@jdom parce que je connais la vitesse à laquelle .NET Framework change et pourquoi il doit être lent. C'est une distribution différente et peut-être qu'il n'y a pas assez d'appréciation pour cela. Tout changement est appliqué à des milliards de machines. La superposition est également complètement différente, ce n'est donc pas une chose triviale à raisonner.

Je ne comprends pas pourquoi .NET Standard doit être accéléré aussi rapidement que l'implémentation la plus basse.

Si nous continuons à augmenter le filigrane bas pour la norme .net dans ASP.NET Core, cela va à l'encontre de l'objectif et vous laisse dans la même situation. Bien sûr, vous ne vous sentez pas laissé pour compte car il est promis qu'un jour ces API arriveront sur .NET Framework, mais dans quel délai ? .NET 4.7 ne complète toujours pas la parité des fonctionnalités avec .NET Standard 2.0.

@davidfowl mais cela ramènera le même problème qu'avec les PCL, cela deviendra le plus petit dénominateur commun et une douleur à utiliser, le fait qu'ASP.NET abandonne son utilisation le montre déjà.

@davidfowl mais cela ramènera le même problème qu'avec les PCL, cela deviendra le plus petit dénominateur commun et une douleur à utiliser,

@Suchiman comment est-ce un problème? Le seul problème avec les PCL était la façon dont ils étaient calculés et représentés dynamiquement dans NuGet, ce qui rendait difficile de prédire ce que vous alliez obtenir. Sinon, comment netstandard fonctionnerait-il s'il ne s'agissait pas d'un ensemble d'API pouvant être implémenté par différentes implémentations ?

Ce qui rendait les PCL ennuyeux à utiliser, c'était la petite surface API super duper. .NET Standard 1.3-1.4 est suffisant pour implémenter la plupart des bibliothèques de base en termes d'API.

.NET Standard a toujours été une question d'étendue.

ASP.NET Core et .NET Core concernaient une pile de serveurs multiplateforme compétitive pour la création de microservices légers. Le souffle dans ce sens était un support de plate-forme plus large (fonctionnant sur linux, osx, tizen, pi, etc.).

@davidfowl

Nous avons identifié les chaînes comme l'une des principales choses que nous aimerions essayer de résoudre dans .NET Core, il y a des tonnes d'idées mais l'une d'entre elles est d'avoir la chaîne en utf8 par défaut (des tonnes de problèmes de compatibilité mais suivez-moi ici).

Une autre chose que nous aimerions corriger est la possibilité de prendre des tranches bon marché de tableaux/chaînes, n'importe quel morceau de mémoire contiguë. Nous avons ajouté l'étendueet regardent Bufferpour représenter cela. Cela peut signifier que String et Array implémentent de nouvelles interfaces qui permettent de prendre une tranche nécessitant une allocation 0.

Il semble que cela signifie que si je veux utiliser ces nouveaux bits dans une bibliothèque, la bibliothèque devra également cibler netcoreapp2.0 au lieu de netstandard2.0 . Est-ce exact?

C'est vraiment une mauvaise idée de ne plus supporter l'ancien framework 4.x. Les gens ne mettent pas à niveau si cela cause beaucoup de travail. Voir le super vieux classique ASP, obsolète depuis 2002 - environ 15 ans. Et nous avons d'anciennes applications qui existent toujours en ASP classique ! Microsoft aime-t-il revoir quelque chose de similaire ? L'abandon de l'ancien support 4.x est quelque chose qui doit être fait obligatoirement - mais à long terme ! Pas maintenant. Cela peut être une option dans quelques années, lorsque le noyau .NET est la norme de facto et que seules les anciennes applications utilisent le net 4.x.

L'idée derrière (ASP).NET Core est vraiment géniale, la meilleure chose que Microsoft ait faite depuis la sortie de .NET. Mais un tel chaos émousse ce joli concept. Il est également très triste que Microsoft décide de lui-même des changements aussi massifs, sans même en discuter avec la communauté ! On dirait que cette entreprise n'a pas encore complètement appris à gérer des projets open source.

@davidfowl

.NET Standard a toujours été une question d'étendue.

Étendue des API ou des plates-formes ?

Quel est le problème avec l'évolution .netstandard au même rythme que .netcoreapp ?
L'une des cibles de réglage BCL est-elle spécifique à .netcoreapp car elle ne sera jamais implémentée dans les autres frameworks ?

Libérer .netstandard2.1 en même temps que .netcoreapp2.1 ne fait aucune différence que de publier .netcoreapp2.1 d'abord et un an plus tard .netstandard2.1 en même temps que .net50 , sauf que les packages ciblant .netstandard2.1 commenceront immédiatement à fonctionner sur .net50 mais seront bloqués s'ils ciblent .netcoreapp2.1

ASP.NET Core est un framework d'applications Web de haut niveau construit sur .NET Core et ciblera à l'avenir .NET Core, _cependant_ il peut également s'agir d'un framework d'applications Web de haut niveau construit sur .NET Standard à la place, de sorte qu'il cible une interface API de référence plutôt qu'une implémentation spécifique de celle-ci.

Le positionnement public de .NET Standard est une cible facile à atteindre tout en laissant de côté les détails de mise en œuvre - avec 2 frameworks officiels directement de Microsoft pour couvrir la plupart des cas d'utilisation.

Pourquoi changer cette histoire maintenant ? Si le .NET Framework ne rattrape jamais son retard, cela semble être hors de propos. Au moins, il est possible que ce soit le cas, ou qu'un autre framework tiers puisse le faire. Et s'il n'y avait qu'une seule mise en œuvre qui suivait le rythme de manière réaliste ? C'est exactement pourquoi nous avons des interfaces dans nos applications même s'il n'y a qu'une seule implémentation concrète, afin que nous ayons la flexibilité et les avantages que cela apporte.

Peut-être réduire la portée d'ASP.NET Core 2.0 en ligne avec .NET Standard 2.0, puis utiliser .NET Standard 2.1 pour les nouvelles fonctionnalités ? Ajoutez des délais de support décents et cela ne résoudrait-il pas tout ce dilemme ? Microsoft possède le .NET Standard et les deux frameworks donc cette crainte d'incrémenter les versions semble totalement infondée...

Je suppose qu'il faut considérer que ASP.NET vers ASP.NET Core n'est pas le chemin de migration pour tout le monde.

ASP.NET sur le framework complet restera et obtiendra des fonctionnalités mais pas comme Core.

La migration deviendra plus facile avec le temps, mais ne sera jamais une correspondance à 100 %.

Les gens utilisent toujours l'ASP classique. C'est bien pour eux aussi.

@davidfowl J'ai un immense respect pour toute l'équipe et les progrès que vous faites tous. Donc, s'il vous plaît, ne prenez pas cela comme étant sur ce qui se passe. Vous êtes des pionniers, et nous vous considérons tous comme des exemples sur la façon de bien faire les choses. Mais je ne vois pas beaucoup de ces points comme des problèmes immédiats de changement de cible, surtout lorsqu'ils n'ont pas été communiqués. J'ai peut-être tort.

Je veux jeter des trucs fous ici parce que ça a été mentionné plusieurs fois. Ce que je m'apprête à dire n'a aucune incidence sur ce qui va se passer, ce ne sont que des spéculations à ce stade. Plusieurs personnes ont demandé pourquoi nous voulions cibler .NET Core au lieu de .NET Standard.

• Nous avons identifié les chaînes comme l'une des principales choses que nous aimerions essayer de résoudre dans .NET Core, il y a des tonnes d'idées mais l'une d'entre elles est d'avoir la chaîne en utf8 par défaut (des tonnes de problèmes de compatibilité mais suivez-moi ici).

Ce point ici changerait certainement la donne, mais IMO c'est le seul qui ne nécessite absolument pas de framework de ciblage, et ce n'est pas pour netcoreapp20 de toute façon.

• Une autre chose que nous aimerions corriger est la possibilité de prendre des tranches bon marché de tableaux/chaînes, n'importe quel morceau de mémoire contiguë. Nous avons ajouté l'étendueet regardent Bufferpour représenter cela. Cela peut signifier que String et Array implémentent de nouvelles interfaces qui permettent de prendre une tranche nécessitant une allocation 0.
• Cela conduit à de nouvelles méthodes sur String qui permettent un fractionnement qui n'alloue pas un tableau à chaque fois.
• Cela conduit à des surcharges vers Int, UInt etc (TryParse) qui prennent Spanet durée.
• Cela conduit à de nouvelles routines d'encodage qui prennent Span.
• Amortiret duréevous permettent de représenter la mémoire de manière uniforme et nous souhaitons mettre à niveau la pile réseau pour permettre le passage de tampons pré-épinglés qui prennent Spanou Tampon.

Tout cela est toujours implémentable en tant que packages en plus du netstandard actuel. Vous n'avez même pas besoin de netstandard20 pour cela. Je comprends que je ne veuille pas transporter ce bagage, mais le reste d'entre nous dans le monde non MS doit créer des implémentations BCL-esque personnalisées tout le temps lorsque le cas d'utilisation ou les performances ne correspondent pas. Sans oublier que l'API Span n'est pas non plus ciblée pour 2.0 (sauf si cela change à nouveau).

Kestrel implémentera HTTP2 dans la période 2.x (visant actuellement à 2.1) et cela nécessite de nouvelles API sur le flux SSL pour faire ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Negotiation).
Le client Http sur .NET Core prend en charge le streaming duplex, il permettra d'implémenter des points de terminaison de streaming sur http dans signalr sur une seule requête http non websocket.

J'ai l'impression que celui-ci est un peu plus délicat, mais pas si différent de Kestrel transportant libuv. L'implémentation CURL de .Net Core peut être facilement insérée dans un package d'extension netstandard jusqu'à ce que tout le monde rattrape son retard.

• Nous avons dérivé les implémentations de l'analyseur d'en-tête de HttpClient et System.Net.Http et les avons renommés (https://github.com/aspnet/HttpAbstractions/tree/d1d9bceff56cb44a194ae36923ce687e5e353006/src/Microsoft.Net.Http.Headers) afin que nous puissions les améliorer et faites-les prendre en charge à la fois .NET Framework et .NET Core. .NET Core a une copie de ces améliorations qui n'a pas été récupérée car il n'est pas nécessaire de les améliorer (nous ne pouvions pas les consommer).

D'accord, mais c'est sans doute la bonne façon de procéder dans ce cas. Frustrant d'attendre et de s'accrocher aux implémentations, mais encore une fois, je ne vois pas en quoi cela est différent de ce que font les autres lorsqu'ils écrivent un framework ou une bibliothèque.

• Sans la possibilité de reviser les primitives de base, nous sommes encouragés à les bifurquer et à créer des choses qui leur ressemblent mais qui n'en sont pas. C'est la raison pour laquelle nous avons notre propre petit BCL dans ASP.NET Core https://github.com/aspnet/Common/tree/dev/src/Microsoft.Extensions.Primitives.

Encore une fois, tout comme le reste d'entre nous.

ASP.NET Core et .NET Core concernaient une pile de serveurs multiplateforme compétitive pour la création de microservices légers.

ASP.Net Core avait des messages comme ça. .Net Core a été annoncé dès le premier jour comme un sous-ensemble de framework .Net côté serveur xplat entièrement fonctionnel. Je n'ai jamais entendu quelqu'un dire que .Net Core est réservé aux microservices. J'ai entendu dire que vous pouvez l'utiliser avec ASP.Net Core si vous le souhaitez, mais également avec des applications de console, des analyses de données, des services de base de données, etc.

ASP.NET sur le framework complet restera et obtiendra des fonctionnalités mais pas comme Core.

Est-ce que cela va? Je n'ai toujours vu personne de MS confirmer qu'il est toujours en cours d'élaboration. Mon instinct me dit que ce n'est pas le cas. Je comprends. L'équipe a besoin d'un moment de type "bougez-le ou perdez-le" pour se libérer. Je ne pense pas que ce soit encore ce moment.

En supposant que nous ayons un assemblage de logique métier 4.6, qui utilise le pilote Oracle.Net, le NHibernate et le RabbitMQ (tous en 4.6). L'interface avec ASP.Net se fait uniquement via nos objets métier, requêtes et réponses. Peut-on référencer cet assembly dans notre ASP.Net Core 2, sans recompiler ?

Mon petit résumé

@ stefan2410 réponse courte, non, vous ne pouvez pas référencer le cadre complet, vous ne pouvez référencer ces assemblages que s'ils sont créés pour le netstandar 2.0.

@mattnischan

Tout cela est toujours implémentable en tant que packages en plus du netstandard actuel. Vous n'avez même pas besoin de netstandard20 pour cela. Je comprends que je ne veuille pas transporter ce bagage, mais le reste d'entre nous dans le monde non MS doit créer des implémentations BCL-esque personnalisées tout le temps lorsque le cas d'utilisation ou les performances ne correspondent pas.

Je suis désolé mais ce n'est vraiment pas le cas. Vous ne pouvez pas singer les types de patchs. Sauf si vous nous suggérez d'ajouter de nouveaux types et de ne pas modifier ceux qui existent déjà.

Sans oublier que l'API Span n'est pas non plus ciblée pour 2.0 (sauf si cela change à nouveau).

Span existe dans la version 2.0 en tant qu'implémentation, mais pas en tant qu'API publique. Nous apportons des modifications radicales aux nouvelles versions majeures afin de pouvoir proposer davantage de fonctionnalités dans les versions mineures. Si ASP.NET Core 2.1 ciblait .NET Standard 2.1, la prise en charge de .NET Framework est à nouveau abandonnée.

J'ai l'impression que celui-ci est un peu plus délicat, mais pas si différent de Kestrel transportant libuv. L'implémentation CURL de .Net Core peut être facilement insérée dans un package d'extension netstandard jusqu'à ce que tout le monde rattrape son retard.

Donc, ce que vous dites, c'est que nous devrions renommer toutes les classes de la BCL afin de pouvoir les utiliser sur les deux standards .NET.

Je n'ai jamais entendu quelqu'un dire que .Net Core est réservé aux microservices. J'ai entendu dire que vous pouvez l'utiliser avec ASP.Net Core si vous le souhaitez, mais également avec des applications de console, des analyses de données, des services de base de données, etc.

Non, .NET Core est un framework à usage général qui n'avait à l'origine aucun secteur vertical en son cœur. Il est possible que ASP.NET Core aurait dû être une verticale au lieu de bibliothèques au-dessus de .NET Core, cela aurait peut-être évité une partie de cette confusion.

Est-ce que cela va? Je n'ai toujours vu personne de MS confirmer qu'il est toujours en cours d'élaboration. Mon instinct me dit que ce n'est pas le cas. Je comprends. L'équipe a besoin d'un moment de type "bougez-le ou perdez-le" pour se libérer. Je ne pense pas que ce soit encore ce moment.

Oui, la prise en charge de HTTP/2 a été ajoutée dans la dernière version. Une autre équipe travaille sur ASP.NET et IIS et apporte des améliorations. Cependant, ils ne sont pas à la même échelle que ce que fait ASP.NET Core.

Je n'ai pas de sentiments très forts à ce sujet car j'ai évité d'exécuter mes services ASP.NET Core sur un framework complet comme la peste. Cela étant dit, j'ai dû éviter d'utiliser des bibliothèques agréables et matures car elles ne prenaient pas en charge .NET Standard car elles attendaient netstandard2.0 ou simplement parce qu'elles ne le voulaient pas.

Ma crainte est que la suppression de la possibilité d'exécuter ASP.NET Core sur un framework complet dissuadera les utilisateurs de porter leurs applications MVC 5/Web API 2 actuelles sur ASP.NET Core, ce qui fournira simplement une autre raison aux auteurs de bibliothèques d'éviter le portage vers .NET Standard. Pourquoi s'embêter à faire le travail de mise à niveau si aucun de vos utilisateurs n'en bénéficiera ? Cela devient un problème de poules et d'œufs et j'ai juste peur que cela nuise à l'écosystème dans son ensemble juste au moment où il a commencé à prendre de l'ampleur. Vous avez d'abord besoin d'utilisateurs ASP.NET Core et je ne suis pas convaincu qu'il y en ait autant que nous le souhaiterions tous. J'espère que je me trompe.

Si ASP.NET Core 2.1 ciblait .NET Standard 2.1, la prise en charge de .NET Framework est à nouveau abandonnée.

Non, cela signifie simplement que Net Framework prendra automatiquement en charge ASP.NET Core 2.1 dès qu'il prendra en charge .NET Standard 2.1, quel que soit le cas, même si cela prend un an ou deux.

Idem pour toutes les autres plateformes compatibles .NET Standard (Xamarin / Unity / ...).

Construire sur .NET Standard signifie que d'autres plates-formes s'allumeront _éventuellement_, s'appuyer sur .NET Core signifie qu'elles ne s'allumeront __jamais__.

Je suppose que le plan est toujours que full-fx rattrapera netstandard, même si avec un long retard?
(et si aucune autre plate-forme, à l'exception de NET Core, ne devrait implémenter .NET Standard 2.1, alors pourquoi même avoir un .NET Standard ?)

Je suis désolé mais ce n'est vraiment pas le cas. Vous ne pouvez pas singer les types de patchs. Sauf si vous nous suggérez d'ajouter de nouveaux types et de ne pas modifier ceux qui existent déjà.

Ce dernier est ce qui a déjà été fait dans la plupart des cas dans 1.x, n'est-ce pas ? N'est-ce plus tenable du coup ?

Span existe dans la version 2.0 en tant qu'implémentation, mais pas en tant qu'API publique. Nous apportons des modifications radicales aux nouvelles versions majeures afin de pouvoir proposer davantage de fonctionnalités dans les versions mineures. Si ASP.NET Core 2.1 ciblait .NET Standard 2.1, la prise en charge de .NET Framework est à nouveau abandonnée.

Pourquoi serait-il abandonné ? Êtes-vous en train de dire que Span n'existera _jamais_ sur Framework ?

Donc, ce que vous dites, c'est que nous devrions renommer toutes les classes de la BCL afin de pouvoir les utiliser sur les deux standards .NET.

Ouah, non. Je dis que si j'ai besoin d'un dictionnaire avec une API différente, je dois créer autre chose et ne pas l'appeler System.Collections.Generic.Dictionary, comme vous l'avez déjà fait avec Microsoft.Net.*

Oui, la prise en charge de HTTP/2 a été ajoutée dans la dernière version. Une autre équipe travaille sur ASP.NET et IIS et apporte des améliorations. Cependant, ils ne sont pas à la même échelle que ce que fait ASP.NET Core.

C'est juste. Je n'étais pas au courant de ça.

Ce dernier est ce qui a déjà été fait dans la plupart des cas dans 1.x, n'est-ce pas ? N'est-ce plus tenable du coup ?

Cela crée un gâchis. Ils ont essayé de le faire le moins possible. La conception et le déploiement de l'API sont tellement plus compliqués que la plupart des gens ne le pensent, je pense. Et ce ne sont pas les gars de Microsoft qui le font de cette façon, c'est la réalité de la prise en charge de nombreuses plates-formes et délais. Je n'ai pas apprécié cela jusqu'à ce que je sois au milieu de cela plusieurs fois et que je parle de tout. Je souhaite vraiment que le transfert de type soit au niveau de la méthode, cependant. Cela aurait résolu pas mal de cas jusqu'à présent :(

Pourquoi serait-il abandonné ? Êtes-vous en train de dire que Span n'existera jamais sur Framework ?

Il devrait être supprimé de ASP.NET Core 2.0 , car les délais ne s'aligneraient plus, car le cadre complet ne l'aurait pas encore .

Il devrait être supprimé d'ASP.NET Core 2.0, car les délais ne s'aligneraient plus, car le cadre complet ne l'aurait pas encore.

AFAIK, les étendues font partie d'un package netstandard1.x qui peut être utilisé sur .NET Desktop (il s'agit d'une implémentation portable, elle n'a donc pas le même boost de performances que si elle était sauvegardée dans le CLR, mais il est probable assez bien).

Modifier : le package System.Memory a un TFM netstandard1.0 , il peut donc être utilisé même sur .NET 4.5.

Ce dernier est ce qui a déjà été fait dans la plupart des cas dans 1.x, n'est-ce pas ? N'est-ce plus tenable du coup ?

Nous arrêtons le travail sur les fonctionnalités dans certaines directions aujourd'hui à cause de cela. C'est intentionnel et nous nous retenons et refusons d'utiliser de nouvelles API en copiant et en réimplémentant des éléments en dehors de .NET Standard afin que .NET Framework puisse fonctionner. Ce n'est pas tout, mais il y a des éléments fondamentaux que nous aimerions aborder à l'avenir, après tout, nous (Microsoft) contrôlons les deux côtés.

Pourquoi serait-il abandonné ? Êtes-vous en train de dire que Span n'existera jamais sur Framework ?

Span lui-même a une version portable qui s'exécute n'importe où, je ne suis pas sûr que l'implémentation rapide sera un jour sur .NET Framework. Les API qui seront ajoutées à .NET Framework qui tirent parti de Span peuvent prendre beaucoup plus de temps que Span lui-même, c'est vaste. À quand remonte la dernière fois que nous avons modifié une chaîne et un tableau dans .NET Framework ?

Ouah, non. Je dis que si j'ai besoin d'un dictionnaire avec une API différente, je dois créer autre chose et ne pas l'appeler System.Collections.Generic.Dictionary, comme vous l'avez déjà fait avec Microsoft.Net.*

C'est exactement ce que vous suggérez. Nous ne voulons pas avoir un Microsoft.Extensions.Collections.Generic. Nous faisons de notre mieux pour éviter cela et nous vivons avec les anciennes API et polyfill lorsque cela est possible (https://github.com/aspnet/DependencyInjection/blob/139d91e57dd31fcd5c6ddaf11ad1f771b5855807/src/Microsoft.Extensions.DependencyInjection/Internal/ConcurrentDictionaryExtensions.cs). Ce n'est pas durable et cela signifie que .NET Core n'obtient pas les avantages car nous évitons activement de l'utiliser.

@PinpointTownes avoir des étendues n'est pas suffisant, ils doivent les utiliser dans les appels de méthodes aux types existants. C'est alors que le transfert de type au niveau de la classe entre en jeu et pose de nombreux problèmes.

@0x53A

C'est juste. Pouvez-vous me dire pourquoi les bibliothèques populaires sur NuGet n'abandonnent pas la prise en charge des anciennes versions de .NET Framework qui ne sont clairement pas prises en charge ? Les bibliothèques les plus populaires ciblent net20, net35, net40, etc. Pourquoi serait-il soudainement acceptable d'exiger la version la plus élevée de .NET Framework pour continuer à utiliser ASP.NET Core ? Pensez-vous que ce serait raisonnable?

C'est un show-bouchon. Je dois envisager d'annuler les migrations depuis ASP.NET MVC 5/Web Api 2 vers Core. De nombreux frameworks stables ne sont pas encore disponibles pour le noyau. Nous utilisons toujours EF6.x car EF Core n'est pas assez mature Comparaison des fonctionnalités .

@PinpointTownes avoir des étendues n'est pas suffisant, ils doivent les utiliser dans les appels de méthodes aux types existants.

"besoin" est probablement un peu excessif. Les étendues sont principalement utilisées pour les performances, donc rien ne les empêche d'utiliser les surcharges non super performantes existantes sur .NET Desktop à l'aide d'ifdefs jusqu'à ce que .NET Desktop obtienne une prise en charge native des étendues.

@davidfowl Je pense que le gros problème est émotionnel. Si vous ciblez netstandard, je sais que je pourrai éventuellement passer de 1.x à 2.x (même avec un retard). La plupart du temps, la mise à jour de netfx n'est pas un gros problème pour une application (différent pour une bibliothèque).

Mais certaines applications ne pourront jamais faire le saut netfx -> netcore, donc si vous ciblez netcore, elles savent qu'elles sont dans une impasse avec 1.x.

À cet égard, il aurait été préférable que le noyau Asp.net n'ait jamais fonctionné sur netfx, dans l'état actuel des choses, ils s'attendaient à ce que cela continue et se sentent maintenant (à juste titre, IMO) trahis. Après tout, ils ont peut-être déjà investi beaucoup de temps là-dedans.

Je ne suis pas personnellement investi là-dedans, car je ne suis pas un utilisateur asp.net, ma grande question est en fait juste

Je suppose que le plan est toujours que full-fx rattrapera netstandard, même si avec un long retard?
(et si aucune autre plate-forme, à l'exception de NET Core, ne devrait implémenter .NET Standard 2.1, alors pourquoi même avoir un .NET Standard ?)

En ce qui concerne les autres bibliothèques ciblant net20, net35, etc., d'après mon expérience, la plupart des auteurs essaient de cibler la version la plus basse possible et ne coupent que les plates-formes où ils n'ont pas d'autre choix.

Et __oui, je pense qu'il est raisonnable d'abandonner la prise en charge des anciennes versions de .NET Framework__, car il existe toujours un chemin de migration clair disponible. Mettez simplement à jour votre version. La plupart du temps, vous n'avez même pas besoin de changer quoi que ce soit, "juste" recompilez et testez.

Je pense que vous sous-estimez sérieusement le nombre d'applications qui ne pourront jamais cibler netcore - une seule dépendance tierce à source fermée suffit à bloquer cela.

Span lui-même a une version portable qui s'exécute n'importe où, je ne suis pas sûr que l'implémentation rapide sera un jour sur .NET Framework. Les API qui seront ajoutées à .NET Framework qui tirent parti de Span peuvent prendre beaucoup plus de temps que Span lui-même, c'est vaste. À quand remonte la dernière fois que nous avons modifié une chaîne et un tableau dans .NET Framework ?

@davidfowl Je pense que cela fait peut-être partie du problème. Honnêtement, j'ai un peu joué l'avocat du diable ici, parce que nous sommes coincés au milieu en tant qu'application greenfield qui a commencé juste avant que .Net Core ne soit une chose, donc nous chevauchons la ligne.

Notre pensée a toujours été d'utiliser les nouvelles bibliothèques sophistiquées (telles que Kestrel) si possible, mais d'attendre que .Net Core se stabilise (et je suis content que nous l'ayons fait, ne serait-ce que pour les changements d'outils), _ou_ attendez le cool Core bits pour revenir à Framework. Je pense que la plupart des gens ont supposé que la plupart, sinon la totalité, des progrès réalisés par corefx se retrouveraient dans Framework vNext ou vNext+1. Mais, il semble (de notre point de vue de 30 000 pieds) à partir de cela et d'autres changements que Framework n'est pas une plate-forme du futur.

Je suppose que si c'est comme ça, c'est comme ça. Notre projet est énorme, alors faites-moi confiance quand je dis que je comprends la douleur d'avoir un tas d'implémentations personnalisées de choses qui sont proches mais pas tout à fait des types BCL ou des spaghettis ifdef. Donc, je ne suggère pas des choses par ignorance des complications. Il y a certainement des compromis.

En effet, une bonne question : que reste-t-il du rétroportage des fonctionnalités de base de .net vers .NET complet ? Comme je l'ai lu ici, .NET complet est si fragile, y déplacer du code prend du temps (il se déplace très lentement) et peut se casser à tout moment (peut-être, aucune idée de la façon dont il est entrelacé), alors je conclus que cela n'arrivera pas très souvent.

Cela ne peut pas être les deux : soit le rétroportage vers .NET complet est OK, ils sortent juste moins souvent (par exemple tous les 6 mois à un an) ou c'est très compliqué et sujet aux erreurs. Si c'est le premier, accélérez simplement le rythme et ne laissez pas vos utilisateurs payer la facture et arrêtez d'utiliser le second comme excuse. Si c'est ce dernier, n'est-ce pas la bonne conclusion que netstandard est une erreur, car tout ce qui compte pour l'avenir est l'API de .netcore de toute façon ?

Je suis sérieusement préoccupé par l'avenir de la direction de .NET. Mon entreprise construit des outils pour .NET complet et .NET standard1.6. La dernière chose que nous voulons, c'est que la force motrice de la direction de .NET (les nouvelles fonctionnalités qui sont sur le point d'être rétroportées sur .NET complet, comme indiqué dans l'annonce du noyau .NET il y a toutes ces lunes) divise efficacement les choses et l'écosystème est divisé en deux, car la fragmentation tue.

Rien dans ce fil ne m'a rassuré que tout allait bien pour l'avenir de _all_ .NET et de l'écosystème nécessaire pour le maintenir en vie : je ne vois que deux groupes :

• Les personnes qui craignent que les options ne deviennent compliquées et qui ont un problème difficile à résoudre
• Microsoft qui ne voit qu'une seule voie : la voie du noyau .net.

Ces deux-là ne correspondent pas pour le moment. Quelqu'un de Microsoft peut-il s'il vous plaît obtenir une histoire cohérente afin que nous puissions tous voir quelle est la vraie affaire, comment les choses sont vraiment, c'est-à-dire avec le rétroportage des fonctionnalités vers .net complet, ce qui est fait pour la myriade de choses manquantes dans le noyau .net (trucs sqlserver, portée des transactions pour n'en nommer que quelques-uns) et comment Microsoft pense pouvoir vendre cette nouvelle direction comme une plate-forme solide, fiable et fiable pour l'avenir, afin que les entreprises et les grandes équipes puissent la choisir sans souci.

Bien que je convienne que tout cela est une bonne chose à long terme, je pense également qu'il est trop tôt pour abandonner le support du framework complet avec 2.0.

Nous aimerions passer à .NET Core dès que possible, mais malheureusement, nos plus gros bloqueurs sont actuellement presque exclusivement des bibliothèques Microsoft (par exemple, Entity Framework Core n'est pas encore assez bon, Azure Service Bus n'a qu'un aperçu très précoce).

Bien que j'espère que les bibliothèques Azure seront prêtes dans les prochaines semaines/mois, il ne semble pas que EF Core aura suffisamment de fonctionnalités de si tôt.

Je ne sais rien des composants internes d'EF6, mais ne serait-il pas possible, avec un effort raisonnable, de cibler netstandard? Cela supprimerait un énorme bloqueur...

"Rester simplement sur 1.x" ne semble pas être une bonne alternative car il y aura sûrement beaucoup de bibliothèques qui s'en fichent (ou qui n'ont pas les ressources/connaissances pour prendre en charge les deux) et qui mettent simplement à niveau leur dépendance vers 2.0

PS : Je suis très frustré par la complexité de l'écosystème .NET au cours des dernières années. J'ai dû passer BEAUCOUP de temps pour comprendre toutes les nouveautés et je ne vois pas comment un nouveau développeur devrait comprendre tout cela. Il y a tellement d'informations obsolètes sur Internet à cause de tous ces changements assez extrêmes.
De plus, toutes les différentes versions du produit (.net core, sdk, .net standard, ...) sont extrêmement déroutantes. Je n'ai pas encore vu quelqu'un qui comprend le tableau standard .NET sans avoir besoin d'une explication de 20 minutes. 😞

quiconque utilisait .net core avec la version complète du framework .NET vient de se faire avoir et doit revenir à MVC 5

Ouais. Je comprends le raisonnement, et je suppose que je pourrais dire que j'aurais dû le voir venir, mais c'est très frustrant de nous faire tomber dessus sans avertissement préalable.

Nous avons un écosystème d'applications, comme beaucoup d'autres, avec des bibliothèques partagées datant d'une décennie et plus, de multiples applications MVC 3, 4, 5, des applications console, des services Windows, des centaines de milliers de lignes de code. Nous ne sommes même pas dans une si mauvaise situation pour effectuer une mise à niveau par rapport à certains.

Nous avons récemment créé quelques nouvelles applications Web utilisant ASP.Net Core 1.1, ciblant nécessairement le framework 4.6.2 complet. Ces applications utilisent de larges pans de nos bibliothèques partagées existantes. Nous avons passé une quantité embarrassante de temps de développement à gérer project.json, puis le nouveau .csproj, en essayant de mélanger les anciens et les nouveaux .csproj dans la même solution, en revenant à VS15 pour faire avancer les choses avec les anciens types .csproj, cassés Système. dépendances et une litanie de problèmes de liaison d'assemblage, de problèmes de construction et de publication .. la liste s'allonge encore et encore.

Et maintenant, nous sommes restés suspendus haut et sec dans une impasse. Gâchons-nous quelques mois-homme de développement ou passons-nous plusieurs fois à essayer de déterminer d'abord ce qui pourrait et ne pourrait pas fonctionner, puis à trouver un moyen de mettre à niveau, puis si c'est même possible de le faire.

Je ne peux pas dire que je ne suis pas d'accord avec la direction et la nécessité de cela, mais une communication plus tôt aurait été appréciée.

Oh, et bien sûr, les bibliothèques Azure Service Fabric ne s'exécutent pas non plus sur le noyau .NET - ce qui est un autre obstacle pour nous.

Je dirais que vous devez prendre en charge le framework .NET complet jusqu'à ce que vous puissiez fournir une histoire de base .NET appropriée au sein de Microsoft (et en particulier d'Azure).

@ cwe1ss Ce changement réduira cependant une partie de la complexité de l'écosystème .NET. Puisque vous n'aurez pas deux formats différents (ASP.NET Core + .NET Full et ASP.NET + .NET Core). Je suis totalement d'accord sur les informations obsolètes, mais je pense que cela ne peut pas être évité lorsque vous développez à l'air libre comme Microsoft le fait maintenant.

@davidfowl

L'histoire du partage de code sur différents runtimes .NET est .NET Standard. Vos bibliothèques doivent essayer de cibler cela sur le code partagé entre .NET Core et .NET Framework.<

Mais le cadre complet tel que je le comprends ne prend même pas en charge la norme.net, ce n'est donc vraiment pas une norme utile.

Microsoft semble avoir oublié l'importance de la rétrocompatibilité.<<

Le problème est qu'ASP.NET Core n'a jamais été conçu pour être rétrocompatible... C'est pourquoi il y a eu un tel changement de paradigme par rapport à ASP.NET 4.x. Il semble que si la rétrocompatibilité est le bit le plus important pour vous, il serait préférable d'utiliser ASP.NET 4.x sur .NET Framework. Cela est pris en charge dans un avenir prévisible et fera l'objet d'un correctif de sécurité tant que Windows sera en vie.<

Les correctifs de sécurité ne sont qu'une partie du problème. Les normes Web changent si rapidement que nous avons besoin de quelque chose avec lequel nous pouvons utiliser les dernières normes. Ainsi, par exemple, j'ai vu quelque part au-dessus quelque chose à propos de HTTPS v2. Je n'ai aucune idée de ce que cela signifie dans la pratique, mais le fait est que je veux que mon cadre puisse prendre en charge ces choses. Si je suis obligé de rester avec une ancienne version du framework, qu'il s'agisse de la v4 ou de la v1, il ne prendra pas en charge les éléments requis.

ASP .net Core a toujours été commercialisé comme fonctionnant à la fois sur le noyau .net et sur le framework. Comme d'autres l'ont dit, cela ne me dérange pas si nous devons attendre six mois ou un an jusqu'à ce que le cadre rattrape son retard. J'ai normalement environ six mois ou plus de retard de toute façon. Mais ce qui semble se produire, c'est que notre investissement existant est complètement abandonné, comme tant d'autres technologies Microsoft dans lesquelles beaucoup d'entre nous ont investi du temps.

Stéphane

@Rutix pour "développer à l'air libre", ce changement majeur a été effectué de manière étonnamment silencieuse sans aucune annonce ni enquête (après tout, ce problème a été créé par un membre de la communauté surveillant les demandes d'extraction).

Faire des choses en silence a mordu Microsoft dans le passé et ils ne semblent pas apprendre. Et n'essayez même pas de me dire qu'ils ne pouvaient pas voir que l'abandon du support complet du framework perturberait la communauté et nuirait à la foi et à l'investissement dans la plate-forme.

Le dernier incident était https://github.com/dotnet/roslyn/issues/17054 mais ils l'ont rapidement corrigé, je me demande comment cela va se passer.

Mais le cadre complet tel que je le comprends ne prend même pas en charge la norme.net, ce n'est donc vraiment pas une norme utile.

@stefanolson Ce n'est pas correct. Les bibliothèques ciblant .Net Standard 1.x peuvent s'exécuter sur diverses versions complètes du framework aujourd'hui. Les bibliothèques ciblant .Net Standard 2.0 devraient pouvoir fonctionner sur 4.6.1 la dernière fois que j'ai regardé.

@Suchiman , je suis totalement d'accord avec vous. Je suis un peu déçu qu'ils ne semblent pas apprendre à communiquer et à lâcher des bombes sur la communauté. Ils auraient pu mieux gérer cela s'ils l'avaient annoncé en premier et avaient eu une discussion communautaire.

Mais le cadre complet tel que je le comprends ne prend même pas en charge la norme.net, ce n'est donc vraiment pas une norme utile.

@stefanolson C'est le cas. Différentes versions (existantes) de .NET Framework implémentent différentes versions de la norme .NET. Voir https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

Je sais que je suis un peu en retard sur ce fil, mais voici deux de nos cas d'utilisation pour utiliser ASP.NET Core sur NetFX sous Windows :

Utiliser ASP.NET pour héberger une API REST pour votre application

Notre application est une application de type "API .NET transformée en API REST". Il a d'abord été livré en tant qu'API .NET et a des dépendances dans toutes sortes de choses Windows.

Lorsque nous avons ajouté une API REST, nous avons choisi l'API Web ASP.NET pour l'héberger. Lorsqu'il est devenu clair que l'API Web s'unifiait dans ASP.NET vNext/5/Core, __et__ nous avons compris que __ASP.NET Core fonctionnerait sur NetFX__, il était logique d'utiliser ASP.NET vNext/5/Core.

Bien que nous profitions de .NET Core pour porter (une partie de) notre application sur Linux et macOS, il existe toujours des dépendances Windows qui ne s'exécutent pas sur .NET Core (pour obtenir une liste des dépendances que nous avons portées, vérifiez le CoreCompat.* paquets NuGet).

Pour faire court, nous nous retrouvons maintenant bloqués sur ASP.NET Core 1.x qui restera pris en charge pendant environ une période limitée. Et maintenant quoi? Retour à ASP.NET 4 ?

Je comprends tout le travail de perf que vous faites et repoussez les limites dans d'autres domaines de .NET Core, mais dans mon cas d'utilisation, je n'héberge pas un site Web à haut volume exposé à Internet, j'héberge une API REST qui obtenir comme quoi, 10-20 RPS max ?

Prise en charge de Visual Studio

Vraiment, mon expérience Visual Studio 2017 sur NET 4.x est toujours bien meilleure que .NET Core - un bon exemple est le temps qu'il faut pour recompiler un projet de test et faire apparaître les nouveaux tests dans la fenêtre de test . C'est beaucoup plus rapide sur NetFX.

Nous nous retrouvons dans une situation où nous avons aujourd'hui un projet NetFX et .NET Core côte à côte compilant essentiellement la même base de code. La seule raison pour laquelle nous maintenons cette double maintenance est due aux performances de Visual Studio avec les projets .NET Core (_en particulier_ les tests unitaires et le débogueur).

Après coup, ce qui me frappe vraiment, c'est que ce changement est effectué maintenant, quelques jours avant la sortie de l'aperçu. Cela semble simplement indiquer qu'il n'y a pas encore de raison technique de le faire - alors pourquoi ne pas effectuer le changement dans ASP.NET Core v3 ?

@mattnischan

@stefanolson Ce n'est pas correct. Les bibliothèques ciblant .Net Standard 1.x peuvent s'exécuter sur diverses versions complètes du framework aujourd'hui. Les bibliothèques ciblant .Net Standard 2.0 devraient pouvoir fonctionner sur 4.6.1 la dernière fois que j'ai regardé.<

Il me semble que le noyau asp.net va exécuter le noyau .net et non la norme .net? Je ne suis donc toujours pas sûr de l'intérêt de la norme .net - si elle est abandonnée pratiquement dès sa création.

Cela aurait tout à fait du sens si le noyau asp.net nécessitait la norme .net 2.1 car il y a des choses dont ils ont besoin qui ne sont pas dans le cadre pour le moment. Nous avons donc dû attendre que le framework .net complet prenne en charge ces fonctionnalités supplémentaires avant de pouvoir utiliser la dernière version du noyau Asp.net. Cela fonctionnerait et aurait du sens.

Mais au lieu de cela, ils abandonnent simplement la norme, la rendant inutile (si je comprends correctement cette situation confuse)

Alors... sa Build 2017 commence demain ; J'imagine que l'équipe est très occupée à se préparer. Peut-être quelques annonces, peut-être pas. Peut-être leur donner un peu de répit et se réunir dans une semaine ?

Peut-être assister à l'émission https://build.microsoft.com/ (mercredi 8h00 PST, 15h00 GMT et jeudi similaire ?)

Nous pouvons en savoir plus; Peut-être pas. Les choses peuvent être plus claires, peut-être pas. Cependant, l'équipe ASP.NET sera probablement en mesure de répondre un peu mieux et de se concentrer davantage sur les préoccupations de chacun. Bien que @davidfowl ait fait vaillamment !

@stefanolson Mais au lieu de cela, ils abandonnent simplement la norme rendant la norme inutile (si je comprends bien cette situation confuse)

Je pense que le point de .NET Standard est la compatibilité. Les auteurs de bibliothèques peuvent cibler .NET Standard, puis tout le monde peut l'utiliser, qu'ils soient sur .NET Framework, .NET Core ou quelque chose d'autre qui prend en charge .NET Standard.

Je pense que le but de .NET Core est une réinvention de .NET Framework. .NET Core est multiplateforme, hautes performances, open source et en évolution rapide.

Changer l'implémentation de string en utf8 par défaut est massif et pas quelque chose que vous vous attendriez à voir sur .NET Framework.

Après avoir lu ce fil, j'ai l'impression :
.NET Core -> .NET Framework est comme ASP.NET MVC -> WebForms.

J'aimerais également souligner l'aspect de l'outillage. Les performances actuelles de restauration / construction / test, etc. sont très mauvaises et une douleur royale. Si nous devions "rester sur 1.0", serions-nous toujours en mesure d'utiliser des SDK plus récents avec (espérons-le) de meilleures performances ou serions-nous bloqués avec un SDK 1.x ?

L'histoire de .NET Core est une merveilleuse tournée pleine de hauts et de bas. Nous venons tout juste de commencer à travailler sur ASP.NET Core à cause de tous les "fuck ups" précédents (versioning, naming, project.json - .csproj transition) et j'étais (et j'attends) avec impatience .netstandard 2.0, parce que je pense ce sera la première "vraie" version.

Je comprends qu'ASP.NET Core 1.1 est toujours pris en charge et fonctionnera pendant les 10 prochaines années, mais vous êtes super courageux pour vous déplacer rapidement et réduire l'un des arguments de vente antérieurs d'ASP.NET Core.

Si vous voulez savoir ce qu'est un bloqueur (en plus des services d'annuaire) de notre côté : nous utilisons toujours EF6 et attendons toujours un package NuGet SDK Open XML officiel qui cible netstandardwhatever.
La migration du code peut prendre beaucoup de temps...

Serait-il possible de formaliser une sorte de processus pour faire avancer netstandardXX en fonction des changements qui se produisent dans Core, ce qui implique de le cibler dans le cadre d'une phase de maintenance de la version de la bibliothèque Asp.Net Core ?

Dans l'état actuel des choses, j'ai une application WebForms/MVC sur laquelle nous étions sur le point d'activer un déclencheur pour exposer une API Web ANC et appeler depuis un SPA (et finalement depuis l'ancienne application WebForms), mais nous ne pouvons pas développer sur le CoreCLR à cause de une dépendance au pilote Sybase (maintenant SAP) Ase ADO.NET (si quelqu'un qui lit ceci pourrait appuyer sur un bouton quelque part chez SAP ... Je n'arrive malheureusement pas du tout à me faire entendre à ce sujet ou sur des bogues que je connais depuis plus 9 ans maintenant).

En lisant ce numéro, je ne suis plus si sûr de ce que devrait être mon chemin. La seule chose sur laquelle je suis sûr de pouvoir planifier est qu'un pilote bogué continuera d'exister pour le framework de bureau. Étais-je censé ignorer les modifications apportées à ASP.NET au cours des dernières années, car elles allaient être une perte de temps et je devrais simplement cibler WebApi2 ? Suis-je censé dire allez-y avec ANC 1.x en sachant que je ne migrerai probablement jamais et que je verrai les avantages de 2.x dans une application qui, je pense, sera prise en charge ici pendant les 10 à 15 prochaines années (l'application WebForms a été migré et maintenu depuis la sortie du framework 1.1) ?

@davidfowl

Span lui-même a une version portable qui fonctionne n'importe où, je ne suis pas sûr que la mise en œuvre rapide sera un jour
sur .NET Framework. Les API qui seront ajoutées à .NET Framework qui tirent parti de Span peuvent prendre beaucoup plus de temps que Span lui-même, c'est vaste. À quand remonte la dernière fois que nous avons changé de chaîne et de tableau dans .NET
Cadre?

Attends quoi?

Nous ne sommes pas tous des développeurs Web. Nous attendions avec impatience une meilleure prise en charge de la gestion des cordes depuis des années et maintenant, tout à coup, vous nous dites que nous sommes SOL ? Que le .NET Framework et les innombrables applications non Web construites dessus n'auront jamais accès aux bibliothèques de gestion de chaînes basées sur Span ?

Ce n'est plus seulement un problème ASP.NET. Il va au cœur de l'engagement à long terme de Microsoft envers .NET Framework et sa bibliothèque de classes de base.

Vous savez, je dois vraiment le donner à des gens comme @davidfowl pour avoir continué à répondre à tout le monde et à tout le monde pour avoir contribué à cette discussion. J'ai beaucoup à rattraper plus tôt dans la journée, mais j'ai l'impression d'apprendre beaucoup à travers chaque commentaire en termes de ce que tout le monde utilise/espère utiliser .NET.

Je pense qu'avec l'aide de tous, nous finirons par aplanir certains chemins et j'espère que tous les côtés seront pris en considération.

j'attends l'annonce officielle avec impatience

Si j'ai bien compris, net coreapp 2.0 fournira un shim de compatibilité qui permettra à nos projets ASP.NET Core 2.0 de dépendre de nos anciennes bibliothèques de classes NetFx (par exemple, net461).
Où puis-je trouver plus d'informations sur les capacités/limitations actuellement prévues d'un tel shim de compatibilité ?

@dgaspar Ce n'est pas vraiment précis, voici comment cela fonctionne : netcoreapp2.0 prend en charge la plupart des API dans net461 . Si votre bibliothèque est conçue pour net461 et n'appelle que les API qui existent dans le sous-ensemble pris en charge par netcoreapp2.0 , vous pouvez quand même importer la bibliothèque (considérez-la comme prioritaire, que vous connaissez mieux) et faites-le fonctionner, puisque toutes les classes et méthodes qu'il appelle doivent être là.

Maintenant, il y a aussi un inconvénient: si les méthodes ne sont pas là ou ne sont pas entièrement prises en charge d'une manière ou d'une autre, vous obtenez des erreurs d'exécution pour les méthodes manquantes, etc. Les vérifications au moment de la compilation ne sont donc pas une bonne assurance. C'est un peu une épée à double tranchant dont il faut être conscient, mais certaines bibliothèques qui ne seront jamais mises à jour sont tout à fait adaptées à l'ensemble des API qu'elles appellent.

@NickCraver quelqu'un se souvient...

"imports": [ "dnxcore50", "portable-net45+win8" ]

Un commentaire connexe que j'ai fait en décembre. 11 pouces levés reportés :

Quelque chose cloche ici. Je livre des applications C# depuis 15 ans. Ironiquement, à mesure que des abstractions de niveau supérieur sont fournies par Microsoft, je passe de plus en plus de temps à creuser profondément dans des éléments internes dont je n'avais jamais eu à m'inquiéter auparavant. VOUS LE FAITES MAL.

Si je voulais être surpris à l'exécution par des erreurs aléatoires induites par la bibliothèque et la gestion des packages que le compilateur n'a pas détectées, j'écrirais mes applications en Ruby.

même node.js nous permet d'appeler facilement toutes les bibliothèques netfx.

le code mvc est vraiment la partie la plus facile. cela peut prendre quelques semaines pour réécrire dans node.js ou nancy, mais il faudra beaucoup plus de temps pour porter le code métier et l'algorithme, et prouver qu'il fonctionne aussi solidement que l'ancien. sans parler du cas où nous n'avons pas la source.

prenez l'exemple de RyuJit, même après la mise en production, des bogues majeurs bloquants ont été trouvés et il a fallu encore un an pour les résoudre complètement. idem pour nos logiciels, qui ne sont pas des animaleries mais des outils industriels qui permettent de gagner des millions de dollars par jour.

le cadre de l'interface utilisateur change rapidement, du winform au web. mais la logique / l'algorithme métier de base est beaucoup plus stable et a une longue durée de vie. donc, pour utiliser le nouveau cadre brillant de l'interface utilisateur, nous devons réécrire/retester ou abandonner notre code métier/algorithme ? non, nous savons que le nouveau brillant sera remplacé par quelque chose de plus tendance dans 5 ans, mais notre code métier/algorithme continuera d'être utilisé.

@qmfrederik

Après coup, ce qui me frappe vraiment, c'est que ce changement est effectué maintenant, quelques jours avant la sortie de l'aperçu. Cela semble simplement indiquer qu'il n'y a pas encore de raison technique de le faire - alors pourquoi ne pas effectuer le changement dans ASP.NET Core v3 ?

Nous faisons ensuite le support HTTP2 et cela nécessite de nouvelles API.

J'aimerais également souligner l'aspect de l'outillage. Les performances actuelles de restauration / construction / test, etc. sont très mauvaises et une douleur royale. Si nous devions "rester sur 1.0", serions-nous toujours en mesure d'utiliser des SDK plus récents avec (espérons-le) de meilleures performances ou serions-nous bloqués avec un SDK 1.x ?

Ouais, ça marchera.

@davidfowl

Nous allons ensuite prendre en charge HTTP2 et cela nécessite de nouvelles API.<

Ainsi, le type de prise en charge HTTP2 qui sera disponible dans asp.net core 2.0 ne sera pas disponible dans 1.x ? C'est vraiment le genre de problème qui m'inquiète où nous n'aurons pas accès à la dernière technologie parce que nous sommes liés au framework .net complet pour une raison quelconque. Comme je l'ai dit ci-dessus, peu importe si cela prend de six mois à un an pour que ce filtre passe à tout ce que j'utilise, mais je ne veux finalement pas être trop loin derrière. En raison du partage de code et de l'utilisation de bibliothèques tierces à ce stade, j'ai besoin du framework .net complet.

enfin je précise quelques trucs :

• quand je dis modules hérités, ce sont des dll dépendant de dll netfx ou c++/cli, qui à leur tour peuvent invoquer certaines dll natives. ils sont pour les entreprises/algorithmes, pas de COM, pas d'asp.net. ils ne sont pas mauvais. ils deviennent hérités principalement parce que .net core ne les exécute pas.
• il est possible de migrer vers net core à long terme, et nous le voulons vraiment. mais il est vraiment difficile de pousser cela pour que cela se produise. Il faudra quelques années pour que nous et les tiers soient tous là.
• les bibliothèques spécifiques à un domaine sont beaucoup plus lentes que les bibliothèques traditionnelles pour les modifications de la pile technologique. nous connaissons tous l'exemple de python 3. ces bibliothèques spécifiques à un domaine sont de véritables affaires.

@danielcrabtree

Je pense que le but de .NET Core est une réinvention de .NET Framework. .NET Core est multiplateforme, hautes performances, open source et en évolution rapide.<

Ce qui est fantastique. Le défi est de savoir comment gérer les bases de code existantes et comment les rendre utilisables avec le noyau .net. Si WPF était disponible sur .net core, je pourrais utiliser .net core partout. Mais comme ce n'est pas le cas et que mon code est partagé entre WPF et ASP.net, j'ai besoin d'un moyen de les partager. Mais je ne veux pas être trop loin derrière avec les dernières technologies Web et techniques de sécurité dont la plupart (toutes ?) semblent être uniquement dans 2.x et versions ultérieures

À quelques reprises dans ce fil de discussion et dans la documentation ailleurs, .NET Core est décrit comme multiplateforme. Cela a été annoncé comme l'un des principaux arguments de vente pour passer à la plate-forme.

Cela ne semble pas être le cas cependant comme clarifié dans cette conversation sur Twitter

https://twitter.com/James_M_South/status/861595907782987776

Et le commentaire ci-dessus; l'accent est mis sur le mien.

Les grandes lacunes restantes manquantes dans .NET Core 2 sont System.DirectoryServices et System.Drawing. Nous travaillons pour avoir un pack de compatibilité Windows qui activerait les deux sur .NET Core sous Windows cet été.

J'ai travaillé très dur avec .NET Core depuis très tôt pour essayer de combler le vide laissé par System.Drawing avec ImageSharp et je suis maintenant à la fois très confus et plus qu'un peu mécontent et demandant :

Qu'est-ce que .NET Core maintenant ?

Voici la description de MS Docs .

.NET Core est une plate-forme de développement à usage général gérée par Microsoft et la communauté .NET sur GitHub. Il est multiplateforme, prend en charge Windows, macOS et Linux, et peut être utilisé dans des scénarios d'appareils, de cloud et intégrés/IoT.

Il y a encore cette déclaration multiplateforme . Est-ce ou n'est-ce pas? Je pense qu'essayer de cerner cela conduit à beaucoup de confusion dans la communauté du développement.

Chaque description que je lis semble être différente.

Peut-on:

1. S'il vous plaît, écrivez un message décent et cohérent quelque part afin que nous puissions réellement avoir un objectif à atteindre et une meilleure compréhension globale.
2. Obtenez des éclaircissements sur la feuille de route actuelle pour System.DirectoryServices et System.Drawing

System.Drawing en particulier est à la fois déroutant et inquiétant. Je ne comprends pas pourquoi vous voudriez jamais porter cette API sur .NET Core sur n'importe quelle plate-forme. Il est difficile de travailler avec, non pris en charge sur le serveur et manque de nombreuses fonctionnalités essentielles requises pour le développement moderne (Multi-threading, Pixel Formats, ICC, EXIF, Quantization, Indexed Png et ainsi de suite).

Il y a beaucoup de noms et de visages reconnaissables ici, et je sais que j'ajoute juste un peu de bruit ici, mais :

• DirectoryServices
• Dessiner (pas que j'en ai besoin)
• EF

Celles-ci semblent être les trois choses les plus critiques à mettre à jour avant de faire une pause aussi importante. Personnellement, la plupart de tout ce sur quoi je travaille est sur net4x uniquement à cause d'EF6, depuis EFCore... eh bien... :trollface:

@stefanolson
Je pense que vous êtes censé séparer le code partagé dans une bibliothèque .NET Standard. Ensuite, il sera utilisable depuis WPF et ASP.NET sur .NET Framework et depuis ASP.NET sur .NET Core et d'autres applications .NET Core.

@JimBobSquarePants
Je ne pense pas que le pack de compatibilité Windows fasse partie de .NET Core. Il s'agit d'une bibliothèque spécifique à Windows qui repose sur .NET Core. Vous pouvez imaginer qu'il existe une bibliothèque spécifique à Linux qui expose des fonctionnalités Linux uniquement.

Je pense que le pack de compatibilité Windows vise à simplifier la migration des bases de code .NET Framework existantes. De toute évidence, une fois que quelqu'un est passé à .NET Core, il doit alors envisager de migrer vers de meilleures solutions comme ImageSharp.

@stefanolson
Il est possible qu'ils puissent même créer un pack WPF uniquement pour Windows qui vous permette de créer des applications WPF dans .NET Core, mais qui ne fonctionnerait que sur Windows.

Ce problème GitHub a été mentionné sur un site d'information informatique allemand :
https://www.golem.de/news/asp-net-core-2-0-microsoft-veraergert-net-entwickler-mit-support-entscheidung-1705-127712.html

Merci @danielcrabtree , c'est la première fois que j'entends parler de packs de compatibilité.

Traduction du lien de @MJomaa : https://translate.google.com/translate?u=https%3A%2F%2Fwww.golem.de%2Fnews%2Fasp-net-core-2-0-microsoft-veraergert- net-entwickler-mit-support-entscheidung-1705-127712.htm

J'attends que System.Xaml soit porté.

@alexwiese ne retiens pas ton souffle.

J'attends que System.Xaml soit porté.

Continue; je vais mordre. Comment utilisez-vous Xaml sur votre site Web ?

Continue; je vais mordre. Comment utilisez-vous Xmal sur votre site Web ?

Interface utilisateur multiplateforme (modèles d'écran partagés entre une application de console "écran vert", une application Xamarin et un SPA angulaire), également utilisée pour un moteur de règles métier.

Wow, ok donc vous transformez le XML du XAML d'une certaine manière en HTML et Javascript ? Assez juste 😄

Je ne savais pas si tu t'étais contenté de troller.

Je fais la même chose, mais de manière réaliste, je ne les vois pas porter XAML, étant donné qu'à ce stade, il ne peut pas être analysé sans être également exécuté.

Wow, ok donc vous transformez le XML du XAML d'une certaine manière en HTML et Javascript ? Assez juste 😄

Bien sûr que non; Je convertis d'abord en JSON 😉

Un autre article de presse sur ce sujet avec beaucoup d'entre nous cités : https://www.infoq.com/news/2017/05/ASPNET-Core-2

@cwe1ss L'auteur est @Grauenwolf

@alexwiese @yaakov-h J'aimerais lire un article de blog à ce sujet ; semble assez intéressant et doit venir avec un ensemble de défis différents de ceux auxquels je suis habitué.

C'est vraiment mauvais. ASP.NET Core était une vente raisonnable lorsque vous pouviez tirer parti des bibliothèques héritées en cas de besoin. Dans le cas où cela peut être fait avec les nouveautés, modifiez quelques éléments et ciblez .NET Core. Sinon, ciblez simplement le cadre complet.

Avec ce changement, c'est un saut tout ou rien. Et étant donné que vous ne comprenez pas toujours toutes les dépendances à l'avance, cela amplifie le risque.

Je comprends le désir d'aller vite et d'évoluer là où les choses doivent aller de toute façon, mais vous allez laisser vos utilisateurs derrière vous. Les gens ont tendance à migrer, pas à sauter. Un grand nombre ne veut tout simplement pas s'éloigner du courant. Et quand ils le feront, ils pourraient bien passer entièrement à une plate-forme différente. Sérieusement, vous sous-estimez ce risque.

C'est une décision qui devrait éventuellement être prise, mais plutôt fin 2019, ou 2020 au plus tôt. Même dans ce cas, vous voulez toujours un modèle à long terme pour soutenir ceux qui ont choisi de mélanger les choses.

Et non, ASP.NET Core 1.x n'est tout simplement pas une réponse. Son immaturité est bien comme phase de transition avec une voie de migration facile vers l'avant, mais elle n'est pas adaptée pour vivre avec à long terme. Il y a une grande différence entre l'état d'esprit de ceux qui développent une plateforme comme celle-ci et ceux qui l'utilisent. Veuillez reconsidérer cette orientation.

@davidfowl Qu'en est-il de quelque chose comme edge.js pour netcore ? Cela rend le consommateur d'API responsable des vérifications de la plate-forme et une interface fortement typée entre netfx et netcore est suffisante pour la plupart des scénarios.

Ce modèle sera-t-il alors supprimé ?

Il est intégré à VS2017 pour le moment.

quelle connerie totalement inacceptable, encore une fois cela prouve que c'est une technologie de jouet qui n'est pas prête pour les heures de grande écoute et une large adoption.

J'apprécie vraiment les gars, vous avez une belle expérience de conduite et de codage, vous pouvez briller dans vos entrées de blog et Twitter (hourra !), améliorer vos profils et CV LinkedIn (hourra ^ 2), toutes les release parties devant vous, les filles, les boissons et les choses ont l'air prometteuses, mais .. qui va les utiliser ? ciblez-vous les entreprises et souhaitez-vous une large adoption et une base d'utilisateurs solide ? ou quelques hippies de démarrage seulement ?!?

Ce commentaire à propos de "full Span" ne pouvant jamais entrer dans .NET Framework me préoccupe sérieusement. Si full Span n'est pas dans .NET Framework, je suppose que les API qui l'utilisent ne pourront jamais en faire un futur netstandard, ce qui rend impossible l'écriture de bibliothèques multiplateformes qui utilisent ou exposent une analyse haute performance ? Ce qui signifie que nous sommes coincés avec nos implémentations personnalisées non sécurisées en permanence de manière efficace...

Vous mentionnez que si vous voulez que votre bibliothèque soit multiplateforme, vous devez cibler netstandard, mais qu'est-ce qu'ASP.NET Core si ce n'est une bibliothèque largement utilisée? Recommanderiez-vous à d'autres bibliothèques de commencer à abandonner la prise en charge de netstandard et de passer à .NET Core ? La prochaine version majeure de JSON.NET ou quoi que ce soit devrait-elle abandonner le netstandard ? Cela pourrait certainement faire avec une analyse rapide!

Remarque Java a réussi à ajouter des E/S rapides sans copie, etc., de manière rétrocompatible avec Netty (https://netty.io/)

Enfin, je tiens à remercier les personnes qui sont prêtes à traîner et à répondre à ces questions. Nous apprécions les réponses...

@shanselman Bouger rapidement est un objectif noble, en particulier pour les équipes qui consacrent des efforts considérables à la compatibilité et à la conception de choses de manière compatible, comme l'équipe ASP.Net. Je sais à quel point ils aimeraient simplifier leur domaine problématique, et je soutiens cela, mais ...

Se déplacer rapidement et en même temps "également loin" de vos clients n'est pas non plus une bonne chose. Vous savez, vos clients (moi y compris) disposent d'un ensemble sérieux de logiciels hérités et investissent du temps dans des applications et des bibliothèques existantes. Vous ne pouvez pas simplement nous laisser derrière vous et aller dans un endroit où nous ne pourrons/ne suivrons pas.

Vous devriez considérer vos clients qui ne peuvent pas accéder au noyau .Net et qui doivent utiliser Full Framework pendant au moins un certain temps à partir de maintenant. Si vous vous éloignez du Full Framework, vous laissez beaucoup de personnes bloquées sur les anciennes versions et créez une grande scission dans le monde .Net.

@JimBobSquarePants Je vous seconde sur la partie System.Drawing . Il y a des discussions dans les autres dépôts sur le retour System.Drawing . Sur la base de certains des commentaires de ce fil, je comprends qu'il y aura d'abord un "pack de compatibilité" sur Windows, puis sur tous les systèmes d'exploitation pour System.Drawing .

Je me demande à quoi cela ressemblera et s'il sera basé sur la libgdiplus de Mono ou non (ce qui supprimerait certaines des préoccupations que vous avez avec System.Drawing, mais c'est une autre histoire)

D'accord, de la façon dont je le vois, il y a quelques problèmes en jeu:

1. Cela a été assez mal communiqué.
2. Les gens n'ont pas été impliqués dans la décision. Notez que Microsoft est bien sûr libre de choisir la direction qu'il souhaite, mais ne pas discuter de ce type de grand changement avec la communauté n'est pas dans l'esprit du développement open source.
3. Il n'y a pas de "grand plan" que la communauté peut utiliser pour examiner ces types de décisions. Au début, .NET Core était une version rognée et multiplateforme du framework complet. Ensuite, avec .NET Standard 2.0, il est apparu à beaucoup que .NET Core 2 serait comme un remplacement direct du framework complet, dans des limites raisonnables bien sûr (pas d'UWP, WinForms, etc.).
4. .NET Core 2 manquera plusieurs fonctionnalités importantes qui se trouvent dans le framework complet, comme System.DirectoryServices. Pour autant que je sache, cela a été reconnu, mais peut-être que la voie à suivre pour ajouter ces fonctionnalités à .NET Core pourrait être rendue plus explicite.
5. ASP.NET Core 2 ne s'exécutera pas sur le framework complet car le framework complet manque de nouvelles fonctionnalités. Je suis en fait totalement d'accord avec ça. Si l'ajout des fonctionnalités manquantes au framework complet est excessivement difficile, ne le faites pas. Avoir ASP.NET Core 2 exécuté uniquement sur .NET Core 2 est en fait assez logique, bien que les mentionner comme étant un produit n'était probablement pas la meilleure façon de décrire leur relation.

Ce que je pense que les gens aimeraient vraiment voir, c'est une description de la vision de la plate-forme .NET. Dans quelle direction les choses iront-elles ? Le framework complet recevra-t-il uniquement des corrections de bogues et autres, mais pas de nouvelles fonctionnalités ? Que fait-on pour ajouter les fonctionnalités manquantes à .NET Core et quand pouvons-nous les attendre ? Espérons que cela contribuerait grandement à atténuer l'anxiété que les gens ressentent actuellement.

@davidfowl Je suppose qu'il ne s'agit pas seulement de HTTP 2.0 ; s'il s'agit vraiment de HTTP 2.0, ne pourriez-vous pas avoir ASP.NET Core 2.0 cible NetFX à l'exception de la prise en charge de HTTP 2.0 ? Peut-être même un modèle enfichable pour que la communauté puisse faire du HTTP 2.0 sur NetFX si elle le voulait vraiment ?

@cokkiy @popcatalin81 @xprzemekw Si vous n'avez rien de constructif à dire, veuillez vous abstenir de commenter, ce genre de commentaires n'aide personne.

Il y a des raisons légitimes pour lesquelles faire le mouvement décrit par @davidfowl https://github.com/aspnet/Home/issues/2022#issuecomment -300141134

Les raisons pour lesquelles le reporter incluent (disons asp.net core 3.0):

• EF Core n'est pas encore prêt à remplacer EF 6.0 en raison de nombreuses fonctionnalités manquantes
• pas de production prêt System.Drawing remplacement
• non System.DirectoryServices
• il y avait mention de office xml sdk , mais cela semble déjà disponible sur netstandard à partir du 2017-05-01 https://www.nuget.org/packages/DocumentFormat.OpenXml/
• autres packages en dehors de la portée de MS non disponibles sur .net core (nhibernate, divers fournisseurs de base de données, ikvm)

Les raisons pour lesquelles vous ne le faites jamais incluent :

• Les utilisateurs ont porté des applications sur le noyau asp.net avec des dépendances héritées sans intention de passer au noyau .net.
• Inquiétez-vous de laisser netstandard derrière vous et de ne pas trop vous en soucier.
• Il est peu probable que certains packages tiers soient jamais portés sur .net core (ce qui les rend sans doute obsolètes, mais ce n'est peut-être que mon opinion)

Un exemple de commentaire constructif serait d'ajouter votre raison pour laquelle vous aimeriez voir l'un de ces trois scénarios ou de suggérer une solution alternative. Si vous souhaitez simplement exprimer votre accord/désaccord, utilisez les boutons "Réaction".

@Kukkimonsuta

Les utilisateurs ont porté des applications sur le noyau asp.net avec des dépendances héritées sans intention de passer au noyau .net.

Complètement d'accord. Parce que Microsoft avait annoncé qu'ASP.NET Core fonctionnerait à la fois sur les frameworks .net core et .net. Et maintenant, les laisser dans AspNet Core 1.x n'est pas juste.

Le dernier résumé est assez bon. Je voudrais juste ajouter une chose ou deux :

1.) Il devrait être possible d'écrire des services Windows avec .NET Core (je sais que les démons sur les plates-formes * NIX fonctionnent différemment). La ServiceBase serait donc toujours nécessaire, et c'est une priorité élevée avec EF.

2.) Il devrait en outre être possible d'écrire des services autonomes avec .NET Core et de les héberger en plus dans votre application .NET existante basée sur le framework complet (c'est-à-dire un service gratuit de votre application Windows Forms / WPF) pour les étendre.

Ce dernier est vraiment nécessaire pour les scénarios de migration lente, où il n'est pas possible de faire une coupe dure et de démarrer sur un terrain vierge.

Complètement d'accord. Parce que Microsoft avait annoncé qu'ASP.NET Core fonctionnerait à la fois sur les frameworks .net core et .net. Et maintenant, les laisser dans AspNet Core 1.x n'est pas juste.

J'aimerais également souligner à nouveau que l'énorme changement de .csproj et msbuild a été principalement excusé par le fait qu'il ne serait pas possible de référencer des projets (ASP).NET Core à partir de vos projets .NET existants (framework complet).

Ce changement rend ce dernier impossible (au moins pour la plus grande partie ASP.NET). Alors pourquoi la compatibilité était-elle primordiale à l'époque (et causait beaucoup de douleur), mais ne l'est-elle pas maintenant (et cause encore beaucoup de douleur) ?

désolé je dois stresser aussi. Mais près de 500 commentaires, je crois que si je suis impliqué en tant que gars de Microsoft pour ce problème, j'avais deux options :
1 : désactiver le problème
2 : repenser ma décision

@gingters Le changement csproj concernait principalement _.net_ core, afin que xamarin, asp.net, uwp et tous les autres partagent du code et fassent également référence à d'autres types de projets comme le code natif.

En outre, il permet aux projets asp.net core 2 de référencer des projets de framework complets, encore une fois, via le compat shim

@qmfrederik

Peut-être même un modèle enfichable pour que la communauté puisse faire du HTTP 2.0 sur NetFX si elle le voulait vraiment ?

Ils pourraient techniquement. Mais il semble qu'ils ne veulent pas. Pour moi, j'ai l'impression qu'ils ne veulent tout simplement pas penser aux besoins réels des entreprises / grandes entreprises, ou à la rétrocompatibilité ou à la nécessité de faire face à autre chose que des trucs nouveaux.

Et pour être franc, la gestion des attentes dans le passé ciblait complètement les entreprises qui souhaitaient étendre / migrer lentement leurs contenus vers plusieurs plates-formes, tout en étant capables d'étendre / migrer lentement leurs applications existantes. Ce mouvement n'est donc pas du tout aligné avec la gestion des attentes précédente.

@aL3891

pour que xamarin, asp.net, uwp et tous les autres partagent du code

Oui. Exactement. Et cela inclut également l'application WPF/Windows Forms pour utiliser les bibliothèques .NET Core, ce qui est désormais impossible lorsque vous souhaitez passer à .NET Core 2.

Quelqu'un pourrait-il expliquer exactement pourquoi ces bibliothèques ne peuvent pas cibler netstandard2.0 ?

Jusqu'à présent, j'ai considéré netcoreapp comme un surnom pour un exécutable multiplateforme (utilisé uniquement dans un projet d'exécutable csproj), mais je ne l'ai jamais considéré comme une plate-forme, maintenant, il devrait être considéré comme une véritable plate-forme ? Pourquoi pourquoi pourquoi, et comment en sommes-nous arrivés à cette option absurde ?