Runtime: Porter System.Xaml vers .NET Core

HORRAY ! Reconnaissance/reconnaissance officielle ! Et oui, je me rends compte que ces mots ne correspondent PAS à "l'engagement", mais c'est certainement mieux que tout ce que j'ai vu jusqu'à présent. @terrajobst tu es mon héros. :coeur: :coeur: :coeur:

@cwensley et @SuperJMN , ce serait formidable d'avoir un dialogue entre tout le monde ici. Idéalement (de mon point de vue), tout le monde devrait finalement utiliser un port/une version de la nouvelle bibliothèque Xaml et ne pas avoir différentes versions/dialectes de Xaml. Est-ce même à distance possible? Je suis d'accord avec ça si ce n'est pas le cas, mais j'aimerais voir si nous pouvons si c'est le cas. :)

De plus, je suis actuellement en "congé sabbatique de travail (de clients autoritaires LOL)" et j'ai 3-4 mois prévus pour Xaml multiplateforme seul. Je pourrais littéralement travailler à temps plein et apporter mon aide pendant cette période si nécessaire. Tout pour la cause (et aussi, je suis un opportuniste du bon timing !)

si System.Xaml est devenu open source, je suis sûr que la communauté peut le porter sur .net core en fonction des exigences et des objectifs de conception de ce projet, les responsables du projet n'auront qu'à guider la communauté. Permet de tirer parti de la puissance de la communauté .net.

@Michael-DST, je suis d'accord qu'il est important d'avoir un dialecte de xaml. Cependant, la mise en œuvre de cela pourrait être entièrement différente. La standardisation sur une seule implémentation dépend vraiment de la communauté.

Pour Portable.Xaml qui est un port PCL 259/136 de l'excellente implémentation System.Xaml (sous licence MIT) de Mono, avec de nombreuses corrections de bogues. L'idée est de prendre en charge tout ce que fait System.Xaml de MS (y compris la lecture/écriture) en utilisant la même API, mais sans nécessairement s'y limiter.

Comme exemple de fonctionnalité étendue, Portable.Xaml prend en charge l'utilisation de convertisseurs de type sur les éléments d'une liste, où System.Xaml utilise IList.Add(object) que vous devez implémenter à l'aide d'une collection personnalisée pour prendre en charge différents types.

@cwensley Je revendique mon ignorance à ce sujet... mais quelle est la différence entre .NET Core et PCL ? Je pensais qu'ils étaient les mêmes? C'est-à-dire que j'avais cru comprendre que si vous conceviez sous un certain profil PCL, cela serait transféré à .NET Core... c'était il y a quelque temps (et honnêtement, j'attendais .NET Core sur RTM/W), alors c'est le bon moment pour se rafraîchir. :P

D'après ma compréhension/impression, Portable.Xaml est en effet un port de System.Xaml de mono, tandis qu'OmniXaml est une réécriture à partir de zéro qui présente de nouvelles nouveautés dans le domaine de l'analyse. Idéalement (de mon point de vue), ce serait formidable de fusionner les deux d'une manière ou d'une autre, mais je ne suis même pas sûr que ce soit faisable, ni même souhaitable entre les deux bases. Dans mon esprit (sans faire de spéléologie/analyse), il s'agit essentiellement de fusionner la maturité de l'un (Portable.Xaml) avec la nouvelle ardeur de l'autre (OmniXaml).

@Michael-DST PCL 259 est en effet compatible avec .NET Core, selon ce post . J'ai déjà inclus \lib\dotnet comme cible dans le package nuget pour Portable.Xaml, donc il _devrait_ être utilisable tel quel pour .NET Core, même si je ne l'ai pas testé.

Je n'ai pas eu le temps de me pencher sur OmniXaml, mais s'il s'agit bien d'une réécriture à partir de zéro, il n'est peut-être pas logique de fusionner les deux projets car je suis sûr que les choses auraient été faites complètement différemment. Je ne suis pas non plus sûr de l'avantage d'une telle chose si Portable.Xaml est presque complet tel quel. Je pourrais toutefois avoir tord (;

:) Oui, j'explore les options ici, et je traite également mon ignorance d'être vraiment dans un monde open source. Je déteste l'idée d'avoir plusieurs bases de code faisant la même chose. Et surtout avec la communauté Xaml étant plus petite, il serait dommage qu'elle soit fragmentée dès le départ (n'est-ce pas censé se produire _après_ quelque chose devient trop réussi pour son propre bien ?! haha). Quoi qu'il en soit, ce serait formidable d'entendre le point de vue de @SuperJMN à ce sujet. Je sais qu'il semblait assez ferme sur ses nouvelles modifications. Par exemple, l'utilisation de MarkupExtensionContext à la place de IServiceProvider pour les extensions de balisage, ce qui constituerait un changement radical pour quiconque souhaite transférer du code existant vers ce nouveau monde.

Pour clarifier, tous les profils PCL sont compatibles avec .NET Core. Les ensembles de contrats et les affacturages que nous avons maintenant sont une évolution des profils PCL. Cela ne s'applique pas aux bibliothèques portables "à l'ancienne" (compilées avec mscorlib, etc.) qui ne sont pas immédiatement compatibles avec .NET Core.

@Michael-DST

@terrajobst tu es mon héros. :coeur: :coeur: :coeur:

Bien que j'apprécie grandement votre enthousiasme, je tiens à préciser que n'importe qui peut déposer des demandes comme celle-ci. Vous n'avez pas besoin de parrainage ou de reconnaissance de notre part pour déposer des problèmes, demander du travail :-) Je l'ai simplement déposé moi-même pour gagner du temps et ne pas être super boiteux ("n'hésitez pas à signaler un bogue") :-)

LOL @terrajobst c'est OK, mon enthousiasme est à moitié ironique et à moitié sérieux... MSFT est pratiquement resté silencieux sur cette question depuis près d'un an maintenant, malgré de nombreux votes et de longues conversations .

Alors, considérez ce que vous avez fait comme l'équivalent de glisser un repas sous la porte d'une personne enfermée à l'isolement pendant près d'un an. :tuck_out_langue:

[Modifier : après avoir lu cette analogie (et l'avoir vue citée ci-dessous), je dois dire que c'est terrible et probablement influencé par un article que je lisais à l'époque -- putain de nouvelles, pourquoi devez-vous m'influencer ainsi ? ! Un meilleur / pertinent serait probablement de recevoir une injection d'argent bien nécessaire d'un ange après une année de course aux fumées.]

cc : @Harikm86 , le propriétaire de System.Xaml

J'adore XAML. C'est un excellent langage déclaratif pour tout, de Silverlight (oui, je l'ai dit) à Windows Workflow et maintenant à la nouvelle plate-forme Universal App. Le portage vers Core permettra de porter d'autres technologies qui dépendent de XAML. Nous en avons besoin!

C'est super d'entendre votre soutien @rschiefer ! Merci pour votre participation. Assurez-vous que d'autres développeurs Xaml que vous connaissez rejoignent ce fil et aident à la conversation/direction.

Je suis également un fan de Silverlight et je poursuis sa prochaine incarnation depuis 2011 (prise éhontée : si vous souhaitez faire savoir à l'équipe de Visual Studio que vous aimeriez voir la prochaine forme plus intelligente de Silverlight, veuillez voter et laissez-les savoir ici ).

Je voudrais prendre une seconde et m'assurer que lorsque nous disons "Xaml", nous devrions aspirer au système/ensemble de fonctionnalités Xaml trouvé dans .NET 4.x+ (ou "System.Xaml"). Même Xaml de Silverlight 5 fera l'affaire, vraiment.

(Bien sûr, l'ajout des nouvelles améliorations trouvées dans OmniXaml est également souhaité.)

Tant que ce n'est pas la "nouvelle" version bâtarde en UWP qui a dû être portée par une équipe de stagiaires, comme nous en souffrons tous depuis (voir les votes que je mentionne dans mon post plus haut).

J'hésite même vraiment à appeler cela un système "Xaml", car il s'agit vraiment de XML avec une analyse supplémentaire de jetons pour la bonne chance (dont il a clairement besoin). Fait amusant : le système Xaml d'UWP utilise finalement l'assembly System.Xaml au cours de son processus de construction. Mmm... #ironie.

Idéalement, une fois ce port en place, le système UWP Xaml sera complètement obsolète et utilisera celui-ci à la place. Nous pouvons alors mettre ce chapitre de l'histoire embarrassante de Xaml derrière nous, et beaucoup de développeurs se réjouiront.

Récupérer Silverlight sous une forme plus récente et meilleure ne serait pas mal non plus. :) :) :)

@Michael-DST

Alors, considérez ce que vous avez fait comme l'équivalent de glisser un repas sous la porte d'une personne enfermée à l'isolement pendant près d'un an. :tuck_out_langue:

Assez bien :sourire:

@Michael-DST

J'ai en fait évité UWP jusqu'à présent, sachant que beaucoup de choses avaient changé et j'avais oublié que UWP utilisait sa propre "version" de Xaml. Merci de me le rappeler.

Je suis entièrement d'accord, System.Xaml devrait être porté et nous pourrons alors réparer UWP pour utiliser le vrai Xaml.

Je suis entièrement d'accord, System.Xaml devrait être porté et nous pourrons alors réparer UWP pour utiliser le vrai Xaml.

Désolé @terrajobst , j'ai maintenant un nouveau héros à @rschiefer. :sourire: :sourire: :sourire:

Merci à tous pour la discussion. C'est super cool pour moi (mais je pourrais juste être facilement impressionné !).

@Michael-DST @rschiefer

@helmsb OUI ! LOL haha ​​!

FWIW, la populaire technologie de conception de matériaux de Google pour le Web (Angular.js), les applications (Android), etc., est également disponible en open source. J'espère que cet argument aidera à convaincre les patrons et les entités ressemblant à des patrons.

@dsaf qu'est ce que tu veux dire ?

FWIW J'ai fait référence à ce problème dans un article publié aujourd'hui intitulé Is the Tide Turning on project.json? , un aperçu de la façon dont Xaml est un mécanisme privilégié pour décrire les objets .NET d'un point de vue technique et commercial/IP MSFT.

Eh bien tout le monde, que diriez-vous de cet accord Xamarin, hein ! quelque chose me dit que cette question va devenir beaucoup plus occupée dans les mois à venir. :le sourire:

Pas nécessairement. Il y a de fortes chances que nous voyions le Xaml d'UWP ou la saveur de Xaml de Xamarin devenir une bibliothèque multiplateforme. Ce qui peut signifier que ni un port de System.Xaml ni même une implémentation Xaml purement gérée ne peuvent se produire.

Le système Xaml de Xamarin est cependant fermé/interne et loin d'être aussi mature que System.Xaml. Le code lui-même est plutôt fragile (une préoccupation reconnue de leur côté - en fait, l'utiliser est l'une des raisons pour lesquelles il est fermé/interne). De plus, il est étroitement couplé à BindingObject, ce qui est prohibitif si vous souhaitez effectuer une sérialisation POCO, etc.

Et comme indiqué ci-dessus, le système Xaml d'UWP est terrible. A moins qu'il y ait quelque chose que vous savez et que j'ignore. :tuck_out_langue:

Pouvez-vous expliquer ce que vous entendez par "implémentation Xaml purement gérée" ? FWIW, mon attente ici n'est pas exactement un port direct 1: 1 de System.Xaml mais une "nouvelle" bibliothèque System.Xaml (Microsoft.Xaml?) Qui prend toutes les qualités de System.Xaml, Xamarin.Core.Xaml, et ... eh bien, je dirais Xaml d'UWP, mais... :wink:

J'ai entendu dire qu'en interne, il y a une préférence pour Xaml d'UWP par rapport à WPF et autres Xaml, bien que différentes équipes chez Microsoft puissent avoir des opinions différentes. Le Xaml de DotNet est sans aucun doute plus puissant et plus flexible, mais comme pour tout ce qui concerne ces descripteurs, il présente probablement des inconvénients qui expliquent pourquoi UWP est si réduit.
Et par non purement géré, je fais référence à la seule bonne chose à propos de Xaml d'UWP en ce sens qu'il n'est pas exclusif à DotNet. Ainsi, un futur potentiel Microsoft.Xaml pourrait être une implémentation native multiplateforme avec une façade gérée afin qu'elle puisse être utilisée en dehors de DotNet. (Cela exclurait également son inclusion dans dotnet/corefx à moins que cette future bibliothèque ne soit décidée à être livrée en tant que composant de CoreFX)

D'accord, je suis confus. Quand vous dites .NET... vous parlez de 4.6, n'est-ce pas ? D'après ce que j'ai compris, il s'agit d'une bibliothèque .NET Core Xaml, qui, de par sa nature même, est multiplateforme et exclusive à .NET (4.6) ? Quand vous dites "non exclusif à DotNet", vous voulez dire "est-ce que DotNet est inclus" ? Doubles négatifs. :stuck_out_tongue : Ce n'est évidemment pas vrai car vous ne pouvez pas utiliser UWP Xaml dans .NET 4.6 (vous ne voudriez pas non plus :stuck_out_tongue :).

S'il vous plaît éclairez-moi sur ce que j'ai mal ici. De plus, un bon objectif ici serait de faire expédier Xaml dans le cadre de CoreFX. Certaines discussions tournent autour de cela depuis un certain temps . - et bien sûr, si je ne me trompe pas @RichiCoder1 , vous avez votre vote pour faire exactement cela dans ce fil... Je me demandais où j'avais déjà vu votre tag ! :le sourire:

Et je voudrais également dire que j'ai également entendu les penchants internes vers Xaml d'UWP, mais c'était avant qu'il y ait une discussion communautaire à ce sujet commençant dans ce fil au-dessus et au-delà ( discussion Twitter de Tim Heuer ). L'aiguille a bien bougé depuis. Au moins, c'était mieux ! MDR. Il y a ceux qui pensent à tort que "Xaml est pour l'interface utilisateur" et puis il y a le reste d'entre nous qui comprend comment cela fonctionne. :tuck_out_langue:

Quand je dis DotNet, je veux dire DotNet, y compris le noyau et le cadre. Et je me rends compte que vous ne pouvez pas utiliser UWP Xaml en dehors des applications UWP, je faisais référence à la possibilité de l'utiliser dans les applications C++ UWP. Donc, quand je dis qu'il ne doit pas être exclusif à DotNet, je veux dire être sur le point de l'utiliser à partir de C++ (ou potentiellement d'autres langages). Et j'imagine que la raison pour laquelle l'équipe propriétaire de XAML ne considère pas sérieusement les cas d'utilisation en dehors de l'interface utilisateur est parce que c'est soit rare, soit, dans certains cas, activement calomnié avec Microsoft ou avec des partenaires. Ce n'est pas mon avis personnel, j'apprécie son expressivité et sa puissance.

OK super @ RichiCoder1 merci pour votre explication. Je pense que je te suis _presque_ complètement maintenant... quand tu dis "framework" tu veux dire 4.6 ?

À mon avis, je dirai qu'une partie de la raison pour laquelle l'équipe interne estime qu'il est rare de l'utiliser en dehors de l'interface utilisateur est liée à un faible engagement avec les développeurs, comme je pense que le message de Tim le montre. Je suis également coupable de cela, car je n'ai vraiment pas été enthousiaste à l'idée d'engager MSFT il y a environ un an environ ? En fait, le Tweet de Tim concernait un vote que j'avais fait, après que je me sois plaint personnellement/en privé à tout le monde depuis Windows 8.0 que le système Xaml était complètement différent et différent de ce qu'il devrait être. Quand j'ai entendu des rumeurs selon lesquelles UWP (Windows 10) Xaml était fondamentalement le même - après 3 ans sans innovation ni amélioration - c'est à ce moment-là que j'ai intensifié. Avec le recul, cela aurait dû être beaucoup plus tôt.

Sûr de dire que c'était une leçon d'apprentissage majeure. Je suis (ou du moins j'ai l'impression d'être) maintenant beaucoup plus intégré dans l'écosystème et j'ai l'impression d'être entendu. En fait, un vote _très important_ que j'ai fait il y a un peu plus de quatre mois a été marqué comme étant en cours d'examen par la prestigieuse équipe de Visual Studio plus tôt cette semaine. Dire que mon monde a été secoué est un euphémisme. :le sourire:

Par framework, je l'utilise pour faire référence au bureau .Net. Cela semble être le moyen populaire de différencier Core et Full Framework.

Je suis d'accord. L'une des bonnes choses à propos de tous les mouvements récents de Microsoft est qu'il force presque un meilleur engagement avec les développeurs :).

Très excité à ce sujet moi-même! Maintenant, juste pour voir comment cela se jouerait. Cela pourrait signifier n'importe quoi, de rendre l'outillage Xamarin de première classe à côté des applications UWP utilisant leurs projets partagés, ou cela pourrait signifier quelque chose de haut niveau, même cela. Seul le temps (et je suppose, // Build) nous le dira.

OK super... merci pour l'info. :+1:

Quant à //build... en effet. :) Personnellement, j'aimerais voir un nouveau modèle entièrement basé (vaguement ?) sur UWP et utiliser la nouvelle bonté Xamarin pour le déplacer vers iOS/Droid. Un modèle Xaml plus fort ne ferait pas de mal non plus. Je suppose que nous devrions garder ce fil silencieux jusqu'après le 28 avril, après tout. :tuck_out_langue:

J'espère que vous pourrez le faire ! :)

Je suppose que les gars UWP adopteraient plus facilement une implémentation XAML qui n'intègre pas le code .NET (même si ce code était du .NET Core).

Comme une boîte noire autonome (ou uniquement en fonction d'UWP, mais nous ne le voulons pas puisque UWP n'est pas [encore] multiplateforme et si c'était le cas, il en manquerait encore une version gérée qui pourrait s'exécuter en .NET/ Silverlight [ne peut pas verrouiller vos applications uniquement sur la cible Win10]).

Mais c'est plus ou moins utopique je pense, à moins de le faire avec une couche d'abstraction et des pluggables/drivers pour les différentes applications de XAML (pour UWP UI, pour Workflow, pour WPF/.NET, pour Silverlight etc.). Comme la façon dont DirectX semble une machine via HAL (Hardware Abstraction Layer), qui ouvre également la possibilité pour HEL (Hardware Emulation Layer - voir les mentions à http://www.developer.com/net/asp/article.php/968461/What -est-DirectX.htm). Bien sûr, si vous ne faites pas attention, cela pourrait également ouvrir la porte à l'enfer en termes de performances, mais puisque DirectX pourrait le tirer, je suppose qu'une telle architecture n'est pas mauvaise

+1 pour le portage de System.Xaml vers .NET Core.
J'espère voir un seul dialecte XAML unifié (.NET Xaml, UWP Xaml, Xamarin Xaml) utilisé sur toutes les plates-formes à l'avenir.
Il pense qu'une version .NET Core de System.Xaml est nécessaire pour y parvenir.

+1

Pour éviter les alertes de notification de masse, nous avons maintenant une nouvelle façon de +1 les commentaires individuels sur GitHub, afin de montrer notre intérêt/réaction pour le sujet en question :

Haha @ jasonwilliams200OK Pour ma part, cela ne me dérange pas les alertes de notification de masse des membres de la communauté exprimant leur intérêt rudimentaire pour une solution System.Xaml puissante et multiplateforme. :angel: Peut-être que d'autres sujets, je partagerais votre douleur/agacement/frustration, cependant. :clin d'œil:

Point valable (et précieux), dans tous les cas. J'ai ajouté mon :+1: pour la cause.

@jasonwilliams200OK

Merci d'avoir appelé ça !

FWIW, je viens d'inviter l'équipe Xamarin.Forms à se joindre à la conversation ici :
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

Ou le cas échéant, informez tout le monde _ici_ de la conversation _là_. :le sourire:

J'ai eu une excellente discussion dans les commentaires de ce post:
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

Fondamentalement, JSON vs Xaml pour le nouveau système de projet qui semble être en cours pour Visual Studio (hourra !). N'hésitez pas à vous joindre à nous. :) Je suis tellement content de voir que cela prend un autre aspect.

@Mike-EEE, consultez également cette feuille de route : https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. Le nouveau système de projet propulsé par Roslyn va être .. précieux.

whoa... fou que j'entende parler de ça maintenant. cela doit être ce à quoi Scott Hunter faisait référence dans l'article de blog susmentionné en ce qui concerne plus d'informations à venir dans un futur article. Bon à voir. Le pouvoir de Roslyn grandit. Cependant, je me sentirais plus à l'aise de voir quelques problèmes pour les définitions de projet sérialisées Xaml. :clin d'œil:

Voir le fichier readme de ce référentiel : https://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system (et le lien vers le blog VS MSDN ), il semble que nous pourrions remplacer divers composants à l'aide de MEF, ce qui permettrait d'insérer un sérialiseur supplémentaire pour analyser la définition de projet écrite en XAML. Personnellement, j'ai appris à préférer JSON à XAML/XML lorsqu'il s'agit de décrire les propriétés et les dépendances du projet, etc. car JSON est moins bruyant (eh bien, YAML est moins bruyant que JSON et la norme lang prend en charge les commentaires contrairement à std-JSON, mais dans le monde dotnet, YAML et d'autres langages avec une syntaxe sensible à l'indentation doivent encore gagner du terrain)

Personnellement, j'ai appris à préférer JSON à XAML/XML

SÉCURITÉ! RETIREZ CET HOMME !!! Hum, je veux dire... :)

Je suis pour prendre le meilleur des deux mondes. @SuperJMN et @Grokys pourraient en parler davantage, mais je pense que des efforts sont faits dans OmniXaml pour le rendre moins verbeux et moins bavard.

Mon problème avec JSON n'est pas avec JSON en soi, mais son approche de conception qui était également la base de la configuration .NET (qui, je suppose, était son inspiration), et c'est-à-dire que le schéma de l'objet est "encore un autre artefact" qui le développeur doit gérer/maintenir et _pas_ la définition de classe. Autrement dit, dans la programmation Xaml (comme vous le savez !), la définition de classe _est_ le schéma du document. En conséquence, cela donne une sensation très naturelle au développement du document, et aide/aide également avec l'outillage.

Sans parler de la santé mentale des développeurs. :sourire: Rien ne m'exaspère plus que d'avoir à rechercher un document de schéma obscur et à comprendre comment l'installer et faire fonctionner l'intellisense le plus simple.

L'autre problème que j'ai avec JSON n'est encore une fois pas spécifique à JSON, mais plutôt à l'état d'esprit Web et c'est la convention de dénomination. La configuration .NET en a également souffert. Autrement dit, vous pourriez définir un POCO tel que :

public class MyPoco {
    public string Property {get; set;}
}

Et son JSON (ou app.config) ressemblerait à quelque chose comme (et vous pouvez me renseigner là-dessus si je me trompe !):

{
 { "property": "Hello world I have inconsistent naming conventions!" }
}

Là encore, Xaml est aligné entre la définition de classe et son homologue sérialisé, c'est pourquoi je le préfère.

Je dois dire que la configuration .NET était la PIRE car sa conception produisait quatre artefacts pour chaque entité de configuration :

1. L'élément dans web/app.config
2. Le fichier .xsd que vous deviez lier comme par magie au web/app.config (je n'ai jamais réussi à le faire fonctionner !)
3. Les éléments ConfigurationElement et/ou ConfigurationSection qui ont pris les valeurs de app/web.config (et ont mappé le camelCase incohérent à PascalCase -- oh la folie !)
4. Le POCO qui a finalement été câblé à partir de l'élément de configuration. (OUF!)

Je n'ai pas suffisamment étudié la conception du projet JSON pour savoir s'il existe un objet POCO en cours de sérialisation avec le document .JSON ou si le mappage superflu décrit ci-dessus se produit également. J'aimerais savoir si vous connaissez la réponse à cette question.

Dans tous les cas, Xaml améliore cette conception en ne nécessitant que deux artefacts :

1. Le fichier de classe (.cs)
2. Le fichier de données (.xaml)

Enfin, merci pour ce lien vers le readme ! Je suis encore une fois "ce type" qui ne fait pas exactement ce que demande le dossier. :en riant:

s'il existe un objet POCO en cours de sérialisation avec le document .JSON ou si le mappage superflu décrit ci-dessus se produit également. J'aimerais savoir si vous connaissez la réponse à cette question.

Je pense que si vous considérez les attributs [DataContract] et [DataMember], alors le framework .NET (au niveau BCL) aide JSON et d'autres sérialiseurs de données. Cependant, il n'y a pas de littéraux d'objets JavaScript natifs/de bas niveau <-> C# POCO support de transition par le compilateur comme JSON vers JavaScript (et de nombreux autres langages) ou CSON vers CoffeeScript. Cependant, contrairement à XML avec tous ses liens XPATH XQUERY XSLT, JSON a le concept de schéma pour valider les données et JSON.net le supporte comme un champion.

Pour C#6 et supérieur, jetez un œil à ces problèmes/propositions https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+ dictionnaire , en particulier https://github.com/dotnet/roslyn/issues/6949 et suivez les liens à l'intérieur. Avec la nouvelle syntaxe d' initialisation du dictionnaire C#6 et ces propositions, il semble que C# devient sémantiquement plus convivial pour JSON.

Je dois dire que la configuration .NET était la pire

D'accord, vous pouvez également profiter du modèle "Configuration" et "IOption" introduit par l'équipe ASP.NET en tant que package plug and play : https://github.com/aspnet/Configuration , https://docs.asp.net/ en/latest/fundamentals/configuration.html , qui remplace l'ancien gestionnaire de configuration notoire lié à XML.

JSON a le concept de schéma pour valider les données et JSON.net le prend en charge comme un champion.

Cela ressemble à une définition de classe en tant que schéma. :) :) :)

il semble que C # devient sémantiquement plus convivial pour JSON.

Haha bien sûr, _any_ object est déjà compatible avec JSON. JSON est idéal pour faire ce qu'il est censé faire : noter les définitions d'objets de manière concise et lisible par l'homme. Et il ne fait aucun doute que JSON.net fait un excellent travail pour atteindre cet objectif. Lorsque vous entrez dans la description des _applications_, nous commençons à entrer dans le domaine où cette conversation commence à s'impliquer, euh, faute d'un meilleur mot. :le sourire:

En fin de compte, il y a deux scénarios ici (pour moi, du moins) : décrire les objets qui sont destinés à être transférés entre les limites de service (léger) et décrire les applications qui créent ces objets (significatif). Personnellement, j'aime rechercher la cohérence de toutes les manières possibles et minimiser les changements de contexte. Tant que nous gardons nos options ( IOptions ? :laughing:) ouvertes et permettons aux développeurs de choisir le format qui leur convient le mieux (et leur permet d'utiliser l'outil qui leur donne le sentiment d'être le plus efficace ! ) alors nous gagnons tous ici. :+1:

UWP XAML a moins de fonctionnalités par rapport au XAML .NET WPF classique. L'une des fonctionnalités qui me manque le plus sont les TypeConverters.

J'ai essayé de créer mon propre TypeConverter comme suggéré ici https://msdn.microsoft.com/en-us/library/bb546926 (v=vs.90).aspx (l'article est pour WPF TypeConverters)

Dans UWP, j'obtiens avec ce "Type inconnu 'voiture' dans l'espace de noms XML ' using:App2TypeConverters '"

        <ListBox>
            <local:car></local:car>
        </ListBox>

N'est-il vraiment pas possible d'ajouter un TypeConverter personnalisé dans UWP ? Ou existe-t-il une solution de contournement ? J'ai lu quelque part que le XamlCompiler utilise le IServiceProvider interne pour enregistrer le TypeConverter. Peut-être qu'il peut être enregistré avec lui d'une manière ou d'une autre?
Je souhaite également en savoir plus sur le contexte de la compilation XAML. XAML sera-t-il toujours généré en BAML ? Pouvons-nous en quelque sorte nous accrocher à la compilation XAML ?
Alors, veuillez ouvrir System.Xaml.

Sooooooo... cela signifie-t-il que System.Xaml va enfin rejoindre la fête ??? :sourire: :sourire: :sourire:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

Je vais intervenir ici et dire :
a) J'aimerais vraiment que XAML fonctionne avec .Net Core et
b) si , lorsque cela se produit, il serait plus logique d'utiliser la saveur UWP, car elle est déjà portée sur d'autres architectures (par exemple, la poussée IoT sur le Raspberry Pi).

Obtenir WPF XAML serait cependant incroyable, si cela est possible.

De la même manière que le noyau .NET a été essentiellement reconstruit à partir de zéro, sur la base de la dernière décennie d'apprentissage, je pense que la même chose devrait être faite pour XAML. L'évolution WPF/Silverlight/WinRt-XAML a été une débâcle complète. Un pas en avant, deux en arrière (un de côté). La promesse de XAML, Expression Blend, etc. ne s'est jamais concrétisée.

J'ai entendu Scott Hunter justifier l'absence d'interface utilisateur multiplateforme dans Dotnet Core l'autre jour en disant "Eh bien, ils ne se révèlent jamais bons. Sur Windows, les utilisateurs s'attendent à un bouton Windows, sur Mac un bouton Mac". Eh bien, je suis désolé - où a-t-il été ces 5 dernières années ??? Le Web domine entièrement la conception de l'interface utilisateur maintenant et sur le Web, il n'y a pas de "bouton standard" - mais devinez quoi ? Les utilisateurs ont réussi à s'en sortir. Cet argument va tout simplement à l'encontre de toute preuve. Ces interfaces utilisateur Web dominent désormais le commerce sur la planète. Mais apparemment, ce n'est pas assez bon pour Dotnet Core. Pourquoi ne pouvons-nous pas avoir un XAML multiplateforme sans se plier à aucune aspiration [imaginaire] "d'apparence et de convivialité de plate-forme standard" ?

Je suppose que les principaux obstacles techniques seraient de savoir comment interfacer "XAML" (ou quel que soit le nom de la plate-forme d'interface utilisateur de prochaine génération) avec une API 3D multiplateforme - car nous ne pouvons évidemment pas dépendre de Direct3D/Direct2D sur MacOS, etc. Mais je présume ce problème a été résolu par Unity etc qui parvient à atteindre cet objectif.

Microsoft a tellement traîné les pieds au sujet de l'open source de la famille de technologies XAML qu'il faut se demander si une cache secrète de bitcoins ou les clés privées de microsoft.com y sont cachées.

Allez-y MSFT : Open Source WPF/Silverlight/WinRT-XAML et laissez la prochaine ère dorée de l'UX commencer.

C'est assez incroyable d'entendre ce que vous dites à propos de Scott Hunter, @JackUkleja. As-tu une source/un lien pour ça ? Si ce que vous dites est vrai, alors en plus de ce que vous dites, cela montre une ignorance (étonnante) sur plusieurs fronts :

1. C'est exactement ce que Xamarin.Forms a tenté de résoudre.
2. Les UX / interactions / styles spécifiques à la plate-forme (ou imitant pour ainsi dire) sont une préoccupation qui peut et doit être abordée par thèmes. C'est ce à quoi WPF était très bon (bien qu'à votre avis, il pourrait et devrait être amélioré).
3. Pire encore, cela ne place aucune confiance dans le vivier de talents qui a créé avec succès WPF, sans doute le meilleur cadre de présentation de tous les temps. Êtes-vous en train de dire qu'ils ne peuvent plus résoudre ce problème? Ou du moins opérer la même magie qui a fait le succès de WPF d'une manière multiplateforme ?

Une bonne UX est une bonne UX. Comme vous le soulignez, le Web le démontre clairement. Les utilisateurs d'applications natives sont définitivement conditionnés à une certaine apparence pour leurs interfaces natives, mais encore une fois, cela devrait pouvoir être résolu à partir d'un thème.

Imaginez pouvoir afficher une application sur un appareil iOS dans un "skin" Droid (avec comportement) et vice versa. C'était/est possible avec WPF et c'est exactement le genre de réflexion qui devrait être poursuivie à l'avenir. C'est-à-dire que l'aspect/la convivialité/l'expérience ne doivent pas entraver le développement et la conception de l'application. Vous devriez être en mesure d'appliquer un thème, et whah, "ça marche." Malheureusement, cela a été / est un détracteur pour Xamarin.Forms dans la mesure où, même s'il tient compte de différentes plates-formes, il y a beaucoup de frictions pour s'assurer que tout fonctionne comme prévu sur chaque plate-forme cible.

@Mike-EEE Je suis presque sûr que Scott Hunter a dit des mots à cet effet dans cet épisode de dotnet rocks : https://www.dotnetrocks.com/?show=1291

Ré:

"le vivier de talents qui a créé avec succès WPF, sans doute le meilleur cadre de présentation de tous les temps"

... ma compréhension est qu'un grand nombre des architectes d'origine, certains de ceux impliqués dans WPF, ont quitté MSFT et sont allés chez Google et ont été impliqués dans Angular. De nombreuses idées de WPF apparaissent dans Angular et des frameworks connexes tels que les modèles. Mais quelle que soit la manière dont vous découpez ces frameworks Web, je pense que vous aurez toujours l'odeur du HTML/CSS en arrière-plan. Toutes les interfaces utilisateur n'ont pas de sens d'être basées sur des documents/sémantiques et c'est la nature de HTML, c'est pourquoi je pense que le monde pourrait toujours utiliser le "noyau XAML".

[jack...ne pense pas que les données sont correctes sur les architectes google et WPF]

@rrelyea C'était ma compréhension mais je peux me tromper. J'aurais pu jurer avoir lu que certains membres de l'équipe WPF travaillaient sur Angular cependant... Ian Ellison-Taylor entre autres ? (Bien qu'il semble qu'il soit de retour à MSFT maintenant...)

odeur de HTML/CSS en arrière-plan

Plus il y aura de conformité et de convergence vers les normes HTML CSS unifiées ou tout type de normes à cet égard (C, C++, JavaScript), mieux ce monde sera. Au lieu de cela, XAML, avec sa fonctionnalité unique, peut se présenter comme un cadre de sur-ensemble pour la pile HTML + CSS, etc. ou simplement comme un moteur frontal alternatif au Razor d'ASPNET : https://github.com/aspnet/Razor/issues/78 : ampoule:

@ jasonwilliams200OK FWIW/FYI il existe déjà un port "standard" HTML/CSS de .NET dans JSIL . Toute sa sortie est 100% compatible HTML5 et fonctionne dans n'importe quel navigateur moderne. C'est le genre de pensée auquel nous devrions aspirer, bien sûr (et aurait dû être la pensée depuis la disparition de Silverlight en 2011, mais je m'éloigne du sujet).

C'est-à-dire (à votre point, j'espère) l'idéal/demande est que les développeurs .NET ne devraient avoir à gérer que .NET/C#/F#/VB.NET et ne jamais avoir à toucher au CSS/HTML/JS, un peu comme comment Les développeurs Xamarin .NET n'ont pas à toucher aux fondements d'iOS/Droid (quels qu'ils soient. :wink: ).

@Mike-EEE, dans les langages de sur-ensemble (TypeScript vers JavaScript ou Less vers CSS), nous pouvons utiliser le code lang du sous-ensemble dans le sur-ensemble dans le même fichier, mais pas l'inverse. Ainsi, le concept de sur-ensemble va un peu au-delà du fonctionnement de phonegap, cordova, etc. :)

Haha ouais @ jasonwilliams200OK Je veux juste m'assurer que nous ne finissons pas par faire un cas particulier pour notre approche/stratégie avec le retour de .NET dans le navigateur. Toucher CSS/JS doit être considéré avec le même dédain que toucher au binaire. :tuck_out_langue:

Par exemple, il existe également un autre projet Fayde qui utilise Xaml (yay), mais qui dépend également de TypeScript (boo). C'est la façon de NE PAS le faire, car vous vous retrouvez finalement avec deux bases de code incompatibles - une en TypeScript/JS pour le code client, .NET pour tout le reste - ce qui est très coûteux en temps et en ressources.

moteur frontal alternatif au Razor d'ASPNET

Razor n'est qu'un moteur de template à mon avis. En fait, sur ce lien que vous avez mentionné, il est indiqué "... que vous pouvez choisir parmi une longue liste de moteurs de modèles frontaux pour coder".

J'avais même entendu des commentaires de MS contre des syntaxes spéciales de type C # comme Razor dans la page HTML, en faveur de frameworks qui utilisent des balises personnalisées à la place

btw, il y a aussi Bridge.net (http://bridge.net) et d'autres compilateurs C# vers Javascript qui pourraient être combinés avec des solutions XAML comme Fayde

Re XAML sur HTML5/JS/etc. Il existe un projet intéressant Granular qui réimplémente WPF. Il utilise Saltarelle pour compiler en JS. Un exemple en direct est ici .

Ce Granular est assez fantastique, @ethanhs. C'en était une dont je n'étais pas au courant. Puisqu'il a adopté la même approche CSHTML5 , JSIL, Bridge.net (que @birbilis mentionne), il souffre du même problème de ne pas pouvoir partager de code entre serveur et client via l'utilisation de PCL, ce qui est vraiment le seul viable façon de le faire ces jours-ci.

Et vraiment, aussi génial que soit ce projet, il résume à peu près le paysage infernal que les développeurs .NET ont dû endurer depuis la disparition de Silverlight. Lui et environ une douzaine d'autres font "un peu" du travail pour faire fonctionner .NET dans le navigateur, mais pas tout à fait toute l'expérience que ceux qui ont une expérience Silverlight attendent.

Il n'y a pas encore de solution unificatrice unique et solitaire qui fasse oublier Silverlight aux développeurs. On se rapproche pourtant. J'espère, du moins. WebAssembly semble prometteur mais je n'ai pas vu/entendu de développements significatifs depuis un moment maintenant. Le port / l'initiative piloté par JSIL semble avoir quelque peu ralenti et n'a pas eu d'enregistrement depuis octobre dernier.

Espérons que nous aurons une percée ici dans un proche avenir. J'aimerais voir une annonce faite lors de //build de l'année prochaine indiquant en tant que tel. :coeur: :+1:

Ce serait l'une des meilleures choses de ces dernières années pour XAML.
Votez ici !

Cool @bbougot. Il y a aussi un autre vote, qui a _enfin_ attiré l'attention, après près de 15 mois d'existence, sans compter les presque 3 ans de non-reconnaissance d'un terrible système Xaml pour commencer (mais je m'éloigne du sujet !) :
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(Sérieusement, 15 mois pour même reconnaître un vote pour un des problèmes les plus évidents ? Que fait l'équipe UWP là-bas ??? Quand l'équipe Visual Studio ou .NET prendra-t-elle le relais et redressera-t-elle le navire ??? .. oups, c'est vrai, je m'égarais...)

Aussi, n'oubliez pas de voter pour ce fil. Il se porte plutôt bien @ 60 actuellement, d'autant plus que ce problème a commencé avant que nous ayons des équipements aussi sophistiqués tels que GitHub Reactions. :le sourire:

Xaml est le seul à pouvoir unifier l'ensemble de l'écosystème client !
S'il vous plaît, débarrassez-vous de DirectX, embrassez OpenGL, s'il vous plaît !
UWP est à exécuter sur PC, sur téléphone, sur site web !
Vive Xaml !

Donc, question civile ici @terrajobst , @harikmenon et @karelz (je vois que vous avez ajouté une balise récemment alors félicitations, je vous entraîne là-dedans !). Par simple curiosité, j'ai décidé de devenir un peu aventureux et de vérifier le filtrage GitHub avancé (ou peut-être pas) sur ce référentiel. En pensant qu'il y avait beaucoup de votes et que non pour différentes questions.

Voici l'URL que j'utilise :
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Il semble que ce problème ait actuellement 82 votes positifs, et si j'ai raison, le prochain élément le plus proche de la liste est à 17. Cela fait de ce problème de loin le problème le plus demandé/voté dans ce rapport, n'est-ce pas ?

Si oui, j'étais curieux de savoir si cela avait une incidence sur vos priorités et/ou votre planification. De toute évidence, cela semble être une question / un élément _très_ populaire maintenant (encore une fois, si je comprends bien), donc je pense qu'il serait peut-être bon d'entendre peut-être une mise à jour ou un enregistrement en ce qui concerne éventuellement le démarrage d'une conversation vers des progrès dans la fabrication cette question une possibilité.

Ce serait formidable d'avoir une perspective / un contexte ici, et / ou si j'ai quelque chose de complètement mal compris en ce qui concerne la demande des clients. Ça arrive. 😄

Nos ingénieurs .NET Core se concentrent fortement sur .NET Standard 2.0 (également une forte demande des clients) - voir les détails ici et ici . Nous examinerons d'autres bibliothèques ne figurant pas dans cette liste après avoir mis .NET Core à la dernière norme.

Merci d'avoir signalé la requête upvotes !

Merci pour votre réponse @karelz ! Très appréciée. 👍

👼 👼 👼 Je laisserai ceci ici au cas où quelqu'un voudrait aimer/retweeter. 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

Je travaille avec xaml depuis la version 3 de .net, j'ai ressenti le downsize de silverlight et même sa mort. Je suis quelqu'un qui aime les changements pour l'amélioration afin de rendre les choses meilleures et plus utiles. Mais maintenant, avec l'UWP, je constate une régression au lieu d'avancer. Ne vous occupez pas de toutes les nouvelles fonctionnalités qui semblent géniales, mais en l'absence de la prise en charge complète de xaml comme l'application de bureau. J'ai essayé de créer une nouvelle application dans UWP, et j'ai appris à la dure que tout ce que j'ai appris a encore changé, je ne trouve pas beaucoup de support en ligne, comme l'endroit où la bibliothèque xaml a été déplacée. Par exemple l'orner qui était sous le framework n'est plus là, le x:static pour les propriétés qui ne fonctionnent pas, il faut chercher des heures pour trouver un exemple ou quoi faire. Il n'y a pas de lien pour montrer le depuis de l'ancien xaml vers le nouveau UWP...

@giworking Il est évident que MS doit prêter attention au développement de ses clients ! Comme Satya Nadella est cité, l'azule est le cœur et l'avenir de la SEP, l'énergie la plus puissante pour stimuler l'azule est l'ensemble de l'écosystème .net. Comparé à java, le côté client est presque la seule arme pour persuader les codeurs et les entreprises d'adopter le cloud de MS (en Chine, .net est vraiment dans une situation catastrophique, les gens parlent de java et réagissent, "qu'est-ce que f k s t xamarin?"). ....). Donc, en tant que codeur chinois, quand je vois xamarin , uwp, tapuscrit et cshtml5, je sais qu'il est possible d'unir l'ensemble du côté client en mode xaml+C#, mais pourquoi nos amis MS ne voient pas l'opportunité d'obtenir remonter la part de marché chinoise avec if?

Wow, ce problème compte maintenant plus de 100 votes positifs ! Merci beaucoup à tous ceux qui ont manifesté leur soutien. Si quelqu'un est intéressé, il y a un article vraiment ( vraiment ! ) génial par @terrajobst complet avec son formidable engagement de développeur de marque dans les commentaires ici :
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

(Sérieusement, chaque employé de MSFT qui publie un article de blog basé sur l'entreprise devrait suivre l'exemple de M. Landwerth sur la façon de publier et de suivre les commentaires inévitables, innombrables et innombrables qui surviennent par la suite. Il est vraiment au top et il semble comme beaucoup trop d'auteurs MSFT laissent simplement leurs messages se dessécher et laissent les questions pour mortes, ce qui est bien sûr une façon terrible de traiter votre public !)

Quoi qu'il en soit, cela vaut vraiment la peine d'être lu si vous ne l'avez pas déjà fait, en particulier les commentaires. Cela m'amène à la raison pour laquelle je poste maintenant car _Je suis très heureux de voir ce problème mentionné dans les commentaires avec la passion/le désir d'amener System.Xaml dans l'ère .NET Standard/multiplateforme_. 👍

154 votes positifs... et ça continue. 😎 Le prochain numéro le plus élevé est à 25 , pour référence. #Roue grinçante

Cela doit être fait. Occupez-vous en!

Nous avons une application @ReactWindows ciblant WPF sur laquelle nous aimerions utiliser .NET Native pour améliorer considérablement l'expérience de premier téléchargement/installation pour nos dizaines de milliers d'utilisateurs de Windows 7. Nous avons également des plans futurs pour apporter React Native à Linux et potentiellement réutiliser le code partagé @ReactWindows mais cibler Xamarin.Forms.

Avoir System.Xaml (et d'autres dépendances de type/méthode/assembly de WindowsBase, PresentationCore et Xamarin.Forms) disponible dans NETCore vNext est essentiel pour cette stratégie. Nous pouvons contourner cette lacune en re-créant et en re-ciblant les assemblys existants, ou en remplissant les types/méthodes manquants dans le System.Xaml de Mono et en le construisant pour .NET Core, mais préférerions vraiment que Microsoft intensifie et fournisse ce qui est nécessaire à la plateforme.. /cc @rozele @pre10der89

@matthargett Bonne chance pour ça. J'ai battu ce problème à mort lorsque je cherchais à apporter le flux de travail au noyau .net. Même allé jusqu'à tendre la main à l'équipe xaml. Ils ne sont même pas intéressés à distance par l'ouverture de System.Xaml. Je ne comprends pas pourquoi - il n'y a certainement rien qui mérite d'être protégé là-dedans.

Cela sera peut-être envisagé après la sortie de la version 2.0 fin avril.

Les gars, encore une fois, nous n'avons pas besoin de System.XAML pour que WF soit porté sur netstandard1.x ... Il y a déjà un bon travail de @dmetzgar dans lequel le noyau de WF fonctionne. La principale pièce manquante est Transactions qui, je pense, revient finalement dans netstandard2.x .

La principale directive du port @dmetzgar est de ne pas avoir de langage de conception lié au noyau et d'avoir des primitives de base afin que les gens puissent sérialiser le flux de travail comme ils le souhaitent et plus tard, créer des concepteurs par-dessus.

Bien sûr, cette approche conduira à une non-rétrocompatibilité avec les flux de travail actuels basés sur XAML, mais croyez-moi, déplacer n'importe quoi vers .Net Core EST un changement majeur, donc les gens doivent comprendre cela.

Il existe OminiSharp qui pourrait être exploité pour les concepteurs XAML, mais encore une fois, la conception/sérialisation est en dehors du noyau WF. Il doit être mince comme tout le reste avec .Net Core.

Je dirais que ce problème fait haut et fort que les gens veulent déplacer WF vers .Net Core, je pense juste que se plaindre auprès de l'équipe System.XAML pour l'OSS, n'est tout simplement pas productif. L'équipe XAML a d'autres priorités et elle est essentielle pour les activités Windows/UWP/Xamarin, alors ne vous attendez pas à ce qu'elle soit OSSée si tôt. Au lieu de cela, je demanderais à @dmetzgar de rendre officiellement public le repo WF sous .Net Foundation, et de guider la communauté pour qu'il soit opérationnel sans fixer de calendrier ni de promesses sur la publication de netstandard2.x . Ce serait un travail continu mené par son équipe et aidé principalement par la communauté qui veut clairement aider et s'en sortir.

Regardez à quelle vitesse les choses évoluent dans le projet d'Orléans ... C'était une recherche Microsoft qui a été OSSed l'année dernière et c'est l'un des référentiels les plus importants et les plus actifs sur .Net Foundation et il est principalement motivé par les efforts de la communauté (il a toujours un l'équipe MSFT qui y travaille à plein temps).

Quoi qu'il en soit, à mon humble avis, je pense que nous devons arrêter de bavarder et commencer à faire quelque chose. Il est clair que l'équipe @dmetzgar n'a pas de bande passante pour travailler là-dessus car leur principale préoccupation est de prendre en charge les principaux utilisateurs de WF, qui sont essentiellement de grands déploiements Sharepoint qui n'ont pas l'intention d'accéder au noyau .net. Il doit donc s'agir d'un effort communautaire (supervisé par l'équipe de @dmetzgar ).

Les gars, encore une fois, nous n'avons pas besoin de System.XAML pour que WF soit porté sur netstandard1.x...

@galvesribeiro c'est peut-être vrai, mais ce problème consiste à faire porter System.Xaml sur .NET Core, dont il s'agit de loin de la fonctionnalité la plus demandée dans le référentiel où l'équipe .NET sollicite des commentaires. Si vous n'écoutez pas vos commentaires, alors pourquoi les solliciter ? Quoi qu'il en soit, WF est simplement _un_ des scénarios qu'un port System.Xaml satisferait. Comme vous le savez (ou devriez !), System.Xaml est capable de beaucoup plus.

L'équipe XAML a d'autres priorités et elle est essentielle pour les activités Windows/UWP/Xamarin, alors ne vous attendez pas à ce qu'elle soit OSSée si tôt.

Oui, c'est en quelque sorte le problème ici et ce que nous demandons de changer. :) De plus, je ne suis même plus sûr qu'il y ait une "Xaml Team" de nos jours, n'est-ce pas ?! On a vraiment l'impression que cette technologie a été fermée et que nous commençons à en avoir le tour.

Quoi qu'il en soit, à mon humble avis, je pense que nous devons arrêter de bavarder et commencer à faire quelque chose.

100 % d'accord. FWIW, @SuperJMN vient de publier OmniXamlv2.0 , il y a donc des efforts communautaires en cours qui peuvent être mis à profit tandis que MSFT priorise leurs énergies et leurs efforts autour de ce problème (qui, d'ailleurs, durent depuis environ 11 mois maintenant - et ça continue).

En parlant de cela, voici un joli fil de discussion sur exactement cela (c'est-à-dire l'inactivité de MSFT à ce sujet), avec une citation de @terrajobst :

Pour être clair, je ne dis pas que System.Xaml ne peut pas ou ne doit pas être multiplateforme. Ce que je dis, c'est que System.Xaml n'est pas très utile en dehors de WPF et WF, et NuGet est une métrique proxy raisonnable pour cette instruction. Bien sûr, System.Xaml pourrait être rendu significatif en dehors du domaine de l'interface utilisateur, mais c'est une étape secondaire. Je préfère utiliser nos ressources MAINTENANT pour que les éléments fondamentaux fonctionnent bien et soient complets. En outre, en ayant une base convergée, le portage de composants de niveau supérieur, tels que System.Xaml, devient également beaucoup plus facile.

Ce n'est donc pas une déclaration soit-ou; c'est une déclaration d'ordre d'exécution.

En écartant la déclaration très incorrecte selon laquelle System.Xaml n'est pas utile en dehors de WPF/WF, tout cela me semble être un gestionnaire de projet, sans aucune intention de jamais contourner ce problème. Mon objectif n'est pas de critiquer cette déclaration car je soutiens pleinement Immo et l'excellent travail qu'il accomplit ici. Cependant, j'ai fait le tour du bloc suffisamment pour permettre à ce genre de langage de me donner une pause et de me mettre dans une position attentiste (ou plutôt "croyez-le quand je le vois" LOL !) concernant ce problème.

En attendant, je soutiens les efforts actuels dans .NET Standard 2.0 et j'attends avec impatience ce que cela donnera. Peut-être que ce serait mieux que prévu. À tout le moins, il semble que nous serons en mesure de récupérer System.Xaml pour les projets .NET Core fonctionnant sur des plates-formes Windows, ce qui est un bon début pour moi. 👍

@Mike-EEE tout d'abord, je suis désolé ... Je pensais que je répondais à ceci https://github.com/dotnet/corefx/issues/2394 oO Ces deux problèmes étaient trop souvent corrélés pour que je sois confus.

Deuxièmement, je ne dis pas que XAML n'est utile que pour l'interface utilisateur. Je l'ai utilisé pendant tant d'années sur les versions TFS, WF lui-même et dernièrement pour l'interface utilisateur. Il existe un tas de DSL comme Azure ML et d'autres qui pourraient tirer parti de XAML.

Ce que je voulais dire, c'est que je ne vois pas XAML être porté si tôt sur .Net Core. Comme l'a dit Immo, ils doivent d'abord bien faire les choses avec les plateformes actuelles. .Net Core n'a même pas encore de bibliothèques natives de manipulation d'images.

Il existe plusieurs implémentations XAML allant de WPF complet à faible et manquant de nombreuses fonctionnalités dans UWP. Il doit être unifié et stabilisé avant qu'une telle chose ne devienne OSS. Je ne parle pas des équipes qui y travaillent. Je pense juste que je ne ferais pas de différence avec eux si je devais prioriser mes ressources.

Cordialement à WF, désolé encore une fois, mais mon commentaire précédent était principalement destiné à ceux qui espèrent que ce problème est la raison pour laquelle le port WF au cœur ne se produit pas aussi rapidement, ce qui n'est pas vrai .

Ces deux problèmes ont été corrélés trop de fois pour que je sois confus.

Haha @galvesribeiro Je ne peux pas vous dire (ou j'ai peur de l'admettre) combien de fois cela m'a mordu aussi. Pas de soucis à ce sujet. Pour ma part, j'apprécie l'entrée malgré tout !

FWIW, il semble également que @cwensley continue de faire un excellent travail sur @ Portable.Xaml , ayant récemment apporté des améliorations de performances à son adaptation mono-basée de System.Xaml qui le rend plus rapide que la version originale. Il semble presque que cela pourrait être un bon point de départ pour un effort ici, car il est probablement le plus proche de l'expérience System.Xaml d'origine de toutes les saveurs/options disponibles. Juste mes deux centimes induits par la caféine pour le matin.

Veuillez porter System.Xaml vers .NetCore

FWIW, plus de 200 votes pour ce problème, maintenant à 202. Le prochain problème le plus élevé est dotnet/corefx # 13526 assis à 47. Eh bien, ÉTAIT 47 ... il est maintenant de 48 après mon vote. :) (Allez lui montrer un peu d'amour, c'est une bonne idée.) #squeakywheel

Merci pour le rappel @Mike-EEE ;-). Pour définir les attentes : nous ne sommes toujours pas encore prêts à commencer à creuser profondément - j'espère personnellement que d'ici mars, nous pourrons commenter davantage nos prochaines étapes officielles, même si c'est à nouveau "nous n'avons pas encore de plans" (avertissement : j'essaie de communiquer ma meilleure supposition personnelle, veuillez ne pas la traiter comme une promesse officielle de l'équipe !).

Lorsque nous avons discuté un peu du problème la dernière fois, la question clé qui a surgi était de déterminer lequel des plus de 200 votes ne concernait vraiment que System.Xaml contre WPF. L'hypothèse étant que beaucoup de gens ne font pas la distinction entre les deux. Une suggestion sur la meilleure façon de s'y prendre? (par exemple, créer 2 problèmes spécifiques et demander aux gens de voter pour WPF contre "Xaml pur, pas WPF")

Il serait également utile d'avoir une liste récapitulative des scénarios pour System.Xaml avec quelques estimations prioritaires (ils sont maintenant dispersés dans une longue discussion). @Mike-EEE est-ce quelque chose que vous pourriez nous aider à mettre en place s'il vous plaît ? (comme vous semblez avoir un fort intérêt et une connaissance approfondie du domaine)

Définitivement System.Xaml est ce que les gens veulent @karelz. Si quelqu'un pense à WPF ici, ce n'est pas le bon endroit à mon humble avis. Il existe un tas d'autres frameworks qui exploitent XAML comme WF, TFS Build, etc. qui utilisent toujours System.Xaml et cela nous donnerait un gros coup de main.

@karelz J'apprécie vraiment votre réponse ici. Merci d'avoir pris le temps de le faire. Comme @galvesribeiro le mentionne, System.Xaml est plus qu'une simple interface utilisateur, ce qui semble être une compréhension clé qui manque malheureusement à beaucoup de MSFT. C'est un paradigme de sérialisation puissant qui le place au-dessus et au-delà de toute autre solution de sérialisation, en particulier et particulièrement lorsqu'il s'agit de décrire des applications, ce qu'il fait de mieux (le "A" dans son surnom, après tout). Malheureusement, "application" a été confondue avec "UI" et donc la friction ici.

Négliger cet aspect était un échec clé de l'UWP et fait partie de la raison pour laquelle personne n'aime vraiment travailler avec. À l'inverse, Xamarin semble avoir compris cet aspect clé dans sa saveur de Xaml, mais il est interne et non exposé comme une offre faisant autorité de première classe devrait l'être (ce qui est à peu près ce que ce problème est après ici).

TBH, le portage de System.Xaml par @cwensley dans Portable.Xaml semble être un précurseur pour le moment. Il a non seulement porté System.Xaml de Mono (en conservant son API globale familière), mais a ajouté de nouvelles fonctionnalités et a en fait amélioré ses performances pour qu'elles soient _meilleures_ que celles de System.Xaml.

À mon avis, ce problème pourrait être aussi simple que de travailler avec @cwensley pour faire de ce qu'il a obtenu la bibliothèque Xaml multiplateforme faisant autorité à utiliser à l'avenir.

En dehors de cela, c'est là que cela devient délicat et pourrait ajouter à votre vision (naturellement) compliquée de ce problème. Comme System.Xaml fournit un langage expressif et puissant pour décrire les applications (encore une fois, pas seulement les interfaces utilisateur), il dispose également d'un excellent support d'outils intégré à Visual Studio (et bien sûr Blend). Donc, idéalement, ce serait génial de continuer cette même expérience formidable et de conserver d'une manière ou d'une autre l'expérience de conception de Xaml d'une manière multiplateforme, mais personnellement, cela demande une cerise sur le gâteau dont nous discutons ici. :)

De plus, pour réitérer ici, la promesse (et la livraison) de Xaml était également une amélioration du flux de travail de développement entre le concepteur et le développeur. J'aime à penser que nous pouvons finalement aller plus loin et améliorer le processus entre le développement et _devops_. Autrement dit, j'aimerais voir un monde où devops fonctionne dans des éditeurs de configuration d'application magnifiquement conçus (alimentés par Xaml) pour gérer et maintenir les applications déployées.

_L'idée ici est de réduire le coût global du développement d'applications, du codage au déploiement. Travailler avec de jolis éditeurs et designers est moins cher (du point de vue des ressources) que de devoir trouver et employer quelqu'un qui doit mettre la main sur le code (et/ou les scripts) pour que la magie opère._

Je partage cela avec vous en tant que perspective de vision, juste pour que vous en soyez conscient. Cependant, je ne sais pas à quel point cela vous intéresse d'entendre cela. 😉 Alors, s'il s'agit simplement d'un "que faudrait-il pour clore ce sujet et vous faire partir ?" Je suggérerais d'explorer la possibilité de travailler avec M. Wensley et de voir si nous pouvons tirer parti de son excellent travail jusqu'à présent (ou s'il est même ouvert à le faire). S'il existe un moyen d'orienter cela afin qu'il puisse être le package Xaml multiplateforme faisant autorité pour la version de .NET Core Wave 2 (vers mai environ ?), alors c'est encore mieux. :)

Merci pour l'info, ça m'intéresse vraiment. J'ai aussi l'impression que ma ou mes questions précédentes n'ont pas répondu à mes attentes, alors laissez-moi essayer de souligner quelques points :

Oui, je suis vraiment intéressé par les détails. Je ne pense pas que quiconque conteste Xaml != WPF du côté MSFT. Je n'ai certainement pas essayé de faire ça. Je sais juste ce que je ne comprends pas entièrement, et j'essaie de combler les lacunes - c'est-à-dire de comprendre pleinement la motivation et le besoin des scénarios de "pur Xaml".
(BTW : je ne comprends pas très bien votre scénario devops et comment Xaml est la seule/meilleure chose pour vous aider ? Ou comment il est réellement utilisé dans le scénario ?)

Je ne suis pas là pour essayer de clore ce sujet. S'il te plaît! Cela ne m'a même pas traversé l'esprit. Je suis ici pour aider la communauté à résumer la demande, de sorte qu'elle puisse être discutée avec les bonnes personnes (pensez aux administrateurs dans ce cas). Oui, cela signifie en partie que moi (et/ou quelques autres MSFT) devons bien comprendre la demande pour la représenter plus haut - d'où mes questions.

J'avoue que je suis un bon exemple d'une personne qui n'a pas distingué Xaml et WPF avant de voir ce problème. À partir de discussions aléatoires avec d'autres membres de l'équipe .NET, beaucoup savent que Xaml ! = WPF, mais ils ne voient pas la "valeur énorme" d'avoir Xaml pur qui est présenté ici - d'où mes questions ci-dessus sur les scénarios. Les scénarios m'aideront/nous aideront à mieux comprendre la motivation et à mieux raconter/vendre l'histoire. (J'espère que ce n'est pas une surprise que lorsqu'il n'y a pas d'histoire claire, personne ne se sente pressé de la financer :) - l'histoire est une condition préalable au financement)
Alors inventons le pitch d'ascenseur pour le faire avancer.

En ce qui concerne le travail de @cwensley - c'est formidable d'entendre qu'il pourrait y avoir des solutions pas si chères. Mais encore une fois, il serait vraiment utile de comprendre d'abord le contexte et POURQUOI, avant de passer à la solution. J'espère que ça a du sens. (Je n'essaie pas d'être dédaigneux ou quoi que ce soit - je répète simplement qu'il est plus facile de faire avancer les choses lorsque le POURQUOI est compris et convenu)

@galvesribeiro Si quelqu'un pense à WPF ici, ce n'est pas le bon endroit IMHO

Je ne partage pas votre confiance dans le fait que les plus de 200 personnes qui ont voté comprennent vraiment le Xaml != WPF jusqu'à de tels détails. Aussi, je suppose qu'au moins quelques-uns le regardent - ouais, commençons par Xaml, il sera alors plus facile de demander WPF. Donc, leur scénario à l'esprit tout le temps est WPF, tandis que "Xaml pur" n'est qu'un premier pas vers cela.
Et peut-être que je me trompe (bien que je ne sois pas la seule personne de l'équipe .NET à avoir ces doutes) ...
Un autre angle pourrait être de décomposer le "Xaml pur" en une liste de scénarios (WPF, devops ci-dessus, peut-être quelques autres ?), puis de demander aux gens de voter pour eux - Lequel d'entre eux compte vraiment pour ceux qui ont voté ici ? Qu'est-ce qu'ils veulent vraiment?
(Ce n'est pas une tactique de retardement, ou quoi que ce soit de mal, j'essaie de comprendre le "client" ici. J'espère que cela a du sens - si vous avez de meilleures suggestions sur la façon d'accéder à ces données, parlez-en, je suis ouvert à d'autres approches )

EDIT : Comme d'habitude, si vous pensez que je n'aborde pas le problème de la bonne manière, veuillez le dire. J'essaie de faire de mon mieux ici pour aider - avec les meilleures intentions. Je ne souffre pas de l'illusion de tout savoir ou de penser que je suis plus intelligent que tout le monde.

@karelz Il existe un tas de frameworks d'interface utilisateur qui réinventent la roue et écrivent leurs propres langages de balisage simplement parce que XAML n'est pas croisé même s'ils n'aiment pas du tout WPF. Avalonia est l'un des meilleurs. Ils utilisent Omnisharp alors qu'ils pourraient utiliser le XAML natif à la place.

Workflow Foundation est un gros utilisateur/client de XAML et les utilisateurs du fil Port WF to .Net Core posent toujours des questions à ce sujet.

Alors oui, je suis d'accord avec vous que nous devrions établir les attentes ou dessiner un ensemble de fonctionnalités brutes sur ce qui est attendu du cross-plat System.Xaml ainsi que les utilisations souhaitées comme par exemple UI et WF.

@karelz

Aussi, je suppose qu'au moins quelques-uns le regardent - ouais, commençons par Xaml, il sera alors plus facile de demander WPF. Donc, leur scénario à l'esprit tout le temps est WPF, tandis que "Xaml pur" n'est qu'un premier pas vers cela.
Et peut-être que je me trompe (bien que je ne sois pas la seule personne de l'équipe .NET à avoir ces doutes) ...

Alors... quel est le problème avec ça ? Une solution multiplateforme de type WPF pourrait être une bonne chose. Xamarin ne peut pas créer d'interface graphique de bureau multiplateforme.

@ jnm2 ce n'est pas mal - mais si c'est le scénario principal (90% +), nous devrions prévoir de faire les deux. Avoir Xaml sans le WPF ne va pas aider dans ce cas (du moins pas beaucoup). Et cela pourrait créer une illusion (potentiellement) invalide que WPF est engagé et viendra peu de temps après.

L'intégration de WPF / GUI dans .NET Core sera une étape importante pour .NET Core, qui cible désormais principalement les scénarios de serveur et les applications de console.

@jnm2 avoir System.Xaml aiderait massivement les gens (comme moi) qui _essayent_ d'apporter quelque chose comme WPF sur d'autres plates-formes (https://github.com/AvaloniaUI/Avalonia).

@grokys , cela ressemble à un scénario raisonnable - pouvez-vous en dire un peu plus ? Quelle serait l'ampleur de l'aide? Qu'est-ce qui est difficile sans cela ?

J'utilise également Xaml pour mon framework d'interface utilisateur de bureau multiplateforme (non WPF), Eto.Forms . C'est pourquoi j'ai créé le projet Portable.Xaml pour commencer, et cela a bien fonctionné pour moi et mes utilisateurs jusqu'à présent.

Je ne suis pas opposé à aider à en faire l'implémentation xaml multiplateforme "faisant autorité" (comme le dit @Mike-EEE). Cependant, gardez à l'esprit que je ne travaille dessus que pendant mon temps libre (;

@karelz
Non seulement les cadres d'interface utilisateur, il peut être utilisé dans de nombreuses scènes comme XAML à HTML

@Kation pouvez-vous partager plus de détails sur ce que vous voulez dire exactement ?

BTW : J'ai commencé à résumer les scénarios dans le premier article. Si votre scénario n'y figure pas, veuillez le décrire et une fois qu'il sera compris, je l'ajouterai ici.

@karelz
Avec le puissant éditeur XAML de Visual Studio, nous pouvons rapidement créer du contenu de composants personnalisés.
Ensuite, je pense que nous pourrions utiliser XAML pour générer du contenu HTML dans un scénario spécial, encore plus de contenu SVG.
Il s'agit d'un framework XAML vers XML semi-fini pour .Net 4.5. https://github.com/Kation/WebPresentation

Je ne comprends pas pourquoi vous voulez générer du HTML ou du SVG à partir de XAML. Quelle est la valeur de XAML ici ?
Est-ce que la valeur qu'il a un bel éditeur VS ? Il existe aussi des éditeurs HTML, pourquoi ne pas les utiliser directement ?
Ou est-ce que je manque complètement le point?

@karelz
Parce que je veux générer du contenu comme WPF avec un modèle et un style dans certains projets.

@karelz merci encore pour le dialogue. Pour ma part, je l'apprécie beaucoup.

Je ne souffre pas de l'illusion de tout savoir ou de penser que je suis plus intelligent que tout le monde.

Oh, j'envie. 😉

Donc, leur scénario à l'esprit tout le temps est WPF, tandis que "Xaml pur" n'est qu'un premier pas vers cela.

Ouais, c'est encore la confusion que j'ai mentionnée. Xaml est un paradigme de sérialisation, pur et simple. Vous pouvez définir et décrire une application - et ses composants contenus - dans celle-ci. Pour commencer, voici un exemple d'_application console_ décrite en Xaml :
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

Vous pouvez voir qu'il existe des commandes décrites dans Xaml qui fournissent des instructions sur ce qu'il faut présenter à l'utilisateur via l'utilisation des entrées et sorties de la console. Cela n'a rien à voir avec WPF ou "UI" (bien que techniquement, il s'agisse de l'interface utilisateur dans le sens où la CLI est une interface utilisateur, mais j'espère que vous pourrez repérer la différence). De plus, vous pouvez voir que j'utilise des extensions de balisage et des déclarations de membres statiques directement dans le fichier. C'est quelque chose que je n'ai pas vu dans JSON ou tout autre format de données. C'est vraiment la puissance de Xaml, IMO.

Comme autre autre exemple de scénario "Pure Xaml", voici le fichier que je propose pour un nouveau MSBuild indépendant du format :
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(si vous montez d'un niveau, vous pouvez voir les autres formats qui font la même chose, il se trouve que c'est la version Xaml)

Il s'agit du fichier du processeur qui est à nouveau un ensemble de commandes ( System.Windows.Input.ICommand ) qui décrivent les étapes à suivre dans un processus de construction théorique. Encore une fois, pas de WPF ou d'interface utilisateur, mais vous pouvez voir qu'il émet des messages vers la console.

Une fonctionnalité que je veux souligner ici que j'ai mentionnée plus tôt est l'outil intégré dans Visual Studio que j'obtiens de ce fichier :

Sans effectuer de travail ni définir de schéma externe, Visual Studio "s'allume" simplement et fournit des éditeurs de propriétés complets avec des listes déroulantes et d'autres interfaces de conception basées sur le schéma de classe du fichier avec lequel je travaille (cela, espérons-le, facilitera le scénario devops comprendre).

En plus du fichier processeur, voici le projet théorique ou fichier d'entrée qui pourrait être utilisé pour envoyer au processeur :
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

Ici, j'essaie d'aller droit au but avec des _extensions de balisage_ utilisées pour fournir une version (probablement à partir d'un fichier externe) et également d'utiliser une requête pour fournir les fichiers collectés à construire (notez que vous ne voudrez peut-être pas le faire dans un système de construction final, mais je voulais démontrer sa possibilité).

BTW, cet exemple de code est entièrement opérationnel, vous devriez donc pouvoir obtenir le SLN à partir de ce dépôt et exécuter la version Xaml, les résultats devraient ressembler à ceci :

(Remarque : fonctionne sur ma machine , votre kilométrage peut donc varier. 😄)

BTW : Je ne comprends pas très bien votre scénario devops et en quoi Xaml est la seule/meilleure chose pour vous aider ? Ou comment est-il réellement utilisé dans le scénario ?

Ouais, j'ai débattu de l'opportunité d'entrer là-dedans, car je sentais que mon message devenait un peu long. J'espère que maintenant le composant de concepteur visuel ci-dessus peut aider à illustrer ce que je cherche ici.

S'il vous plaît, sachez et notez que pour moi, c'est la fin ultime du jeu et pourquoi je suis si enthousiaste à propos de tout cela. _La raison en est que cela finit par réduire le coût total de possession d'une application tout au long de sa durée de vie._

Donc, au cœur ici, ce dont nous parlons ici est le développement basé sur POCO, où l'édition et la conception se produisent sur les POCO utilisés dans un processus de candidature. Comme nous le savons, un développeur et concepteur travaillera sur un fichier Xaml décrivant les éléments POCO qui traitent du domaine de l'interface utilisateur (ici, le traditionnel "WPF" de "Xaml" si vous voulez).

Dans mon monde, j'aimerais voir ce processus étendu afin que le développement fournisse des fichiers Xaml que les devops puissent utiliser pour gérer/maintenir les applications qui ont été déployées dans un environnement en direct.

Vous pouvez considérer cela comme des fichiers de configuration en direct. La façon dont ils sont chargés devra être aplanie, mais le résultat final ressemblera à ce que vous voyez dans la capture d'écran ci-dessus dans Visual Studio. Au lieu que l'utilisateur final (devops) soit obligé de mettre la main sur le code (ou plutôt, qu'une organisation soit obligée d'embaucher les talents/compétences coûteux requis en tant que tels), ils travaillent plutôt avec des contrôles d'édition visuels limités et validés pour configurer et maintenir l'application.

_L'idée ici est qu'en raison de l'effort (et des compétences) requis pour le faire plutôt que d'être tenu de connaître et de comprendre le code, le coût de maintenance d'une application après le déploiement est considérablement réduit._

Un aspect que je n'ai pas mentionné à ce sujet est que ces contrôles sont en fait personnalisables. Visual Studio dispose d'une API étendue (bien que vieillissante) pour définir les éditeurs visuels attachés à ces propriétés POCO :
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

Tout cela est disponible dès maintenant dans Visual Studio sans aucun travail, surcharge ou effort supplémentaire. L'idée ultime ici serait donc de créer une suite d'éditeurs et de concepteurs puissants pour aider non seulement dans le processus de développement, mais en fin de compte dans le processus de devops.

Encore une fois, tout cela est visionnaire et sans aucune base réelle dans le monde réel (encore). Bien sûr, ce n'est pas totalement mon idée mais est inspiré par le groupe de modèles et de pratiques avec leur éditeur de configuration basé sur Windows Forms . J'ai simplement poussé cette ventouse un peu plus loin et j'ai vu l'utiliser grâce à la puissance de Xaml.

N'hésitez pas à me faire savoir si vous avez d'autres questions à ce sujet @karelz. Encore une fois, j'apprécie le dialogue. Non seulement c'est l'occasion de partager, mais c'est aussi l'occasion de valider mes idées et mes convictions. Et en revenant à l'idée de tout savoir (oui, je suis coupable 👼), j'essaie de garder l'esprit ouvert sur les choses et de me rendre compte que je n'ai pas toutes les réponses. C'est définitivement un processus que j'essaie continuellement de m'améliorer. Merci encore!

@karelz - Avalonia utilise actuellement OmniXaml comme moteur XAML, et bien que cela fonctionne assez bien, il y a encore des bogues et des fonctionnalités manquantes. Comme Portable.Xaml, OmniXaml est maintenu par un bénévole qui n'a pas toujours beaucoup de temps pour y travailler.

Si, en fait, vous décidez de ne pas ouvrir System.Xaml, la publication de votre suite de tests serait peut-être un bon compromis - au moins de cette façon, nous pourrions nous assurer que les implémentations tierces telles que OmniXaml et Portable.Xaml étaient aussi conformes que possible.

Je pense que ce dont l'écosystème .net a besoin, c'est d'un format de sérialisation par défaut lisible par l'homme - quelque chose comme JSON dans le monde Javascript. Ce format doit utiliser des types de données donet et utiliser directement les POCO comme schéma. Ensuite, ce format peut être utilisé pour décrire les objets POCO. Ces descriptions sont fortement et statiquement typées. Il peut s'agir d'une disposition d'interface utilisateur, d'une configuration d'application d'exécution, d'une description de projet/flux de travail ou même d'une communication entre deux programmes .net. Et même la communication avec d'autres écosystèmes (comme le web/Javascript) est également possible, étant donné qu'ils implémentent le format. Mais il devrait être conçu autour de l'écosystème .net. C'est pourquoi JSON/BOND/Protobuf/XML ne suffit pas.

Historiquement, XAML assumait quelque peu la responsabilité. Maintenant, la question est de savoir à quel point c'est bon pour ce rôle. Si c'est assez bon, alors je pense que XAML devrait être transformé en implémentations netstandard puis .net. Mais, si possible, d'autres formats doivent également être pris en considération. Je pense que la semaine dernière, http://www.ammyui.com/ est sorti. Un format de description de l'interface utilisateur axé sur la simplicité mais traduit en XAML. Parce que XAML n'était pas assez simple. J'ai moi-même proposé un format dans roslyn repodotnet/roslyn#16648 basé sur des initialiseurs (objet, collection et index). Et ma proposition est en fait tirée (puis légèrement modifiée) de cet article de blog par @bricelam de l'équipe Entity Framework. Son message et mon fil de proposition contiennent tous deux des exemples.

Ce que je veux dire, c'est qu'il devrait y avoir un format par défaut pour .net, que ce soit XAML ou autre chose.

@grokys Je voulais mentionner OmniXaml et j'ai invité @SuperJMN à la conversation ici, mais il ne semble pas qu'il veuille participer. Je ne sais pas s'il s'agit de paramètres ou quoi (j'ai également fait une tentative dans le gitter - puisque vous travaillez avec lui, vous pouvez peut-être avoir plus de chance en le traînant ici 😄 ). OmniXaml est bien sûr également le bienvenu dans cette conversation.

@gulshan +💯 👏 👏 ! Ha ha. Une partie de la confusion dans tout cela est que Xaml EST un format et une technologie MSFT. Avec tous les investissements et les outils construits autour de lui - à la fois avec MSFT et dans les entreprises, il est en effet incompréhensible qu'il semble y avoir un écart pour assurer sa continuité afin que les efforts et les investissements existants puissent être mis à profit.

Cela dit, j'aime ce que je vois avec Ammy et je continue d'avoir l'esprit ouvert à ce sujet. Ou essayez d'en avoir un. 👼

Je pense qu'il est important de répéter pourquoi nous nous embêtons même avec les fichiers de données pour commencer, la valeur principale de l'utilisation des formats de données est :

• Langue impérative agnostique . L'utilisation des fichiers ne nécessite pas la connaissance d'un langage de programmation.
• Convivial pour les concepteurs et les outils. _L'utilisation d'un concepteur visuel et/ou la mise en place d'une expérience de concepteur visuel avec votre produit permet de réduire le TCO _.

Cela dit, ce qui est personnellement important pour moi, c'est :

• Flux de travail intégré développeur/concepteur
• Expérience de concepteur visuel pour l'édition manuelle de fichiers.
  
  
  
  • PropertyGrid (fenêtre Propriétés) avec API d'éditeur extensible comme indiqué ci-dessus.
  
  
• Extensions de balisage
• Cerise sur le gâteau de génial : capacité à tirer parti de tout ce qui précède dans des scénarios en dehors du développement (exemple de développement ci-dessus).

Si toutes ces conditions sont remplies, je serais prêt à envisager "un autre format .NET", mais je préférerais évidemment conserver et étendre Xaml en tant que format. C'est une technologie MSFT et donc une propriété intellectuelle, après tout.

@Mike-EEE Si un format peut être désérialisé en POCO, toutes ces fonctionnalités devraient fonctionner. La fenêtre de propriétés dans VS apparaît également pour les scénarios non-XAML. Mais une chose qui m'inquiète est la lisibilité sans aucun support d'éditeur. Dans certains cas, vous devez modifier un fichier de configuration sur un serveur distant et vous n'avez que vim. Comparé à JSON, XML (et XAML) n'est pas si génial à cet égard, à mon humble avis.

Mais XAML a des choses uniques (en fait des fonctionnalités non XML) comme les propriétés jointes, qui sont difficiles à imiter dans un format de sérialisation simple.

Je voterais d'abord pour WPF (pour que je puisse enfin dire au revoir à xamarin.froms), puis xaml

La fenêtre des propriétés dans VS s'affiche également pour les scénarios non-XAML

Correct, mais ce n'est pas presque "éclairé" comme c'est le cas pour Xaml, avec des commandes d'édition entièrement personnalisables, etc. Corrigez-moi si je me trompe ici. Vous ne pouvez pas simplement placer votre curseur sur une propriété dans ces formats et avoir un rendu déroulant pour un champ enum (par exemple). Cette expérience est essentiellement la prochaine forme et version de WinForms, ce qui explique en partie pourquoi il est si agréable (WinForms est toujours populaire !).

Comparé à JSON, XML (et XAML) n'est pas si génial à cet égard, à mon humble avis.

Ouais, je suis d'accord, Xaml n'est pas exactement laconique, et vous entendrez des plaintes sur la façon dont il est verbeux. C'est là qu'OmniXaml fait sa marque en apportant des améliorations autour du formatage. Vous êtes également en concurrence avec d'autres formats tels que TOML et YAML, etc.

fonctionnalités non-XML) comme les propriétés jointes ...

Et les extensions de balisage. 😄 Ce sont des caractéristiques de sa vision.

Ce que (je crois) vous piaffez ici @gulshan est essentiellement un "Data AST (arbre de syntaxe abstraite)". Si nous parlons d'améliorer sérieusement Xaml (ou le format de données .NET), alors c'est la voie à suivre. Il pourrait même être propulsé par Roslyn. En fait, j'ai un vote uservoice pour cette idée même (avec un article de blog correspondant ). Malheureusement, ce n'est pas très populaire car c'est un peu difficile à expliquer, haha. Essentiellement, vous disposez d'un arbre AST (données) qui peut être écrit dans n'importe quel nombre de formats. De cette façon, les développeurs (et les outils) peuvent travailler avec lui selon le format qui leur convient le mieux (esthétiquement ou non).

donc je peux enfin dire au revoir à xamarin.froms

En accord avec vous sur cet aspect @groege. 😎

@Mike-EEE Je n'ai pas encore vérifié votre proposition Data AST. Oui, il est conceptuellement similaire à la proposition de sérialisation/notation d'objet par défaut pour .net. L'idée est difficile à comprendre en raison de son caractère abstrait. 😄

En ce qui concerne XAML, un format de sérialisation de données fortement typé basé sur .net réduira le besoin de nombreuses extensions de balisage XAML. Pourtant, il en restera certains, qui ne peuvent pas être initialisés par une expression (sans constructeurs). J'aimerais que certaines de ces fonctionnalités d'extension de balisage fassent partie de C # lui-même.

Eh bien, je n'ai pas eu de nouvelles de @karelz , donc je ne peux que supposer qu'il a depuis été perché devant son moniteur en tant que tel après avoir appris que vous pouvez définir une application console en Xaml :

(Mauvaises) blagues à part, n'hésitez pas à me faire savoir si vous avez d'autres questions.

En outre, à partir de This Week in .NET, ressemble à un moteur plutôt cool qui se prépare dans .NET Core . Le premier commentaire de ce post dit tout . :)

@Mike-EEE Je sais que je vous dois une réponse (elle est marquée comme importante dans ma boîte de réception et ouverte dans le navigateur).
Jusqu'à présent, je n'ai pu que parcourir les réponses (merci beaucoup à tous pour tous les détails et idées !), mais je n'ai pas eu le temps de me renseigner sur Xaml (comme vous le soulignez) et de lire attentivement toutes les réponses pour être capable de répondre... désolé, trop d'incendies et de high-pris en ce moment :(, j'y reviendrai plus tard, promis !

Tout va bien @karelz ! J'apprécie beaucoup vos efforts et votre dialogue ici.

Voici un vote pour l'open source WPF, toutes les autres versions de XAML sont des ordures en comparaison. Et sérieusement les gars, complétez la boucle à ce sujet, ayez un .net core / XAML STORE pour unix et MacOS.

@Mike-EEE vraiment désolé, je n'ai toujours pas eu le temps de revenir sur ce problème :(

Oh mec ne t'inquiète pas pour ça, @karelz je sais que tout le monde est occupé en ce moment. J'apprécie la conversation plus que tout. J'ai eu beaucoup de choses dans ma tête. C'est bien de le voir là-bas et d'y réfléchir en tant que tel. De plus, nous avons déjà attendu plus d'un an pour cela jusqu'à présent... qu'est-ce que quelques mois de plus environ ? :)

ils devraient opensource silverlight 5 .. depuis leur mouvement html5, leur mouvement win8 / winrt ... & maintenant uwp & win10 et xamarin .... COMMUN !! pathétique tu es perdu dans la la land comme hollywood ou quoi...

comment passer de silverlight 5 à toutes ces conneries ? COMMENT? comment pouvez-vous dire que vous respectez vos utilisateurs quand vous cassez toujours les interfaces d'assemblage .. vous renommez même votre propre paquet de nuget et ne donnez pas de moyen automatique de passer de l'ancien au nouveau dans le nuget .. c'est comme si vous utilisiez toujours tout le monde comme infini bêta-testeur parce que vous êtes trop stupide pour penser clairement avant de créer les idées et de les coder.

vous devez supprimer le besoin de projets ios/android/uwp dans les formulaires xamarin.

maintenant tout rassembler sous un f. framework you ass wipes (je recommande la couverture wpf/silverlight et le langage xaml mais diable si vous voulez tout mettre dans xamarin mais s'il vous plaît pouvez-vous ajouter des types de données sur le style/modèles .. omission étrange comme beaucoup et assurez-vous que votre f. nucrapget fonctionne A1 pour une fois .. pourquoi diable aurais-je besoin d'installer un paquet nuget dans toutes les assemblées dépendantes ? même chose avec la dll référencée .. ? vous n'avez aucune vision ... niet aucune ... capout ... tout ce temps coincé dans la merde ms .. j'aurais pu construire mon propre f. SDK de classe mondiale ..

Je ne peux pas passer une journée sans que MS mette une merde sur ma route... j'envisage sérieusement scala-js ou juste Swift... il est temps de quitter la maison ! J'en ai marre

Eh bien, cela leur a pris près de deux ans, mais UWP spécifie enfin des extensions de balisage pour son modèle Xaml :
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

A noter également, Noesis a lancé son produit v2.0 la semaine dernière, et il semble assez impressionnant. Son système Xaml comporte déjà des extensions de balisage (en C++, avec C# en route), et il ne leur a pas fallu sept ans pour arriver à la spécification. Il est également gratuit pour les développeurs indépendants maintenant. Une fois que vous avez pris en compte son support AmmyUI , je dois dire que c'est en haut de ma liste en ce qui concerne les modèles Xaml vont ATM :

http://www.noesisengine.com/

Hey @karelz peut-être pourriez-vous commenter cela. Mais savez-vous si la « spécification » UWP Xaml qui se produit actuellement a une corrélation avec ce problème ? Si non, savez-vous si c'est possible ? Idée folle ici, mais il pourrait être agréable de résoudre deux problèmes pour le prix d'un si cela peut être aidé. J'y ai également laissé un message sur le vote UWP, mais j'ai pensé que je ferais un ping ici aussi.

@Mike-EEE UWP Xaml "spec" est probablement piloté par une autre organisation (je pense sous Windows) - leur demander des détails sur l'uservoice est probablement le meilleur canal.

Oui, j'avais peur de ça. 😛 J'ai reçu une réponse là-bas, mais je dois être honnête, cela n'a pas beaucoup de sens pour moi.

D'après ce que je peux comprendre, il semble qu'ils vont continuer à adopter une approche à huis clos avec leur processus de spécification. Ceci est préoccupant car il semblerait que cela conduirait aux mêmes résultats que la dernière fois, se terminant par une API que personne ne veut utiliser ou adopter.

Peut-être qu'ils aiment secrètement que les développeurs se plaignent de leur travail. :)

Dans tous les cas, si vous lisez ceci et êtes un partisan de la collaboration et du développement transparents et open source, et que vous avez apprécié de faire partie du succès de l'initiative d'asp/.NET Core dans ce domaine, veuillez prendre une seconde pour vous diriger vers à WPDev UserVoice et envoyez-leur une note les encourageant à faire de même. Le lien a été mentionné plus tôt mais le revoici pour ceux qui lisent ceci par e-mail :
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Je dois appeler @birbilis et le remercier pour sa contribution précédente là-bas. Tout mot de confiance supplémentaire que quelqu'un pourrait prêter pour promouvoir le processus que nous utilisons tous ici serait grandement apprécié. 👍

soupir ... tout comme uservoice, vous faites voter les gens pour des choses et à la fin, même si c'était populaire, ne faites rien!

Mettre à jour:
https://github.com/microsoft/xaml-standard

Je suis sûr que @Mike-EEE sera très content de ça ;P

C'est une excellente initiative. Merci pour le partage @RichiCoder1

Malheureusement, il ne s'agit que d'une interface utilisateur. D'autres utilisations de XAML comme Sharepoint et WF sont probablement dépassées.

Mais oui, cela aidera au moins à normaliser le XAML sur toutes les plates-formes prises en charge.

Bon mouvement!

J'espère qu'ils le diviseront en couches

Par exemple, en dehors de la couche XAML de base non-UI, j'aimerais voir la couche 3D XAML

@galvesribeiro On dirait que quelqu'un a créé un problème: https://github.com/Microsoft/xaml-standard/issues/23 Je lui donnerais +1, aucune raison pour que la norme éventuelle ne soit pas divisée.

Je suis sûr que @Mike-EEE sera très content de ça ;P

Haha et vous avez raison, @RichiCoder1 ! Tout est faux et cassé et nulle part où il devrait être, mais c'est un début. ;) Merci de nous en avoir informé. 👍

Et très heureux de voir quelqu'un créer https://github.com/Microsoft/xaml-standard/issues/23 pour que je n'aie pas à le faire. ;) ;) ;)

S'il vous plaît, pensez à inclure WF (Workflow Foundation) dans XAML Standard !!.

@Suriman s'il vous plaît votez pour!
https://github.com/Microsoft/xaml-standard/issues/23

Donc, je déteste demander - et je le fais dans l'intérêt d'être un bon citoyen de dépôt/problème, mais ce problème est-il plus nécessaire ? Je veux dire, ce référentiel enregistre déjà plus de 50 problèmes qui entrent dans WAYYYYY plus en détail que ce problème ne le peut jamais. On dirait qu'il a déjà une vie propre !

Y a-t-il une raison de garder ce problème ici ouvert ? À moins que je ne comprenne totalement quelque chose (tout à fait possible), je pense que nous avons atteint l'objectif ici avec le standard Xaml. C'est axé sur la communauté et tout ce qui est le plus important pour moi, personnellement. :)

@Mike-EEE Il y a une différence subtile entre les deux problèmes ; l'un me semble concerner la standardisation des API disponibles dans XAML lui-même (strictement dans le XAML lui-même), et l'autre concerne la prise en charge de XAML en tant que composant .NET Standard similaire à System.Xaml.

@lokitoth est définitivement ouvert à la conversation à ce sujet, car j'essaie toujours de comprendre toutes les nouvelles pièces. Je suppose qu'il est préférable de commencer par suggérer de regarder l' excellente vidéo informative de @terrajobst qui montre que le code "fonctionne juste" avec le nouveau .NET Standard2.0. Personnellement, je n'ai pas compris comment cela affecte System.Xaml. Ma pensée était que cela devrait "juste fonctionner" mais peut-être que je commence à penser que je me trompe maintenant (trop beau pour être vrai).

Et pour être honnête, après avoir lu quelques-uns de ces fils de discussion dans le repo Xaml Standard, je me suis en quelque sorte blâmé pour ma suggestion précédente (☕️ le café m'a fait le faire, je le jure ! ☕️). À première vue, "Xaml Standard" est mieux nommé "MSFT UX/UI Standard" car c'est ce qui est principalement discuté dans ce référentiel. Dans l'état actuel des choses, Xaml en tant que technologie de sérialisation puissante n'est pas du tout présenté/présenté/mis en évidence (en dehors des quelques voix courageuses ici qui ont fait des efforts là-bas), ce qui entraîne également une certaine déconnexion/confusion.

Personnellement, je n'ai pas compris comment cela affecte System.Xaml.

Nous aurions besoin d'inspecter l'assembly pour déterminer si son arbre de dépendance est chargeable dans un contexte .NET Standard 2.0. S'il s'agit de .NET pur, cela fonctionnera probablement (bien qu'il existe tout un ensemble d'éléments au moment de la compilation, par exemple BAML, Embedded Resources, etc., qui devraient être intégrés à la chaîne d'outils de .NET Core)

À première vue, "Xaml Standard" est mieux nommé "MSFT UX/UI Standard" car c'est ce qui est principalement discuté dans ce référentiel.

Je pense que cela dépend davantage de son annonce dans le contexte de UWP/Xamarin.Forms, ce qui signifie que les développeurs qui se concentrent sur ces deux plates-formes - qui n'ont peut-être pas été exposés à "BigXaml" - sont ceux qui y contribuent principalement. Bien que vous voyiez quelques problèmes "apporter tout le dialecte WPF XAML" ouverts.

Étant donné qu'il y a beaucoup de nettoyage à faire pour l'équipe et qu'actuellement, le taux de nouveaux problèmes est assez élevé par rapport au nombre de personnes qui y contribuent, je lui donnerais plus de temps pour voir où l'équipe le prend.

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
J'ai créé un problème dans Xaml Standard.
https://github.com/Microsoft/xaml-standard/issues/57

Merci pour l'avertissement et la contribution à la conversation, @juepiezhongren !

bien @lokitoth Je suis content que nous ayons gardé ce problème intact car il a été décidé que https://github.com/Microsoft/xaml-standard/issues/23 n'était pas adapté à la lumière du jour.

J'ai cependant créé un nouveau problème qui, à mon avis, décrit mieux le problème en question et ce serait génial d'avoir votre vote positif et/ou vos contributions ajoutées ici : https://github.com/Microsoft/xaml-standard /problèmes/145

Pour clarifier, ce que vous recherchez serait en fait des artefacts générés par _JavaScript_+HTML5+CSS3. TypeScript est en fait un transpileur pour JS. Au lieu de créer un transpileur .NET pour produire un JS conforme aux normes qui s'exécuterait efficacement dans un navigateur (comme JSIL ), MSFT a décidé de consacrer le temps précieux du créateur de C # à créer quelque chose qui le concurrencerait efficacement et finalement.

Je dirais ne me lancez pas là-dessus, mais je ne pense pas m'être jamais arrêté. 😛

De plus, un autre point est que CSHTML5 est très proche de ce que vous recherchez @weitzhandler , mais il ne permet pas le partage de code entre les assemblages client/serveur (comme les PCL, etc.). Ainsi, vous vous retrouvez toujours avec deux bases de code distinctes et incompatibles à maintenir, ce qui entraîne le même problème de coût/activité entre .NET et JS (ou TypeScript 😉) qui, par exemple, n'existe pas dans une solution strictement NodeJS.

Mon rêve est d'utiliser le style d'écritures Android xml ui pour les applications de bureau avec le noyau dot net! Oui vraiment!!

Tout effort pour porter XAML vers le noyau .NET, je suis prêt à me porter volontaire.

Dans mes modifications apportées à CoreWf (WorkflowFoundation sur le net standard 2.0), je vois que System.Xaml ou une implémentation Portable.Xaml plus compatible sera probablement nécessaire pour permettre le chargement de DynamicActivity à partir de Xaml . CoreWf s'exécute sur le framework .net avec un chargement DynamicActivity de base à l'aide de System.Xaml, mais échoue toujours en raison d'un état d'analyse non valide sur le noyau .net avec Portable.Xaml.

Une question est de savoir pourquoi le code de System.Xaml n'est-il pas ajouté au référentiel de source de référence sous licence Mit ? Y a-t-il un problème de licence, de brevet ou autre ? S'il n'y a pas de problème, l'ajout de ce code à la source de référence nous permettrait, à nous la communauté, de faire le portage nécessaire pour prendre en charge CoreWf. Le référentiel source de référence n'engage pas Microsoft à prendre en charge System.Xaml. Dois-je y ajouter un problème demandant l'ouverture de System.Xaml?

Si System.Xaml n'est pas ouvert, pouvons-nous avoir un document (autre que la spécification Xaml) ou un support sous la forme de tests qui décrivent les étapes correctes pour analyser et tokeniser le code Xaml pour WorkflowFoundation ?

Hey FWIW @karelz J'ai mis quelques réflexions sur le scénario DevOps ici :
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Basé sur quelques événements intéressants dans Visual Studio Xaml Designer :
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

J'ai pensé que je le mentionnerais ici, pendant que j'y étais. 👍 D'ailleurs, ce fil est en retard pour une bosse. 😆

@weitzhandler vous devez être mis à jour, car mono-wasm est en voie alpha, il est presque temps de commencer à oublier js.

@weitzhandler 2 ou 3 ans r requis, mais ce n'est pas seulement une pile complète, c'est une pile universelle pour .net.

CoreRT est également à bord - https://github.com/dotnet/corert/pull/4480 . En espérant un combo HTML+CSS+C# prêt pour la production l'année prochaine.

Le pack de compatibilité .net proposé inclut System.Xaml avec le statut peut-être et lié à ce problème.

Apparemment, ce problème a été lié pour le pack de compatibilité 2.1 ? Quelqu'un peut-il confirmer? Je vois qu'il a été étiqueté netfx-compat-pack, mais pas avec une version. Je vais prendre cela sur tout ce qui s'est produit jusqu'à présent, cependant. 😄

Je déteste décevoir, mais je pense que j'ai accidentellement marqué cela comme 2.1 lorsque je mettais à jour en masse les problèmes du pack comapt. J'ai déplacé vers Future pour refléter le statut peut-être dans la proposition.

@Mike-EEE il semble que xamarin.wasm arrive.
https://github.com/mono/mono/pull/5924#issuecomment -343551464

Merci pour la mise à jour messieurs. J'apprécie que tu penses à moi. :) @terrajobst c'est en effet décevant, mais j'apprécie que vous preniez le temps de vérifier et de mettre à jour. Je ne savais pas si vous étiez toujours abonné à ce fil ou non. 👼

Étant donné que nous prenons le temps de brancher sans vergogne des projets (et qu'il faudra un certain temps avant d'obtenir notre correctif Xaml officiel), je prendrai une seconde pour mentionner que j'ai passé l'année dernière à aider avec la v2 de ExtendedXmlSerializer , qui vient de sortir. Il propose une prise en charge expérimentale des extensions de balisage et des propriétés jointes (qui fonctionnent sur POCO, aucun DependencyObject requis), ainsi que la sérialisation paramétrée de style protobuf .

Si vous recherchez (ou ajoutez) une fonctionnalité Xaml-ish pendant que nous attendons l'arrivée de System.Xaml, n'hésitez pas à la vérifier, à fournir des commentaires ou (mieux encore) à soumettre un PR dans le dépôt. 👍

https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3-and-support-for-windows-desktop-applications/

@danmosemsft Workflow Foundation xaml sera-t-il pris en charge dans les projets SDK dans le cadre de l'initiative de bureau 3.0 ?

@lokki Je ne connais pas de plans. @terrajobst @karelz?

@danmosemsft
Pourquoi n'y a-t-il pas de problème indiquant "Fournir un framework d'interface utilisateur dans le cadre de .NET Core" ?

Ce problème ne parle pas spécifiquement de l'absence d'un cadre d'interface utilisateur, et il ne semble pas que les gens ici s'en rendent compte.
Voir ceci : https://github.com/Microsoft/xaml-standard/issues/232

@weitzhandler Ce problème a BEAUCOUP plus de sens pour moi maintenant. Merci pour la clarification.

Je peux voir que System.Xaml inclus dans la norme .NET est utile, en particulier aux côtés de la norme XAML.

si j'ai bien compris "l'initiative de bureau", vous devriez pouvoir utiliser les bibliothèques .NET que vous pouviez utiliser dans le passé, tant que vous ne ciblez que Windows (pas sûr que votre application puisse s'adapter dynamiquement à l'environnement qu'elle s'exécute, si l'application principale ne pourra pas le faire [par exemple, ne se lancera pas si elle ne trouve pas le système d'exploitation Windows], vous pourrez probablement le faire en créant plusieurs assemblages .NET Core qui appellent les éléments spécifiques à la plate-forme et chargez-les à la demande en fonction de la plate-forme sur laquelle l'application détecte qu'elle s'exécute)

@birbilis pas assez. Le même XAML doit s'afficher de la même manière sur toutes les plates-formes.

L'initiative de bureau ne concerne pas XAML, il s'agit de .NET Core n'étant pas un silo de dénominateur le moins commun, mais permettant plutôt des applications qui peuvent cibler des plates-formes spécifiques (ou idéalement aussi s'adapter dynamiquement à la plate-forme sur laquelle elles s'exécutent) et rendre le utilisez-les au mieux, effectuez des intégrations spécifiques à la plate-forme, etc. Des API d'abstraction/compatibilité peuvent également être construites sur cette base, en se connectant à différentes implémentations pour chaque plate-forme que les auteurs d'une API souhaitent prendre en charge.

Pour l'instant, je pense que Portable.Xaml est si proche de System.Xaml maintenant. Si vous rencontrez un problème, merci de nous faire part de vos commentaires.

L'équipe WPF (@dotnet/wpf-developers) vient d' annoncer l'open-sourcing de WPF pour .NET Core 3.0. Dans ce cadre, les versions d'aperçu pour .NET Core 3.0 contiennent désormais System.Xaml, et les sources correspondantes sont disponibles sur https://www.github.com/dotnet/wpf.

d'ailleurs