Runtime: System.Xaml auf .NET Core portieren

HORRA! Offizielle Anerkennung/Anerkennung! Und ja, mir ist klar, dass diese Worte NICHT mit „Engagement“ gleichzusetzen sind, aber das ist definitiv besser als alles, was ich bisher gesehen habe. @terrajobst du bist mein Held. :herz: :herz: :herz:

@cwensley und @SuperJMN , es wäre großartig, hier einen Dialog zwischen allen zu bekommen. Im Idealfall (aus meiner Sicht) sollte jeder letztendlich einen Port/eine Version der neuen Xaml-Bibliothek verwenden und nicht verschiedene Versionen/Dialekte von Xaml da draußen haben. Ist das auch nur annähernd möglich? Ich bin damit einverstanden, wenn nicht, aber ich würde gerne sehen, ob wir es können, wenn ja. :)

Außerdem befinde ich mich derzeit in einem "Arbeits-Sabbatical (von herrischen Kunden LOL)" und ich habe 3-4 Monate geplant, um allein Xaml plattformübergreifend zu machen. Ich könnte buchstäblich Vollzeit arbeiten und während dieser Zeit bei Bedarf aushelfen. Alles für die Sache (und außerdem bin ich ein Opportunist für gutes Timing!)

Wenn System.Xaml Open Source wurde, bin ich sicher, dass die Community es gemäß den Anforderungen und Designzielen dieses Projekts auf .net Core portieren kann, müssen die Projektbetreuer nur die Community anleiten. Nutzen wir die Kraft der .net-Community.

@Michael-DST, ich stimme zu, dass es wichtig ist, einen xaml-Dialekt zu haben. Die Umsetzung könnte jedoch völlig anders sein. Die Standardisierung auf eine einzelne Implementierung hängt wirklich von der Community ab.

Für Portable.Xaml , eine PCL 259/136-Portierung von Monos hervorragender System.Xaml-Implementierung (MIT-lizenziert), mit vielen Bugfixes. Die Idee ist, alles zu unterstützen, was System.Xaml von MS tut (einschließlich Lesen/Schreiben), indem dieselbe API verwendet wird, aber nicht unbedingt darauf beschränkt ist.

Als Beispiel für erweiterte Funktionalität unterstützt Portable.Xaml die Verwendung von Typkonvertern für Elemente in einer Liste, wobei System.Xaml IList.Add(object) verwendet, das Sie mithilfe einer benutzerdefinierten Sammlung implementieren müssten, um verschiedene Typen zu unterstützen.

@cwensley Ich behaupte meine Unwissenheit darüber ... aber was ist der Unterschied zwischen .NET Core und PCL? Ich dachte die wären gleich? Das heißt, ich habe verstanden, dass, wenn Sie unter einem bestimmten PCL-Profil entwerfen, es auf .NET Core übertragen würde ... das ist eine Weile her (und ehrlich gesagt habe ich auf .NET Core auf RTM/W gewartet). also ist jetzt ein guter zeitpunkt für eine auffrischung. :P

Nach meinem Verständnis/Eindruck ist Portable.Xaml tatsächlich eine Portierung von Monos System.Xaml, während OmniXaml von Grund auf neu geschrieben wurde und einige neue Schärfe in der Parsing-Arena bietet. Im Idealfall (aus meiner Sicht) wäre es großartig, die beiden irgendwie zusammenzuführen, aber ich bin mir nicht einmal sicher, ob dies zwischen den beiden Basen machbar oder sogar wünschenswert ist. Meiner Meinung nach (ohne die Höhlenforschung/Analyse zu machen) ist es im Grunde die Verschmelzung der Reife des einen (Portable.Xaml) mit der neuen Schärfe des anderen (OmniXaml).

@Michael-DST PCL 259 ist laut diesem Beitrag tatsächlich mit .NET Core kompatibel. Ich habe \lib\dotnet bereits als Ziel in das nuget-Paket für Portable.Xaml aufgenommen, daher _sollte_ es so wie es ist für .NET Core verwendbar sein, obwohl ich es nicht getestet habe.

Ich hatte noch keine Zeit, mich mit OmniXaml zu befassen, aber wenn es sich tatsächlich um eine Neufassung von Grund auf handelt, macht es möglicherweise keinen Sinn, die beiden Projekte zusammenzuführen, da ich mir sicher bin, dass die Dinge völlig anders gemacht worden wären. Ich bin mir auch nicht sicher, welchen Nutzen so etwas hat, wenn Portable.Xaml größtenteils so vollständig ist, wie es ist. Ich könnte mich aber irren (;

:) Ja, ich erkunde hier Optionen und beschäftige mich auch mit meiner Unwissenheit, wirklich in einer Open-Source-Welt zu sein. Ich hasse die Idee, mehrere Codebases zu haben, die dasselbe tun. Und besonders da die Xaml-Community kleiner ist, wäre es scheiße, wenn sie gleich von Anfang an fragmentiert wäre (sollte das nicht passieren, _nachdem_ etwas zu erfolgreich für sich selbst wird?! haha). Wie auch immer, es wäre großartig, die Meinung von @SuperJMN dazu zu hören. Ich weiß, dass er bei seinen neuen Modifikationen ziemlich entschlossen zu sein schien. Beispielsweise die Verwendung von MarkupExtensionContext anstelle von IServiceProvider für Markup-Erweiterungen, was eine bahnbrechende Änderung für jeden wäre, der vorhandenen Code in diese neue Welt portieren möchte.

Zur Verdeutlichung: Alle PCL-Profile sind mit .NET Core kompatibel. Die Vertragssets und Factorings, die wir jetzt haben, sind eine Weiterentwicklung der PCL-Profile. Dies gilt nicht für portable Bibliotheken im „alten Stil“ (kompiliert gegen mscorlib usw.), die nicht sofort mit .NET Core kompatibel sind.

@Michael-DST

@terrajobst du bist mein Held. :herz: :herz: :herz:

Obwohl ich Ihren Enthusiasmus sehr schätze, möchte ich klarstellen, dass jeder solche Anfragen stellen kann. Sie brauchen kein Sponsoring oder Bestätigung von uns, um Probleme zu melden und um Arbeit zu bitten :-) Ich habe es nur selbst eingereicht, um etwas Zeit zu sparen und nicht super lahm zu sein ("fühlen Sie sich frei, einen Fehler zu melden") :-)

LOL @terrajobst es ist OK, meine Begeisterung ist halb augenzwinkernd und halb ernst ... MSFT hat zu diesem Thema seit fast einem Jahr im Grunde geschwiegen, trotz zahlreicher Abstimmungen und ausführlicher Gespräche .

Betrachten Sie also, was Sie getan haben, als ob Sie eine Mahlzeit unter die Tür von jemandem geschoben hätten, der fast ein Jahr lang in Einzelhaft gesperrt war. :stuck_out_tongue:

[Bearbeiten: Nachdem ich diese Analogie gelesen habe (und sie unten zitiert sehe), muss ich sagen, dass sie schrecklich ist und wahrscheinlich von einem Artikel beeinflusst wurde, den ich damals las – verdammt, Sie Nachrichten, warum müssen Sie mich so beeinflussen?! Ein besserer/relevanterer würde wahrscheinlich eine dringend benötigte Geldspritze von einer Engelsrunde bekommen, nachdem er ein Jahr lang mit Dämpfen gelaufen ist.]

cc: @Harikm86 , der Besitzer von System.Xaml

Ich liebe XAML. Es ist eine großartige deklarative Sprache für alles, von Silverlight (ja, ich habe es gesagt) über Windows Workflow bis hin zur neuen universellen App-Plattform. Durch die Portierung auf Core wird es möglich, andere Technologien zu portieren, die von XAML abhängen. Wir brauchen das!

Schön, deine Unterstützung zu hören @rschiefer! Danke für deinen Beitrag. Bitte stellen Sie sicher, dass Sie andere Xaml-Entwickler haben, die Sie kennen, um diesem Thread beizutreten und bei der Konversation/Leitung zu helfen.

Ich bin auch ein Fan von Silverlight und jage seit 2011 nach seiner nächsten Inkarnation (schamloser Einwand: Wenn Sie das Visual Studio-Team wissen lassen möchten, dass Sie die nächste, intelligentere Form von Silverlight sehen möchten, stimmen Sie bitte ab und lassen Sie es sie wissen hier ).

Ich möchte mir eine Sekunde Zeit nehmen und sicherstellen, dass wir, wenn wir „Xaml“ sagen, nach dem Xaml-System/Feature-Set streben sollten, das in .NET 4.x+ (oder „System.Xaml“) zu finden ist. Sogar das Xaml von Silverlight 5 reicht wirklich aus.

(Natürlich ist es auch erwünscht, die neuen Verbesserungen in OmniXaml hinzuzufügen .)

Solange es nicht die "neue", bastardisierte Version in UWP ist, die von einem Team von Praktikanten portiert worden sein muss, da wir alle seitdem darunter leiden (siehe die Stimmen, die ich in meinem obigen Beitrag erwähnt habe).

Ich zögere wirklich sogar, das ein "Xaml"-System zu nennen, da es wirklich XML mit etwas zusätzlichem Token-Parsing für viel Glück ist (was es eindeutig braucht). Fun Fact: Das Xaml-System von UWP verwendet während seines Build-Prozesses letztendlich die System.Xaml-Assembly. Mmm... #Ironie.

Sobald dieser Port eingerichtet ist, wird das UWP-XAML-System im Idealfall insgesamt veraltet sein und stattdessen dieses verwenden. Dann können wir dieses Kapitel der peinlichen Xaml-Geschichte hinter uns lassen, und viele Entwickler werden sich freuen.

Es wäre auch nicht schlecht, Silverlight in einer neueren, besseren Form zurückzubekommen. :) :) :)

@Michael-DST

Betrachten Sie also, was Sie getan haben, als ob Sie eine Mahlzeit unter die Tür von jemandem geschoben hätten, der fast ein Jahr lang in Einzelhaft gesperrt war. :stuck_out_tongue:

Alles klar :smile:

@Michael-DST

Ich habe UWP bis zu diesem Punkt tatsächlich vermieden, da ich wusste, dass sich viel geändert hatte, und ich hatte vergessen, dass UWP eine eigene „Version“ von Xaml verwendet. Danke, dass du mich erinnert hast.

Ich stimme vollkommen zu, System.Xaml sollte portiert werden und dann können wir UWP reparieren, um echtes Xaml zu verwenden.

Ich stimme vollkommen zu, System.Xaml sollte portiert werden und dann können wir UWP reparieren, um echtes Xaml zu verwenden.

Sorry @terrajobst , ich habe jetzt einen neuen Helden in @rschiefer. :Lächeln lächeln lächeln:

Vielen Dank für die Diskussion. Das ist super cool für mich (aber ich könnte einfach beeindruckt sein!).

@Michael-DST @rschiefer

@helmsb JA! LOL haha!

FWIW, die beliebte Material Design-Technologie von Google für Web (Angular.js), Apps (Android) usw., ist ebenfalls als Open Source verfügbar. Ich hoffe, dieses Argument hilft, die Bosse und Boss-ähnlichen Wesen zu überzeugen.

@dsaf was meinst du?

FWIW Ich habe auf dieses Problem in einem heute veröffentlichten Artikel mit dem Titel Is the Tide Turning on project.json verwiesen? , ein Blick darauf, inwiefern Xaml ein bevorzugter Mechanismus zum Beschreiben von .NET-Objekten sowohl aus technischer als auch aus MSFT-Geschäfts-/IP-Perspektive ist.

Nun, wie wäre es mit diesem Xamarin-Deal, huh! irgendetwas sagt mir, dass diese Ausgabe in den kommenden Monaten viel geschäftiger werden wird. :Lächeln:

Nicht unbedingt. Es besteht eine gute Chance, dass Xaml von UWP oder Xamarin von Xamarin zu einer plattformübergreifenden Bibliothek wird. Was bedeuten könnte, dass weder eine Portierung von System.Xaml noch eine rein verwaltete Xaml-Implementierung stattfinden darf.

Das Xaml-System von Xamarin ist jedoch geschlossen/intern und bei weitem nicht so ausgereift wie System.Xaml. Der Code selbst ist ziemlich schwach (ein anerkanntes Anliegen auf ihrer Seite - die tatsächliche Verwendung ist einer der Gründe, warum er geschlossen / intern ist). Darüber hinaus ist es eng mit BindingObject verbunden, was unzulässig ist, wenn Sie eine POCO-Serialisierung usw. durchführen möchten.

Und wie oben beschrieben, ist das Xaml-System von UWP schrecklich. Es sei denn, Sie wissen etwas, was ich nicht weiß. :stuck_out_tongue:

Können Sie erklären, was Sie mit "rein verwalteter XAML-Implementierung" meinen? FWIW, meine Erwartung hier ist nicht gerade eine direkte 1:1-Portierung von System.Xaml, sondern eine "neue" System.Xaml (Microsoft.Xaml?)-Bibliothek, die alle Vorteile von System.Xaml, Xamarin.Core.Xaml, und ... na ja, ich würde sagen UWPs Xaml, aber ... :wink:

Ich habe gehört, dass intern das Xaml von UWP gegenüber dem Xaml von WPF bevorzugt wird, obwohl offensichtlich verschiedene Teams bei Microsoft unterschiedliche Meinungen haben können. Xaml von DotNet ist ohne Zweifel leistungsfähiger und flexibler, aber wie bei allem mit diesen Deskriptoren hat dies wahrscheinlich Nachteile, die der Grund dafür sind, dass UWP so zurückgefahren wird.
Und mit nicht rein verwaltet beziehe ich mich auf die eine nette Sache an Xaml von UWP, da es nicht DotNet-exklusiv ist. Ein potenzielles zukünftiges Microsoft.Xaml könnte also eine plattformübergreifende native Implementierung mit einer verwalteten Fassade sein, sodass es außerhalb von DotNet verwendet werden könnte. (Das würde auch die Aufnahme in dotnet/corefx ausschließen, es sei denn, diese zukünftige Bibliothek wurde als Komponente von CoreFX ausgeliefert.)

Okay, ich bin verwirrt. Wenn Sie .NET sagen, sprechen Sie von 4.6, richtig? Nach meinem Verständnis ist dies für eine .NET Core XAML-Bibliothek, die von Natur aus plattformübergreifend und exklusiv für .NET (4.6) ist? Wenn Sie "nicht DotNet exklusiv" sagen, meinen Sie "ist DotNet inklusive"? Doppelnegativ. :stuck_out_tongue: Dies ist offensichtlich nicht wahr, da Sie UWP Xaml in .NET 4.6 nicht verwenden können (noch möchten Sie :stuck_out_tongue:).

Bitte klärt mich auf, was ich hier falsch mache. Außerdem wäre hier ein gutes Ziel, Xaml als Teil von CoreFX auszuliefern. Einige Diskussionen gibt es schon seit einiger Zeit . -- und sicher genug, wenn ich mich nicht irre, @RichiCoder1 , hast du deine Stimme, um genau das in diesem Thread zu tun ... Ich habe mich gefragt, wo ich dein Tag schon einmal gesehen habe! :Lächeln:

Und ich möchte auch sagen, dass ich auch die internen Neigungen zu UWPs Xaml gehört habe, aber das war, bevor es eine Community-Diskussion darüber gab, die in diesem Thread darüber hinaus begann ( ala Tim Heuers Twitter-Diskussion ). Die Nadel hat sich seitdem definitiv bewegt. Zumindest war es besser! LOL. Es gibt diejenigen mit der falschen Vorstellung, dass „Xaml für die Benutzeroberfläche ist“, und dann gibt es den Rest von uns, der versteht, wie es funktioniert. :stuck_out_tongue:

Wenn ich DotNet sage, meine ich DotNet inklusive Core und Framework. Und mir ist klar, dass Sie UWP Xaml nicht außerhalb von UWP-Apps verwenden können. Ich bezog mich auf die Möglichkeit, es in C++ UWP-Apps zu verwenden. Wenn ich also sage, dass es nicht DotNet-exklusiv sein soll, meine ich damit, es von C++ (oder möglicherweise anderen Sprachen) aus zu verwenden. Und ich kann mir vorstellen, dass das Team, dem XAML gehört, Anwendungsfälle außerhalb der Benutzeroberfläche nicht ernsthaft in Betracht zieht, weil sie entweder ungewöhnlich sind oder in einigen Fällen aktiv von Microsoft oder Partnern geschmäht werden. Nicht meine persönliche Meinung, ich schätze seine Ausdruckskraft und Kraft.

OK toll @RichiCoder1 danke für deine Erklärung. Ich glaube, ich kann dir jetzt _fast_ voll und ganz folgen... wenn du "Framework" sagst, meinst du 4.6?

Meiner Meinung nach wird ich sagen, dass ein Teil des Grundes, warum das interne Team der Ansicht ist, dass es ungewöhnlich ist, es außerhalb der Benutzeroberfläche zu verwenden, mit der schlechten Zusammenarbeit mit den Entwicklern zu tun hat, wie ich denke, dass Tims Beitrag zeigt. Ich bin auch dessen schuldig, da ich bis vor ungefähr einem Jahr nicht wirklich munter darüber wurde, MSFT zu engagieren? Tatsächlich handelte es sich bei Tims Tweet um eine Abstimmung, die ich gemacht hatte, nachdem ich mich persönlich/privat seit Windows 8.0 bei allen darüber beschwert hatte, dass das Xaml-System völlig anders und nicht so war, wie es sein sollte. Als ich Gerüchte hörte, dass UWP (Windows 10) Xaml im Grunde dasselbe sei – nach 3 Jahren ohne Innovation oder Verbesserung – da stieg ich ein. Im Nachhinein hätte es viel früher sein müssen.

Man kann mit Sicherheit sagen, dass dies eine wichtige Lektion war. Ich bin (oder fühle mich zumindest so) jetzt viel mehr in das Ökosystem integriert und fühle mich gehört. Tatsächlich wurde eine _sehr wichtige_ Abstimmung , die ich vor etwas mehr als vier Monaten abgegeben habe, Anfang dieser Woche vom renommierten Visual Studio-Team als „Under Review“ markiert. Zu sagen, dass meine Welt erschüttert wurde, ist eine Untertreibung. :Lächeln:

Per Framework verwende ich es, um auf Desktop .Net zu verweisen. Das scheint die beliebte Art zu sein, zwischen Core und dem Full Framework zu unterscheiden.

Ich stimme zu. Eines der schönen Dinge an all den jüngsten Schritten von Microsoft ist, dass es fast eine bessere Zusammenarbeit mit Entwicklern erzwingt :).

Darüber freue ich mich selbst sehr! Jetzt nur um zu sehen, wie sich das spielen würde. Das könnte alles bedeuten, von der Erstellung der Xamarin-Tools abgesehen von UWP-Apps mit ihren gemeinsamen Projekten, oder es könnte sogar etwas Höheres bedeuten. Nur die Zeit (und ich denke, //Build) wird es zeigen.

OK cool ... danke für die Info. :+1:

Wie für //build ... in der Tat. :) Persönlich würde ich gerne ein ganz neues Modell sehen, das (locker?) auf UWP basiert und die neue Xamarin-Güte nutzen, um es auf iOS/Droid zu verschieben. Ein stärkeres Xaml-Modell würde auch nicht schaden. Ich schätze, wir sollten diesen Thread doch bis nach dem 28. April ruhig halten. :stuck_out_tongue:

Ich hoffe ihr schafft das! :)

Vermutlich würden die UWP-Leute leichter eine XAML-Implementierung übernehmen, die keinen .NET-Code einfügt (selbst wenn dieser Code .NET Core-Zeug wäre).

Wie eine eigenständige Blackbox (oder nur abhängig von UWP, aber das wollen wir nicht, da UWP [noch] nicht plattformübergreifend ist und wenn es so wäre, würde man immer noch eine verwaltete Version davon vermissen, die in .NET/ Silverlight [kann Ihre Apps nicht nur auf das Win10-Ziel sperren]).

Aber das ist mehr oder weniger utopisch, denke ich, es sei denn, Sie machen es mit einer Abstraktionsschicht und Pluggables / Treibern für die verschiedenen Anwendungen von XAML (für UWP UI, für Workflow, für WPF/.NET, für Silverlight usw.). Wie DirectX scheint eine Maschine über HAL (Hardware Abstraction Layer) zu sein, was auch die Möglichkeit für HEL (Hardware Emulation Layer) eröffnet - siehe Erwähnungen unter http://www.developer.com/net/asp/article.php/968461/What -is-DirectX.htm). Natürlich, wenn Sie nicht aufpassen, könnte es auch die Tür zur Hölle in Bezug auf die Leistung öffnen, aber da DirectX es ziehen könnte, denke ich, dass eine solche Architektur nicht schlecht ist

+1 für die Portierung von System.Xaml auf .NET Core.
Ich hoffe, dass in Zukunft ein einziger einheitlicher XAML-Dialekt (.NET Xaml, UWP Xaml, Xamarin Xaml) auf allen Plattformen verwendet wird.
Es wird davon ausgegangen, dass eine .NET Core-Version von System.Xaml erforderlich ist, um dies zu erreichen.

+1

Um Massenbenachrichtigungen zu vermeiden, haben wir jetzt eine neue Möglichkeit, den einzelnen Kommentaren auf GitHub +1 zu geben, um unser Interesse / unsere Reaktion für das jeweilige Thema zu zeigen:

Haha @jasonwilliams200OK Ich für meinen Teil habe nichts gegen Massenbenachrichtigungen von Community-Mitgliedern, die ihr rudimentäres Interesse an einer leistungsstarken, plattformübergreifenden System.Xaml-Lösung zum Ausdruck bringen. :angel: Vielleicht würde ich bei anderen Themen deinen Schmerz/Ärger/Frust aber teilen. :zwinkern:

Gültige (und wertvolle) Punkte auf jeden Fall. Ich habe mein :+1: für die Sache hinzugefügt.

@jasonwilliams200OK

Danke für diesen Aufruf!

FWIW, ich habe gerade das Xamarin.Forms-Team eingeladen, hier an der Unterhaltung teilzunehmen:
https://bugzilla.xamarin.com/show_bug.cgi?id=26740

Oder wenn überhaupt, machen Sie alle _hier_ auf das Gespräch _dort_ aufmerksam. :Lächeln:

In den Kommentaren zu diesem Beitrag gab es eine tolle Diskussion:
https://blogs.msdn.microsoft.com/dotnet/2016/05/06/net-core-rc2-improvements-schedule-and-roadmap/

Im Grunde JSON vs. Xaml für das neue Projektsystem, das anscheinend für Visual Studio im Gange ist (Hurra!). Fühlen Sie sich frei, mitzumachen. :) So froh zu sehen, dass dies einen weiteren Blick bekommt.

@Mike-EEE, schau dir auch diese Roadmap an: https://github.com/dotnet/roslyn-project-system/blob/master/docs/Roadmap.md. Das neue Roslyn-basierte Projektsystem wird ... wertvoll sein.

whoa... verrückt, dass ich das erst jetzt höre. Dies muss das sein, worauf sich Scott Hunter in dem oben genannten Blog-Beitrag in Bezug auf weitere Informationen bezogen hat, die in einem zukünftigen Beitrag erscheinen werden. Gut zu sehen. Roslyns Macht wächst. Ich würde mich jedoch wohler fühlen, wenn ich einige Probleme für Xaml-serialisierte Projektdefinitionen sehe. :zwinkern:

Siehe die Readme-Datei dieses Repos: https://github.com/dotnet/roslyn-project-system#welcome -to-the-roslyn-c-and-visual-basic-project-system (und den Link zum VS MSDN-Blog ), scheint es, als könnten wir verschiedene Komponenten mit MEF ersetzen, wodurch es möglich wäre, einen zusätzlichen Serialisierer einzufügen, um die in XAML geschriebene Projektdefinition zu analysieren. Persönlich bevorzuge ich JSON gegenüber XAML/XML, wenn es darum geht, die Projekteigenschaften und Abhängigkeiten usw. zu beschreiben, da JSON weniger laut ist (na ja, YAML ist weniger laut als JSON und der lang-Standard unterstützt Kommentare im Gegensatz zu std-JSON, aber in der Dotnet-Welt müssen YAML und andere Sprachen mit einrückungsfähiger Syntax noch Fuß fassen)

Ich persönlich bevorzuge mittlerweile JSON gegenüber XAML/XML

SICHERHEIT! ENTFERNE DIESEN MANN!!! Ähm, ich meine... :)

Ich bin dafür, das Beste aus beiden Welten zu nehmen. @SuperJMN und @Grokys sprechen vielleicht mehr dazu, aber ich glaube, dass in OmniXaml Anstrengungen unternommen werden, um es weniger ausführlich und geschwätzig zu machen.

Mein Problem mit JSON ist nicht mit JSON an sich, sondern sein Designansatz, der auch die Grundlage der .NET-Konfiguration war (was meiner Meinung nach seine Inspiration war), und das heißt, das Schema des Objekts ist "noch ein weiteres Artefakt". der Entwickler muss die Klassendefinition verwalten/pflegen und _nicht_. Das heißt, in der Xaml-Programmierung (wie Sie wissen!) ist die Klassendefinition das Dokumentschema. Infolgedessen verleiht dies der Entwicklung des Dokuments ein sehr natürliches Gefühl und hilft/unterstützt auch bei der Werkzeugerstellung.

Ganz zu schweigen von der Vernunft der Entwickler. :smile: Nichts macht mich mehr wütend, als irgendein obskures Schemadokument zu jagen und herauszufinden, wie man es installiert und den einfachsten Intellisense zum Laufen bringt.

Das andere Problem, das ich mit JSON habe, ist wiederum nicht JSON-spezifisch, sondern mehr von der Web-Denkweise und das ist die Namenskonvention. Darunter litt auch die .NET-Konfiguration. Das heißt, Sie definieren möglicherweise ein POCO wie:

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

Und seine JSON (oder app.config) würde ungefähr so ​​​​aussehen (und Sie können mich darin unterrichten, wenn ich das falsch mache!):

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

Auch hier ist Xaml zwischen der Klassendefinition und seinem serialisierten Gegenstück ausgerichtet, weshalb ich es bevorzuge.

Ich muss sagen, dass .NET Configuration das SCHLECHTESTE war, weil sein Design vier Artefakte für jede Konfigurationseinheit ergab:

1. Das Element in web/app.config
2. Die .xsd-Datei, die Sie irgendwie magisch mit der web/app.config verknüpfen mussten (ich habe das nie zum Laufen gebracht!)
3. Die ConfigurationElement - und/oder ConfigurationSection -Elemente, die die Werte aus app/web.config übernommen haben (und den inkonsistenten camelCase auf PascalCase abgebildet haben – oh, der Wahnsinn!)
4. Das POCO, das letztendlich vom Konfigurationselement verkabelt wurde. (WÜTEND!)

Ich habe das Projektdesign von JSON nicht ausreichend studiert, um zu wissen, ob es ein POCO-Objekt gibt, das mit dem .JSON-Dokument serialisiert wird, oder ob die oben beschriebene irrelevante Zuordnung ebenfalls auftritt. Ich würde gerne hören, ob Sie die Antwort darauf wissen.

In jedem Fall verbessert Xaml dieses Design, indem es nur zwei Artefakte benötigt:

1. Die Klassendatei (.cs)
2. Die Datendatei (.xaml)

Abschließend danke für den Link zur Readme! Ich bin wieder einmal "der Typ", der nicht genau das tut, was die Datei verlangt. :Lachen:

wenn es ein POCO-Objekt gibt, das mit dem .JSON-Dokument serialisiert wird, oder wenn die oben beschriebene irrelevante Zuordnung ebenfalls auftritt. Ich würde gerne hören, ob Sie die Antwort darauf wissen.

Ich denke, wenn Sie die Attribute [DataContract] und [DataMember] berücksichtigen, unterstützt das .NET-Framework (auf BCL-Ebene) JSON und andere Daten-Serailizer. Es gibt jedoch keine native/Lowlevel-JavaScript-Objektliterale <-> C# POCO-Übergangsunterstützung durch den Compiler als JSON zu JavaScript (und vielen anderen Sprachen) oder CSON zu CoffeeScript. Im Gegensatz zu XML mit all seinen XPATH XQUERY XSLT-Bindungen hat JSON jedoch das Konzept des Schemas, um die Daten zu validieren, und JSON.net unterstützt es wie ein Champion.

Sehen Sie sich für C#6 und höher diese Probleme/Vorschläge an: https://github.com/dotnet/roslyn/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+author%3Agafter+ dictionary , insbesondere https://github.com/dotnet/roslyn/issues/6949 , und folgen Sie den darin enthaltenen Links. Mit der neuen C#6-Wörterbuchinitialisierungssyntax und diesen Vorschlägen scheint C# semantisch JSON-freundlicher zu werden.

Ich muss sagen, dass die .NET-Konfiguration das SCHLECHTESTE war

Stimmen Sie zu, Sie können auch das vom ASP.NET-Team eingeführte „Configuration“- und „IOption“-Muster als Plug-and-Play-Paket genießen: https://github.com/aspnet/Configuration , https://docs.asp.net/ en/latest/fundamentals/configuration.html , das den alten berüchtigten XML-gebundenen Konfigurationsmanager ersetzt.

JSON hat das Konzept des Schemas, um die Daten zu validieren, und JSON.net unterstützt es wie ein Champion.

Klingt nach einer Klassendefinition als Schema. :) :) :)

es scheint, als würde C# semantisch JSON-freundlicher werden.

Haha, um sicher zu sein, _jedes_ Objekt ist bereits JSON-freundlich. JSON eignet sich hervorragend, um das zu tun, wofür es vorgesehen ist: Objektdefinitionen auf prägnante, für Menschen lesbare Weise zu notieren. Und es besteht kein Zweifel, dass JSON.net dieses Ziel hervorragend erfüllt. Wenn Sie damit beginnen, _Anwendungen_ zu beschreiben, kommen wir in den Bereich, in dem diese Konversation anfängt, sich zu verwickeln, ähm, in Ermangelung eines besseren Wortes. :Lächeln:

Letztendlich gibt es hier (zumindest für mich) zwei Szenarien: die Beschreibung von Objekten, die zwischen Dienstgrenzen übertragen werden sollen (leichtgewichtig) und die Beschreibung der Anwendungen, die diese Objekte erstellen (bedeutend). Ich persönlich strebe gerne auf jede erdenkliche Weise nach Konsistenz und minimiere Kontextwechsel. Solange wir unsere Optionen ( IOptions ? :lachen:) offen halten und Entwicklern erlauben, das Format zu wählen, das für sie am sinnvollsten ist (und ihnen erlauben, die Tools zu verwenden, die ihnen das Gefühl geben, am effizientesten zu sein! ) dann gewinnen wir alle hier. :+1:

UWP XAML hat im Vergleich zum klassischen .NET WPF XAML weniger Funktionen. Eines der Features, die ich am meisten vermisse, sind TypeConverters.

Ich habe versucht, meinen eigenen TypeConverter zu erstellen, wie hier vorgeschlagen https://msdn.microsoft.com/en-us/library/bb546926 (v=vs.90).aspx (der Artikel ist für WPF TypeConverters)

In UWP bekomme ich mit diesem „Unknown type ‚car‘ in XML namespace ‚ using:App2TypeConverters ‘“

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

Ist es wirklich nicht möglich, einen benutzerdefinierten TypeConverter in UWP hinzuzufügen? Oder gibt es Abhilfe? Ich habe irgendwo gelesen, dass der XamlCompiler den internen IServiceProvider verwendet, um den TypeConverter zu registrieren. Vielleicht lässt es sich damit irgendwie registrieren?
Ich bin auch daran interessiert, mehr über den Hintergrund der XAML-Kompilierung zu erfahren. Wird XAML weiterhin in BAML generiert? Können wir uns irgendwie in die XAML-Kompilierung einklinken?
Öffnen Sie also bitte System.Xaml.

Sooooooo... bedeutet das, dass System.Xaml endlich mitfeiern wird??? :Lächeln lächeln lächeln:
https://blogs.msdn.microsoft.com/dotnet/2016/05/27/making-it-easier-to-port-to-net-core/

Ich melde mich hier und sage:
a) Ich würde es wirklich lieben, wenn XAML mit .Net Core läuft und
b) Wenn das passiert, wäre es am sinnvollsten, den UWP-Flavor zu verwenden, da er bereits auf andere Architekturen portiert wird (z. B. der IoT-Push auf dem Raspberry Pi).

Es wäre jedoch erstaunlich, WPF XAML zu erhalten, wenn dies möglich ist.

So wie der .NET-Core im Wesentlichen von Grund auf neu aufgebaut wurde, basierend auf dem Lernen der letzten zehn Jahre, sollte meiner Meinung nach das Gleiche für XAML getan werden. Die Evolution WPF/Silverlight/WinRt-XAML war ein komplettes Debakel. Ein Schritt vorwärts, zwei zurück (einer seitwärts). Das Versprechen von XAML, Expression Blend usw. hat sich nie erfüllt.

Ich hörte, wie Scott Hunter neulich keine plattformübergreifende Benutzeroberfläche in Dotnet Core rechtfertigte, indem er sagte: „Nun, sie werden nie gut. Unter Windows erwarten Benutzer eine Windows-ähnliche Schaltfläche, auf Mac eine Mac-Schaltfläche“. Nun, es tut mir leid - wo war er die letzten 5 Jahre??? Das Web dominiert das UI-Design jetzt vollständig und im Web gibt es keine "Standardschaltfläche" - aber wissen Sie was? Benutzer haben es geschafft, es auszuarbeiten. Dieses Argument widerspricht einfach allen Beweisen. Diese Web-UIs dominieren jetzt den Handel auf dem Planeten. Aber anscheinend ist das nicht gut genug für Dotnet Core. Warum können wir kein plattformübergreifendes XAML haben, ohne einem [imaginären] Streben nach „Standard-Plattform-Look & Feel“ nachzugeben?

Die wichtigsten technischen Hindernisse, die ich annehme, wären die Schnittstelle von "XAML" (oder wie auch immer die UI-Plattform der nächsten Generation heißt) mit einer plattformübergreifenden 3D-API - da wir offensichtlich keine Abhängigkeit von Direct3D/Direct2D auf MacOS usw. eingehen können. Aber ich nehme an Dieses Problem wurde von Unity usw. gelöst, die es schaffen, dieses Ziel zu erreichen.

Microsoft hat beim Thema Open-Sourcing der XAML-Familie von Technologien so viel Fuß geschleppt, dass man sich fragen muss, ob darin ein geheimer Cache mit Bitcoins oder den privaten Schlüsseln von microsoft.com verborgen ist.

Machen Sie weiter mit MSFT : Open Source WPF/Silverlight/WinRT-XAML und lassen Sie die nächste goldene Ära von UX beginnen.

Es ist ziemlich erstaunlich zu hören, was Sie über Scott Hunter sagen, @JackUkleja. Hast du dazu eine Quelle/Link? Wenn das, was Sie sagen, wahr ist, dann zeigt dies zusätzlich zu dem, was Sie sagen, (überraschende) Unwissenheit an mehreren Fronten:

1. Genau das hat Xamarin.Forms versucht anzugehen.
2. Plattformspezifische (oder sozusagen nachgeahmte) UX/Interaktionen/Stile sind ein Anliegen, das von Themes angegangen werden kann und sollte. Darin war WPF sehr gut (obwohl es Ihrer Meinung nach verbessert werden könnte und sollte).
3. Am schlimmsten ist, dass dies kein Vertrauen in den Talentpool setzt, der erfolgreich WPF geschaffen hat, das wohl größte Präsentations-Framework aller Zeiten. Wollen Sie damit sagen, dass sie dieses Problem nicht mehr lösen können? Oder zumindest plattformübergreifend dieselbe Magie wirken lassen, die WPF so erfolgreich gemacht hat?

Gute UX ist gute UX. Wie Sie betonen, zeigt das Web dies deutlich. Benutzer nativer Anwendungen sind definitiv auf ein bestimmtes Aussehen und Verhalten ihrer nativen Schnittstellen konditioniert, aber auch dies sollte von einem Thema aus lösbar sein.

Stellen Sie sich vor, Sie könnten eine Anwendung auf einem iOS-Gerät in einem Droid-„Skin“ (komplett mit Verhalten) anzeigen und umgekehrt. Dies war/ist mit WPF möglich und ist genau die Denkweise, die in die Zukunft getragen werden sollte. Das heißt, Look/Feel/Erfahrung sollten der Entwicklung und Gestaltung der Anwendung nicht im Wege stehen. Sie sollten in der Lage sein, ein Thema anzuwenden, und whalah, "es funktioniert einfach". Dies war/ist leider ein Nachteil für Xamarin.Forms, da es zwar verschiedene Plattformen berücksichtigt, aber viel Reibung damit verbunden ist, sicherzustellen, dass auf jeder Zielplattform alles wie erwartet funktioniert.

@Mike-EEE Ich bin mir ziemlich sicher, dass Scott Hunter in dieser Folge von dotnet rocks ähnliche Worte gesagt hat: https://www.dotnetrocks.com/?show=1291

Betreff:

„Der Talentpool, der WPF erfolgreich geschaffen hat, das wohl größte Präsentations-Framework aller Zeiten“

...meines Wissens nach hat eine große Anzahl der ursprünglichen Architekten , einige von denen, die an WPF beteiligt waren, MSFT verlassen und zu Google gewechselt und sich an Angular beteiligt. Viele Ideen von WPF tauchen in Angular und verwandten Frameworks wie Templating auf. Aber egal, wie Sie diese Web-Frameworks aufteilen, ich denke, Sie werden immer den Geruch von HTML/CSS im Hintergrund haben. Nicht alle UIs sind dokument-/semantikbasiert sinnvoll, und das liegt in der Natur von HTML, weshalb ich denke, dass die Welt immer noch den "XAML-Kern" verwenden könnte.

[Jack ... glaube nicht, dass die Daten zu Google und WPF-Architekten korrekt sind]

@rrelyea Das war mein Verständnis, aber ich kann mich irren. Ich hätte schwören können, dass ich gelesen habe, dass einige Mitglieder des WPF-Teams an Angular gearbeitet haben ... Ian Ellison-Taylor unter anderen? (Obwohl es scheint, dass er jetzt wieder bei MSFT ist ...)

Geruch von HTML/CSS im Hintergrund

Je mehr Konformität und Konvergenz in Richtung einheitlicher HTML-CSS-Standards oder jeglicher Art von Standards in dieser Hinsicht (C, C++, JavaScript), desto besser wäre diese Welt. Stattdessen kann sich XAML mit seiner einzigartigen Funktion als übergeordnetes Framework für HTML+CSS-Stack usw. oder einfach als alternative Front-End-Engine für Razor von ASPNET rendern: https://github.com/aspnet/Razor/issues/78 : Birne:

@jasonwilliams200OK FWIW/FYI, es gibt bereits einen HTML/CSS-"Standard"-Port von .NET in JSIL . Die gesamte Ausgabe ist zu 100 % HTML5-konform und läuft in jedem modernen Browser. Dies ist natürlich die Denkweise, die wir anstreben sollten (und die seit dem Ende von Silverlight im Jahr 2011 die Denkweise gewesen sein sollte, aber ich schweife ab).

Das heißt (zu Ihrem Punkt hoffe ich), dass .NET-Entwickler sich nur mit .NET/C#/F#/VB.NET befassen und niemals CSS/HTML/JS berühren müssen, so wie es ist Xamarin .NET-Entwickler müssen sich nicht mit den Grundlagen von iOS/Droid befassen (was auch immer _sie_ sind. :wink: ).

@Mike-EEE, in Superset-Sprachen (TypeScript zu JavaScript oder Less zu CSS) können wir den Subset-Lang-Code in Superset in derselben Datei verwenden, aber nicht umgekehrt. Das Konzept von Superset geht also etwas darüber hinaus, wie Phonegap, Cordova usw. funktionieren. :)

Haha ja @jasonwilliams200OK Ich möchte nur sicherstellen, dass wir unseren Ansatz/unsere Strategie nicht zu einem Sonderfall machen, indem wir .NET wieder in den Browser bringen. Das Berühren von CSS/JS sollte mit der gleichen Verachtung betrachtet werden wie das Berühren von Binärdateien. :stuck_out_tongue:

Als Beispiel gibt es auch ein anderes Projekt Fayde , das Xaml verwendet (yay), aber auch auf TypeScript angewiesen ist (boo). Dies ist der Weg, es NICHT zu tun, da Sie letztendlich mit zwei inkompatiblen Codebasen enden – eine in TypeScript/JS für den Clientcode, .NET für alles andere – was sowohl Zeit als auch Ressourcen kostet.

alternative Front-End-Engine zu Razor von ASPNET

Razor ist meiner Meinung nach nur eine Template-Engine. Tatsächlich heißt es unter dem von Ihnen erwähnten Link "... dass Sie aus einer langen Liste von Front-End-Templating-Engines auswählen können, gegen die Sie codieren können."

Ich hatte sogar einige Kommentare von MS gegen spezielle C#-ähnliche Syntaxen wie Razor innerhalb der HTML-Seite zugunsten von Frameworks gehört, die stattdessen benutzerdefinierte Tags verwenden

Übrigens gibt es auch Bridge.net (http://bridge.net) und andere C#-zu-Javascript-Compiler, die mit XAML-Lösungen wie Fayde kombiniert werden könnten

Bezüglich XAML auf HTML5/JS/etc. Es gibt ein interessantes Projekt Granular , das WPF neu implementiert. Es verwendet Saltarelle zum Kompilieren in JS. Ein Live-Beispiel ist hier .

Dieses Granular ist ziemlich fantastisch, @ethanhs. Das war mir nicht bewusst. Da es den gleichen Ansatz CSHTML5 , JSIL, Bridge.net (das @birbilis erwähnt) verwendet hat, leidet es unter dem gleichen Problem, dass es nicht möglich ist, Code zwischen Server und Client durch die Verwendung von PCLs zu teilen, was wirklich das einzig Mögliche ist Weise, dies in diesen Tagen zu tun.

Und so großartig dieses Projekt auch aussieht, es fasst ziemlich genau die Höllenlandschaft zusammen, die .NET-Entwickler seit dem Niedergang von Silverlight ertragen mussten. Es und etwa ein Dutzend andere erledigen "etwas" die Aufgabe, .NET im Browser zum Laufen zu bringen, aber nicht ganz die gesamte Erfahrung, die diejenigen mit Silverlight-Erfahrung erwarten.

Es muss noch eine einzelne, einsame, vereinheitlichende Lösung geben, die Entwickler dazu bringt, Silverlight zu vergessen. Wir kommen uns aber näher. Ich hoffe zumindest. WebAssembly scheint vielversprechend zu sein, aber ich habe seit einiger Zeit keine signifikanten Entwicklungen mehr gesehen/gehört. Die JSIL-gesteuerte Portierung/Initiative scheint sich etwas verlangsamt zu haben und hatte seit letztem Oktober keinen Check-in mehr.

Hoffentlich haben wir hier in naher Zukunft einen Durchbruch. Ich würde gerne eine Ankündigung sehen, die auf der //Build im nächsten Jahr als solche angegeben wird. :herz: :+1:

Das wäre eines der besten Dinge, die XAML in den letzten Jahren passiert ist.
Stimmen Sie hier ab !

Cool @bbougot. Es gibt auch noch eine weitere Stimme, die _endlich_ etwas Aufmerksamkeit bekommen hat, nach fast 15 Monaten des Bestehens, nicht mitgerechnet für die fast 3 Jahre, in denen ein schreckliches Xaml-System nicht erkannt wurde (aber ich schweife ab!):
https://wpdev.uservoice.com/forums/110705-dev-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

(Im Ernst, 15 Monate, um überhaupt eine Abstimmung für das offensichtlichste aller Probleme zu erkennen? Was macht das UWP-Team da drüben??? Wann wird das Visual Studio- oder .NET-Team das Ruder übernehmen und das Schiff in Ordnung bringen??? .. oops, das stimmt, ich war abgeschweift ...)

Vergiss auch nicht, diesen Thread upzuvoten. Es läuft derzeit bei 60 ziemlich gut, besonders wenn man bedenkt, dass dieses Problem begann, bevor wir so ausgefallene Annehmlichkeiten wie GitHub Reactions hatten. :Lächeln:

Xaml ist das einzige mit dem Potenzial, das gesamte Client-Ökosystem zu vereinheitlichen!
Bitte werdet DirectX los, bitte umarmt OpenGL!
UWP soll auf PC, Telefon, Website laufen!
Viva Xaml!

Also, zivile Frage hier @terrajobst , @harikmenon und @karelz (wie ich sehe, hast du kürzlich ein Tag hinzugefügt, also herzlichen Glückwunsch, ich ziehe dich hinein!). Aus reiner Neugier habe ich beschlossen, ein wenig abenteuerlustig zu werden und mir die fortgeschrittene (oder vielleicht auch nicht) GitHub-Filterung in diesem Repo anzusehen. Ich denke, dass es viele Stimmen gab und was nicht für verschiedene Themen.

Hier ist die URL, die ich verwende:
https://github.com/dotnet/corefx/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Es scheint, als ob dieses Problem derzeit 82 Upvotes hat, und wenn ich richtig liege, ist das nächstnächste Element in der Liste bei 17. Das macht dieses Problem bei weitem zum am häufigsten nachgefragten / für das Thema in diesem Repo, richtig?

Wenn ja, würde mich interessieren, ob dies einen Einfluss auf Ihre Prioritäten und/oder Planung hat. Offensichtlich scheint dies jetzt eine _sehr_ beliebte Frage/ein Gegenstand zu sein (wiederum, wenn ich das richtig verstehe), also denke ich, dass es vielleicht nett wäre, vielleicht ein Update oder einen Check-in zu hören, um möglicherweise ein Gespräch über Fortschritte zu beginnen dieses Problem eine Möglichkeit.

Es wäre großartig, hier eine Perspektive / einen Kontext zu erhalten und / oder wenn ich in Bezug auf die Kundennachfrage etwas völlig missverstanden habe. Es passiert. 😄

Unsere .NET Core-Ingenieure konzentrieren sich stark auf .NET Standard 2.0 (ebenfalls hohe Kundennachfrage) – siehe Details hier und hier . Wir werden uns andere Bibliotheken ansehen, die nicht in dieser Liste enthalten sind, nachdem wir .NET Core auf den neuesten Standard gebracht haben.

Danke für den Hinweis auf die Upvotes-Abfrage!

Danke für deine Antwort @karelz! Sehr geschätzt. 👍

👼 👼 👼 Ich werde das gleich hier lassen, falls jemand liken/retweeten möchte. 👼 👼 👼
https://twitter.com/MikeEEE76/status/776769805722521600

Ich arbeite seit der Version 3 von .net mit xaml, ich habe die Verkleinerung von Silverlight und sogar seinen Tod gespürt. Ich bin jemand, der Veränderungen liebt, um Dinge besser und nützlicher zu machen. Aber jetzt mit dem UWP finde ich einen Rückschritt statt einen Fortschritt. Kümmern Sie sich nicht um all die neuen Funktionen, die sich großartig anfühlen, aber an der fehlenden vollständigen XAML-Unterstützung wie bei der Desktop-App. Ich habe versucht, eine neue App in UWP zu erstellen, und ich habe auf die harte Tour gelernt, dass sich alles, was ich gelernt habe, erneut geändert hat. Ich kann online nicht viel Unterstützung finden, da die xaml-Bibliothek dorthin verschoben wurde. Zum Beispiel ist der Adorner, der unter dem Framework war, nicht mehr da, das x:static für die Eigenschaften, die nicht funktionieren, man muss stundenlang suchen, um ein Beispiel zu finden oder was zu tun ist. Es gibt keinen Link, um die Form des alten xaml zum neuen UWP anzuzeigen ...

@giworking Es ist offensichtlich, dass MS auf die Client-Entwicklung achten sollte! Wie Satya Nadella zitiert wird, ist Azule der Kern und die Zukunft von MS. Die stärkste Energie, um Azule anzukurbeln, ist das gesamte .net-Ökosystem. Im Vergleich zu Java ist die Client-Seite fast die einzige Waffe, um Programmierer und Unternehmen davon zu überzeugen, die Cloud von MS anzunehmen (in China befindet sich .net wirklich in einem katastrophalen Zustand, die Leute sprechen über Java und reagieren: „Was ist f k s t xamarin?“. ....). Wenn ich also als chinesischer Programmierer xamarin , uwp, typescript und cshtml5 sehe, weiß ich, dass es möglich ist, die gesamte Clientseite im xaml+C#-Modus zu vereinen, aber warum sehen unsere MS-Freunde nicht die Gelegenheit dazu zurück den chinesischen Marktanteil mit if?

Wow, diese Ausgabe hat jetzt über 100 Upvotes! Vielen Dank an alle, die ihre Unterstützung gezeigt haben. Wenn es jemanden interessiert, gibt es hier einen wirklich ( wirklich! ) großartigen Artikel von @terrajobst mit seinem enormen Engagement für Markenentwickler in den Kommentaren:
https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/

(Im Ernst, jeder MSFT-Mitarbeiter, der einen unternehmensbasierten Blog-Beitrag veröffentlicht, sollte Herrn Landwerths Anleitung folgen, wie man die unvermeidlichen, unzähligen und unzähligen Kommentare, die danach entstehen, postet und nachfasst. Er ist wirklich top mit allem, wie es scheint wie viel zu viele MSFT-Autoren lassen ihre Posts einfach austrocknen und lassen die Fragen tot, was natürlich eine schreckliche Art ist, Ihr Publikum zu behandeln!)

Wie auch immer, es lohnt sich auf jeden Fall, es zu lesen, wenn Sie es noch nicht getan haben, insbesondere die Kommentare. Dies bringt mich zu dem Grund, warum ich jetzt poste, da _ich mich sehr darüber freue, dass dieses Problem in den Kommentaren erwähnt wird, zusammen mit der Leidenschaft/dem Wunsch, System.Xaml in die .NET Standard-/plattformübergreifende Ära zu bringen_. 👍

154 Upvotes ... Tendenz steigend. 😎 Die nächsthöhere Ausgabe ist bei 25 , als Referenz. #Quietschendes Rad

Dies muss getan werden. Steigen Sie ein!

Wir haben eine @ReactWindows- Anwendung, die auf WPF abzielt und auf der wir .NET Native verwenden möchten, um das erstmalige Download-/Installationserlebnis für unsere Zehntausende von Windows 7-Benutzern erheblich zu verbessern. Wir haben auch Pläne für die Zukunft, React Native auf Linux zu bringen und möglicherweise @ReactWindows freigegebenen Code wiederzuverwenden, aber auf Xamarin.Forms abzuzielen.

Die Verfügbarkeit von System.Xaml (und anderen Typ-/Methoden-/Assembly-Abhängigkeiten von WindowsBase, PresentationCore und Xamarin.Forms) in NETCore vNext ist für diese Strategie von entscheidender Bedeutung. Wir können diesen Mangel umgehen, indem wir die vorhandenen Assemblys neu erstellen und neu ausrichten oder indem wir fehlende Typen/Methoden in System.Xaml von Mono ausfüllen und für .NET Core erstellen, aber wir würden es wirklich vorziehen, wenn Microsoft sich verstärkt und bereitstellt, was ist notwendig für die Plattform.. /cc @rozele @pre10der89

@matthargett Viel Glück dabei. Ich habe dieses Problem totgeschlagen, als ich daran dachte, den Workflow auf .net Core zu bringen. Er ging sogar so weit, sich an das xaml-Team zu wenden. Sie sind nicht einmal im Entferntesten daran interessiert, System.Xaml zu öffnen. Ich verstehe nicht warum - da ist bestimmt nichts Schützenswertes drin.

Möglicherweise wird dies nach der Veröffentlichung von 2.0 Ende April in Betracht gezogen.

Leute, noch einmal, wir brauchen System.XAML nicht, um WF nach netstandard1.x portiert zu machen ... Es gibt bereits eine gute Arbeit von @dmetzgar , in der der Kern von WF funktioniert. Das wichtigste fehlende Stück sind Transaktionen, von denen ich glaube, dass sie irgendwann in netstandard2.x zurückkommen werden.

Die wichtigste Richtlinie von @dmetzgar port ist, keine Art von Designsprache an den Kern gebunden zu haben und grundlegende Primitive zu haben, damit die Leute den Workflow nach Belieben serialisieren und später Designer darauf erstellen können.

Natürlich wird dieser Ansatz zu einer Nicht-Abwärtskompatibilität mit aktuellen XAML-basierten Workflows führen, aber glauben Sie mir, alles auf .Net Core zu verschieben, IST eine große bahnbrechende Änderung, also müssen die Leute das verstehen.

Es gibt OminiSharp, das für die XAML-Designer genutzt werden könnte, aber auch hier ist Design/Serialisierung etwas außerhalb des WF-Kerns. Es muss schlank sein wie alles andere bei .Net Core.

Ich würde sagen, dass dieses Problem laut und deutlich gemacht hat, dass die Leute WF auf .Net Core verschieben wollen, ich denke nur, dass es einfach nicht produktiv ist, sich beim System.XAML-Team über OSS zu beschweren. Das XAML-Team hat andere Prioritäten und es ist der Kern des Windows/UWP/Xamarin-Geschäfts, also erwarten Sie nicht, dass es so bald OSSed wird. Stattdessen würde ich @dmetzgar bitten, das WF-Repo unter der .Net Foundation offiziell zu veröffentlichen und die Community anzuleiten, es zum Laufen zu bringen, ohne einen Zeitplan oder Versprechungen für die Veröffentlichung von netstandard2.x festzulegen. Es wäre eine fortlaufende Arbeit, die von seinem Team vorangetrieben und hauptsächlich von der Community unterstützt wird, die eindeutig helfen und es schaffen will.

Schauen Sie sich an, wie schnell sich die Dinge im Orleans-Projekt entwickeln ... Es war eine Microsoft-Forschung, die letztes Jahr OSSed wurde, und es ist eines der größten und aktivsten Repositorys auf der .Net Foundation und wird hauptsächlich von Community-Bemühungen angetrieben (es hat immer noch eine MSFT-Team, das Vollzeit darin arbeitet).

Wie auch immer, meiner Meinung nach, müssen wir aufhören zu quatschen und anfangen, etwas zu tun. Es ist klar, dass das @dmetzgar- Team keine Bandbreite hat, um daran zu arbeiten, da ihr Hauptanliegen darin besteht, Hauptbenutzer von WF zu unterstützen, bei denen es sich im Grunde um große Sharepoint-Bereitstellungen handelt, die überhaupt nicht vorhaben, zum .net-Kern zu gelangen. Es muss also eine von der Community betriebene (beaufsichtigt von @dmetzgars Team) Anstrengung sein.

Leute, noch einmal, wir brauchen System.XAML nicht, um WF auf netstandard1.x portiert zu machen ...

@galvesribeiro , das mag stimmen, aber dieses Problem besteht darin, System.Xaml auf .NET Core zu portieren, von dem es bei weitem das am häufigsten nachgefragte Feature in dem Repo ist, in dem das .NET-Team um Feedback bittet. Wenn Sie nicht auf Ihr Feedback hören, warum sollten Sie es dann einholen? Wie auch immer, WF ist einfach _eines_ der Szenarien, die eine System.Xaml-Portierung erfüllen würde. Wie Sie wissen (oder sollten!), kann System.Xaml noch viel mehr.

Das XAML-Team hat andere Prioritäten und es ist der Kern des Windows/UWP/Xamarin-Geschäfts, also erwarten Sie nicht, dass es so bald OSSed wird.

Ja, das ist sozusagen das Problem hier und das, was wir ändern wollen. :) Außerdem bin ich mir nicht einmal sicher, ob es heutzutage noch ein "Xaml-Team" gibt, oder?! Es fühlt sich wirklich an, als wäre diese Technologie geschlossen worden, und wir beginnen, sie in den Griff zu bekommen.

Wie auch immer, meiner Meinung nach, müssen wir aufhören zu quatschen und anfangen, etwas zu tun.

100% einverstanden. FWIW, @SuperJMN hat gerade OmniXamlv2.0 veröffentlicht, also sind einige Community-Bemühungen im Gange, die genutzt werden können, während MSFT ihre Energien und Bemühungen um dieses Problem priorisiert (die übrigens jetzt seit etwa 11 Monaten andauern – und zählen).

Apropos, hier ist ein netter Thread zu genau dem (d. h. der Inaktivität von MSFT in dieser Hinsicht), mit einem Zitat von @terrajobst :

Um es klar zu sagen, ich sage nicht, dass System.Xaml nicht plattformübergreifend sein kann oder sollte. Was ich sagen will, ist, dass System.Xaml außerhalb von WPF und WF nicht sehr nützlich ist und NuGet eine sinnvolle Proxy-Metrik für diese Aussage ist. Natürlich könnte System.Xaml außerhalb des UI-Bereichs sinnvoll gemacht werden, aber das ist ein zweiter Schritt. Ich würde lieber JETZT unsere Ressourcen nutzen, damit die grundlegenden Teile gut funktionieren und vollständig sind. Außerdem wird durch eine konvergente Basis auch das Portieren von Komponenten höherer Ebene, wie z. B. System.Xaml, viel einfacher.

Es ist also keine Entweder-Oder-Aussage; es ist eine Erklärung über die Reihenfolge der Hinrichtung.

Abgesehen von der sehr falschen Aussage, dass System.Xaml außerhalb von WPF/WF nicht nützlich ist, klingt das alles für mich nach Projektmanager-Glish, ohne die Absicht, jemals auf dieses Problem einzugehen. Ich möchte mit dieser Aussage nicht kritisch sein, da ich Immo und die großartige Arbeit, die er hier leistet, voll und ganz unterstütze. Ich war jedoch genug um den Block herum, um mir diese Art von Sprache zu erlauben, mir eine Pause zu gönnen und mich in eine abwartende (oder eher "glaube es, wenn ich es sehe" LOL!) Haltung in Bezug auf dieses Problem zu bringen.

In der Zwischenzeit unterstütze ich die aktuellen Bemühungen im .NET Standard 2.0 und bin gespannt, was das bringen wird. Vielleicht ist es besser als erwartet. Zumindest klingt es so, als könnten wir System.Xaml für .NET Core-Projekte zurückfordern, die auf Windows-Plattformen arbeiten, was für mich ein guter Anfang ist. 👍

@Mike-EEE zunächst tut es mir leid ... Ich dachte, ich hätte auf diese https://github.com/dotnet/corefx/issues/2394 geantwortet oO Diese beiden Probleme waren zu oft miteinander verbunden, als dass ich verwirrt war.

Zweitens sage ich keineswegs, dass XAML nur für die Benutzeroberfläche nützlich ist. Ich habe es so viele Jahre lang für TFS-Builds, WF selbst und in letzter Zeit für die Benutzeroberfläche verwendet. Es gibt eine Reihe von DSLs wie Azure ML und andere, die XAML nutzen könnten.

Was ich sagen wollte, ist, dass ich nicht sehe, dass XAML so bald auf .Net Core portiert wird. Wie Immo sagte, müssen sie es zuerst mit den aktuellen Plattformen richtig machen. .Net Core hat noch nicht einmal irgendwelche nativen Bildbearbeitungsbibliotheken.

Es gibt mehrere XAML-Implementierungen, die von WPF mit vollem Funktionsumfang bis hin zu schwachen und fehlenden Funktionen in UWP reichen. Es muss vereinheitlicht und stabilisiert werden, bevor so etwas OSS bekommt. Ich spreche nicht von den Teams, die darin arbeiten. Ich denke nur, dass ich mich nicht von ihnen unterscheiden würde, wenn ich meine Ressourcen priorisieren müsste.

Grüße an WF, nochmals Entschuldigung, aber mein vorheriger Kommentar zielte hauptsächlich auf diejenigen ab, die hofften, dass dieses Problem der Grund dafür ist, dass die WF-Portierung zum Kern nicht so schnell erfolgt, was nicht wahr ist .

Diese beiden Probleme wurden zu oft miteinander in Verbindung gebracht, dass ich verwirrt war.

Haha @galvesribeiro Ich kann dir nicht sagen (oder habe Angst zuzugeben), wie oft mich das auch gebissen hat. Keine Sorge. Ich für meinen Teil schätze den Input trotzdem!

FWIW, es sieht auch so aus, als ob @cwensley weiterhin gute Arbeit über @ Portable.Xaml leistet, nachdem er kürzlich Leistungsverbesserungen an seiner monobasierten Adaption von System.Xaml vorgenommen hat, die es schneller als die Originalversion machen. Es sieht fast so aus, als ob dies ein guter Ausgangspunkt für eine Anstrengung hier sein könnte, da es wahrscheinlich der ursprünglichen System.Xaml-Erfahrung aller Geschmacksrichtungen/Optionen am nächsten kommt. Nur meine koffeinbedingten zwei Cent für den Morgen.

Bitte portieren Sie System.Xaml nach .NetCore

FWIW, über 200 Stimmen für diese Ausgabe, jetzt bei 202. Die nächsthöhere Ausgabe ist dotnet/corefx#13526, die bei 47 sitzt. Nun, WAR 47 ... es ist jetzt 48 nach meiner Abstimmung. :) (Zeig ihm etwas Liebe, es ist eine gute Idee.) #squeakywheel

Danke für die Erinnerung @Mike-EEE ;-). Zur Erwartungshaltung: Wir sind noch nicht bereit, tief in die Materie einzudringen – ich persönlich hoffe, dass wir bis März in der Lage sein sollten, unsere nächsten offiziellen Schritte genauer zu kommentieren, auch wenn es wieder heißt: „Wir haben noch keine Pläne“ (Haftungsausschluss: Ich versuche, meine beste persönliche Vermutung mitzuteilen, bitte behandeln Sie es nicht als offizielles Teamversprechen!).

Als wir das Thema letztes Mal ein wenig besprochen haben, war die Schlüsselfrage, welche der über 200 Abstimmungen sich wirklich nur auf System.Xaml vs. WPF beziehen. Die Annahme ist, dass viele Leute nicht zwischen den beiden unterscheiden. Irgendein Vorschlag, wie man das am besten angeht? (z. B. Erstellen von 2 spezifischen Problemen und Bitten der Leute, für WPF vs. "reines Xaml, nicht WPF" zu stimmen)

Es wäre auch hilfreich, eine zusammenfassende Liste von Szenarien für System.Xaml mit einigen Prioritätseinschätzungen zu haben (sie sind jetzt über lange Diskussionen verstreut). @Mike-EEE könntest du uns bitte bei der Zusammenstellung helfen? (da Sie ein starkes Interesse und fundiertes Wissen auf dem Gebiet zu haben scheinen)

Definitiv System.Xaml ist das, was die Leute wollen @karelz. Wenn hier jemand an WPF denkt, ist das meiner Meinung nach nicht der richtige Ort. Es gibt eine Reihe anderer Frameworks, die XAML wie WF, TFS Build usw. nutzen, die immer noch System.Xaml verwenden, und das würde uns eine große Hilfe sein.

@karelz Ich schätze Ihre Antwort hier sehr. Vielen Dank, dass Sie sich die Zeit dafür genommen haben. Wie @galvesribeiro erwähnt, ist System.Xaml mehr als nur UI, was ein Schlüsselverständnis zu sein scheint, das von vielen MSFT leider übersehen wird. Es ist ein leistungsstarkes Serialisierungsparadigma, das jede andere Serialisierungslösung auf dem Markt übertrifft, insbesondere wenn es darum geht, Anwendungen zu beschreiben, was es am besten kann (immerhin das "A" in seinem Spitznamen). Leider wurde "Anwendung" mit "UI" vermengt und daher die Reibung hier.

Das Übersehen dieses Aspekts war ein Hauptfehler von UWP und ist einer der Gründe, warum niemand wirklich gerne damit arbeitet. Umgekehrt scheint Xamarin diesen Schlüsselaspekt in seinem Xaml-Geschmack verstanden zu haben, aber es ist intern und nicht als erstklassiges, autoritatives Angebot verfügbar (was ziemlich genau das ist, worauf es in diesem Problem hier ankommt).

TBH, @cwensleys Port von System.Xaml in Portable.Xaml scheint im Moment ein Spitzenreiter zu sein. Er hat nicht nur System.Xaml von Mono portiert (unter Beibehaltung seiner insgesamt vertrauten API), sondern auch neue Funktionen hinzugefügt und seine Leistung tatsächlich verbessert, sodass sie _besser_ als die von System.Xaml ist.

Meiner Ansicht nach könnte dieses Problem so einfach sein wie die Zusammenarbeit mit @cwensley , um das, was er in Gang gebracht hat, zur maßgeblichen plattformübergreifenden Xaml-Bibliothek zu machen, die in Zukunft verwendet werden kann.

Abgesehen davon wird es schwierig und könnte zu Ihrer (verständlicherweise) komplizierten Sicht auf dieses Problem beitragen. Da System.Xaml eine ausdrucksstarke und leistungsstarke Sprache zum Beschreiben von Anwendungen (wiederum nicht nur Benutzeroberflächen) bietet, verfügt es auch über einige großartige Tools, die in Visual Studio (und natürlich Blend) integriert sind. Im Idealfall wäre es großartig, dieselbe großartige Erfahrung fortzusetzen und die Designererfahrung von Xaml irgendwie plattformübergreifend beizubehalten, aber persönlich verlangt das nach einer Kirsche auf dem Kuchen der großartigen, über die wir hier sprechen. :)

Um es hier noch einmal zu wiederholen, war das Versprechen (und die Lieferung) von Xaml auch eine Verbesserung des Entwicklungsworkflows zwischen Designer und Entwickler. Ich denke gerne, dass wir letztendlich einen Schritt weiter gehen und den Prozess zwischen Entwicklung und _devops_ verbessern können. Das heißt, ich würde gerne eine Welt sehen, in der Devops in schön gestalteten Editoren für die Anwendungskonfiguration (powered by Xaml) arbeitet, um bereitgestellte Anwendungen zu verwalten und zu warten.

_Die ganze Idee hier ist die Reduzierung der Gesamtkosten in der Anwendungsentwicklung von der Codierung bis zur Bereitstellung. Die Zusammenarbeit mit hübschen Redakteuren und Designern ist (aus Ressourcensicht) billiger, als jemanden finden und einstellen zu müssen, der Code (und/oder Skripte) in die Hände bekommen muss, um Magie zu verwirklichen._

Ich teile dies mit Ihnen als Visionsperspektive, nur damit Sie sich dessen bewusst sind. Ich bin mir jedoch nicht sicher, wie interessiert Sie daran sind, dies zu hören. 😉 Also, wenn dies einfach ein "Was wäre nötig, um dieses Problem zu schließen und dich dazu zu bringen, wegzugehen?" Ich würde vorschlagen, die Möglichkeit einer Zusammenarbeit mit Mr. Wensley zu prüfen und zu sehen, ob wir seine großartige Arbeit bisher nutzen können (oder ob er überhaupt bereit ist, dies zu tun). Wenn es eine Möglichkeit gibt, dies so auszurichten, dass es das maßgebliche plattformübergreifende Xaml-Paket für die Veröffentlichung von .NET Core Wave 2 (etwa im Mai oder so?) sein kann, dann noch besser. :)

Danke für die Info, ich bin auf jeden Fall interessiert. Ich habe auch das Gefühl, dass meine vorherige(n) Frage(n) nicht so rübergekommen ist, wie ich es beabsichtigt hatte, also lassen Sie mich versuchen, auf einige Dinge hinzuweisen:

Ja, Details interessieren mich auf jeden Fall. Ich glaube nicht, dass jemand Xaml != WPF auf MSFT-Seite bestreitet. Das habe ich definitiv nicht versucht. Ich weiß nur, was ich nicht vollständig verstehe, und ich versuche, die Lücken zu füllen - dh die Motivation und Notwendigkeit der Szenarien von "pure Xaml" vollständig zu verstehen.
(Übrigens: Ich verstehe Ihr Devops-Szenario nicht ganz und wie Xaml das einzige/beste ist, um dort zu helfen? Oder wie wird es überhaupt in dem Szenario verwendet?)

Ich bin nicht hier, um zu versuchen, dieses Thema zu schließen. Bitte! Das ist mir gar nicht in den Sinn gekommen. Ich bin hier, um der Community zu helfen, die Frage zusammenzufassen, damit sie mit den richtigen Leuten diskutiert werden kann (denken Sie in diesem Fall an die Direktoren). Ja, ein Teil davon bedeutet, dass ich (und/oder ein paar andere MSFTs) die Bitte verstehen müssen, sie weiter oben zu vertreten - daher meine Fragen.

Ich gebe zu, ich bin ein gutes Beispiel für jemanden, der Xaml und WPF nicht unterschieden hat, bevor er dieses Problem sah. Aus zufälligen Chats mit anderen im .NET-Team wissen viele, dass Xaml != WPF ist, aber sie sehen nicht den "riesigen Wert", reines Xaml zu haben, das hier vorgeschlagen wird - daher meine obigen Fragen zu den Szenarien. Die Szenarien helfen mir/uns, die Motivation besser zu verstehen und die Geschichte besser zu erzählen/verkaufen. (Ich hoffe, es ist keine Überraschung, dass, wenn es keine klare Geschichte gibt, niemand darauf bedacht ist, sie zu finanzieren :) - die Geschichte ist eine Voraussetzung für die Finanzierung)
Lassen Sie uns also mit dem Elevator Pitch aufwarten, um ihn voranzubringen.

In Bezug auf die Arbeit von @cwensley ist es großartig zu hören, dass es einige nicht so teure Lösungen geben könnte. Aber auch hier wäre es wirklich hilfreich, zuerst den Hintergrund und das WARUM zu verstehen, bevor wir uns an die Lösung machen. Ich hoffe, es macht Sinn. (Ich versuche nicht, abweisend oder so zu sein – ich wiederhole nur, dass es einfacher ist, die Dinge voranzubringen, wenn das WARUM verstanden und vereinbart wird.)

@galvesribeiro Wenn jemand hier an WPF denkt, ist es meiner Meinung nach nicht der richtige Ort

Ich teile Ihre Zuversicht nicht, dass all die über 200 Personen, die abgestimmt haben, das Xaml != WPF für solche Details wirklich verstehen. Ich denke auch, dass sich zumindest ein paar es ansehen - ja, lass uns zuerst Xaml bekommen, dann wird es einfacher sein, nach WPF zu fragen. Ihr Szenario ist also die ganze Zeit WPF, während "reines Xaml" nur der erste Schritt in diese Richtung ist.
Und vielleicht irre ich mich (obwohl ich zumindest nicht die einzige Person im .NET-Team mit diesen Zweifeln bin) ...
Ein anderer Blickwinkel könnte darin bestehen, "reines Xaml" in eine Liste von Szenarien (WPF, Entwickler oben, vielleicht ein paar mehr?) aufzuteilen und dann die Leute zu bitten, für sie zu stimmen - Welche davon sind für diejenigen, die hier abgestimmt haben, wirklich wichtig? Was sie wirklich wollen?
(Dies ist keine Verzögerungstaktik oder irgendetwas Böses, ich versuche hier, den "Kunden" zu verstehen. Ich hoffe, das macht Sinn - wenn Sie bessere Vorschläge haben, wie Sie an solche Daten gelangen, sprechen Sie, ich bin offen für alternative Ansätze )

EDIT: Wie üblich, wenn Sie denken, dass ich das Problem nicht richtig angehe, sagen Sie es bitte. Ich versuche hier mein Bestes zu geben, um zu helfen - mit den besten Absichten. Ich leide nicht unter der Illusion, alles zu wissen oder zu denken, dass ich schlauer bin als alle anderen.

@karelz Es gibt eine Reihe von UI-Frameworks, die das Rad neu erfinden und ihre eigenen Auszeichnungssprachen schreiben, nur weil XAML nicht plattformübergreifend ist, auch wenn sie WPF überhaupt nicht mögen. Avalonia ist einer der besten. Sie verwenden Omnisharp, wenn sie stattdessen natives XAML nutzen könnten.

Workflow Foundation ist ein großer Benutzer/Kunde von XAML, und Leute im Port WF zu .Net Core- Thread fragen immer danach.

Also ja, ich stimme Ihnen zu, dass wir die Erwartungen festlegen oder einen rohen Funktionssatz zeichnen sollten, was von der plattformübergreifenden System.Xaml erwartet wird, zusammen mit den gewünschten Verwendungen wie zum Beispiel UI und WF.

@Karelz

Ich denke auch, dass sich zumindest ein paar es ansehen - ja, lass uns zuerst Xaml bekommen, dann wird es einfacher sein, nach WPF zu fragen. Ihr Szenario ist also die ganze Zeit WPF, während "reines Xaml" nur der erste Schritt in diese Richtung ist.
Und vielleicht irre ich mich (obwohl ich zumindest nicht die einzige Person im .NET-Team mit diesen Zweifeln bin) ...

Also... was ist das Problem daran? Eine WPF-ähnliche plattformübergreifende Lösung könnte eine ziemlich gute Sache sein. Xamarin kann keine plattformübergreifende Desktop-GUI ausführen.

@jnm2 es ist nicht schlecht - aber wenn dies das Hauptszenario (90% +) ist, sollten wir planen, beides zu tun. Xaml ohne WPF zu haben, wird in einem solchen Fall nicht helfen (zumindest nicht viel). Und es könnte (potenziell) ungültige Illusionen erzeugen, dass WPF festgeschrieben ist und kurz danach kommen wird.

WPF / GUI in .NET Core zu integrieren, wird ein großer Schritt für .NET Core sein, das jetzt hauptsächlich auf Serverszenarien und Konsolen-Apps abzielt.

@jnm2 mit System.Xaml würde Leuten (wie mir) massiv helfen, die _versuchen_, so etwas wie WPF auf andere Plattformen zu bringen (https://github.com/AvaloniaUI/Avalonia).

@grokys das klingt nach einem vernünftigen Szenario - kannst du das etwas näher erläutern? Wie groß wäre die Hilfe? Was ist herausfordernd ohne?

Ich verwende Xaml auch für mein (nicht WPF-ähnliches) plattformübergreifendes Desktop-UI-Framework Eto.Forms . Aus diesem Grund habe ich zunächst das Portable.Xaml- Projekt erstellt, und es hat bisher für mich und meine Benutzer gut funktioniert.

Ich bin nicht dagegen, dabei zu helfen, dies zur "autoritativen" plattformübergreifenden XAML-Implementierung zu machen (wie @Mike-EEE es ausdrückt). Denken Sie jedoch daran, dass ich nur in meiner Freizeit daran arbeite (;

@Karelz
Nicht nur UI-Frameworks, es kann in vielen Szenen wie XAML zu HTML verwendet werden

@Kation kannst du mehr Details teilen, was genau du meinst?

Übrigens: Ich habe angefangen, Szenarien im obersten Beitrag zusammenzufassen - wenn Ihr Szenario nicht dabei ist, beschreiben Sie es bitte, und sobald es verstanden ist, füge ich es dort hinzu.

@Karelz
Mit dem leistungsstarken XAML-Editor in Visual Studio können wir schnell benutzerdefinierte Komponenteninhalte erstellen.
Dann, denke ich, könnten wir XAML verwenden, um HTML-Inhalte in einem speziellen Szenario zu generieren, sogar noch mehr SVG-Inhalte.
Dies ist ein halbfertiges XAML-zu-XML-Framework für .Net 4.5. https://github.com/Kation/WebPresentation

Ich verstehe nicht, warum Sie HTML oder SVG aus XAML generieren möchten. Welchen Wert hat XAML hier?
Ist der Wert, dass es einen netten VS-Editor hat? Es gibt auch HTML-Editoren, warum diese nicht direkt verwenden?
Oder verfehle ich den Punkt ganz?

@Karelz
Weil ich in einigen Projekten Inhalte wie WPF mit Template und Style generieren möchte.

@karelz nochmals vielen Dank für den Dialog. Ich für meinen Teil weiß das sehr zu schätzen.

Ich leide nicht unter der Illusion, alles zu wissen oder zu denken, dass ich schlauer bin als alle anderen.

Oh, ich beneide. 😉

Ihr Szenario ist also die ganze Zeit WPF, während "reines Xaml" nur der erste Schritt in diese Richtung ist.

Ja, das ist wieder die Verschmelzung, die ich erwähnt habe. Xaml ist schlicht und einfach ein Serialisierungsparadigma. Sie können eine Anwendung -- und die darin enthaltenen Komponenten -- darin definieren und beschreiben. Hier ist zunächst ein Beispiel für eine in Xaml beschriebene _Konsolenanwendung_:
https://github.com/DevelopersWin/VoteReporter/blob/master/DevelopersWin.VoteReporter.Application/Program.xaml

Wie Sie sehen, gibt es in Xaml beschriebene Befehle, die Anweisungen dazu geben, was dem Benutzer durch die Verwendung von Konsoleneingaben und -ausgaben präsentiert werden soll. Dies hat nichts mit WPF oder "UI" zu tun (obwohl dies technisch gesehen die UI im Sinne der CLI als UI ist, aber hoffentlich können Sie den Unterschied erkennen). Außerdem können Sie sehen, dass ich direkt in der Datei Markup-Erweiterungen und statische Member-Deklarationen verwende. Dies ist etwas, das ich in JSON oder einem anderen Datenformat nicht gesehen habe. Das ist wirklich die Macht von Xaml, IMO.

Als weiteres Beispiel für ein „Pure Xaml“-Szenario ist hier eine Datei, die ich für ein neues formatunabhängiges MSBuild vorschlage:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Processor.xaml

(wenn Sie eine Ebene höher gehen, können Sie die anderen Formate sehen, die dasselbe tun, dies ist zufällig die Xaml-Version)

Dies ist die Prozessordatei, die wiederum aus einer Reihe von ( System.Windows.Input.ICommand ) Befehlen besteht, die die Schritte beschreiben, die in einem theoretischen Erstellungsprozess ausgeführt werden müssen. Auch hier kein WPF oder UI, aber Sie können sehen, dass es Nachrichten an die Konsole ausgibt.

Eine Funktion, auf die ich hier hinweisen möchte und die ich bereits erwähnt habe, sind die integrierten Tools in Visual Studio, die ich aus dieser Datei erhalte:

Ohne etwas zu tun oder ein externes Schema zu definieren, „leuchtet“ Visual Studio einfach auf und stellt Eigenschaftseditoren mit Dropdowns und anderen Designeroberflächen bereit, die auf dem Klassenschema der Datei basieren, mit der ich arbeite (dies wird hoffentlich das Entwicklungsszenario einfacher machen). verstehen).

Zusätzlich zur Prozessordatei ist hier das theoretische Projekt oder die Eingabedatei, die zum Senden an den Prozessor verwendet werden könnte:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/SampleFormats/Xaml/Project.xaml

Hier versuche ich, mit _Markup-Erweiterungen_ auf den Punkt zu kommen, die verwendet werden, um eine Version bereitzustellen (möglicherweise aus einer externen Datei) und auch eine Abfrage zu verwenden, um die zum Erstellen gesammelten Dateien bereitzustellen (beachten Sie, dass Sie dies möglicherweise nicht in einer endgültiges Build-System, aber ich wollte seine Möglichkeit demonstrieren).

Übrigens, dieser Beispielcode ist voll funktionsfähig, Sie sollten also in der Lage sein, die SLN aus diesem Repo abzurufen und die XAML-Version auszuführen, die Ergebnisse sollten in etwa so aussehen:

(Hinweis: Funktioniert auf My Machine , daher kann Ihr Kilometerstand variieren. 😄)

Übrigens: Ich verstehe Ihr Devops-Szenario nicht ganz und wie Xaml das einzige/beste ist, um dort zu helfen? Oder wie wird es in dem Szenario überhaupt verwendet?

Ja, ich habe überlegt, ob ich darauf eingehen soll, da ich das Gefühl hatte, dass mein Beitrag etwas lang wird. Hoffentlich kann die obige Komponente des visuellen Designers jetzt helfen, zu veranschaulichen, worauf ich hier hinaus will.

Bitte wissen und beachten Sie, dass dies für mich das ultimative Endspiel ist und warum ich so begeistert von all dem bin. _Der Grund dafür ist, dass es letztendlich die Gesamtbetriebskosten für eine Anwendung über ihre Lebensdauer reduziert._

Im Kern sprechen wir hier also von POCO-basierter Entwicklung, bei der die Bearbeitung und Gestaltung von POCOs erfolgt, die in einem Anwendungsprozess verwendet werden. Wie wir wissen, arbeitet ein Entwickler und Designer an einer Xaml-Datei, die POCO-Elemente beschreibt, die sich mit der UI-Domäne befassen (das hier ist das traditionelle „WPF“ von „Xaml“, wenn Sie so wollen).

In meiner Welt würde ich gerne sehen, dass dieser Prozess erweitert wird, sodass die Entwicklung XAML-Dateien für Devops bereitstellt, die verwendet werden können, um Anwendungen zu verwalten/zu warten, die in einer Live-Umgebung bereitgestellt wurden.

Sie können sich dies als Live-Konfigurationsdateien vorstellen. Wie sie geladen werden, muss ausgebügelt werden, aber das Endergebnis würde in etwa so aussehen, wie Sie es im obigen Screenshot in Visual Studio sehen. Anstatt dass der Endbenutzer (Devops) gezwungen ist, seine Hände in den Code zu stecken (oder vielmehr eine Organisation gezwungen ist, die dafür erforderlichen teuren Talente/Fähigkeiten einzustellen), arbeiten sie stattdessen mit eingeschränkten, validierten visuellen Bearbeitungssteuerungen, um zu konfigurieren und Anwendung beibehalten.

_Die Idee dabei ist, dass die Kosten für die Wartung einer Anwendung nach der Bereitstellung aufgrund des Aufwands (und der Fähigkeiten), der dafür erforderlich ist, anstatt Code zu kennen und zu verstehen, erheblich reduziert werden._

Ein Aspekt, den ich nicht erwähnt habe, ist, dass diese Steuerelemente tatsächlich anpassbar sind. Visual Studio verfügt über eine (wenn auch veraltete) umfangreiche API zum Definieren der visuellen Editoren, die diesen POCO-Eigenschaften zugeordnet sind:
https://msdn.microsoft.com/en-us/library/microsoft.windows.design.model.designmodevalueprovider(v=vs.90).aspx

All dies ist jetzt in Visual Studio ohne zusätzliche Arbeit, Overhead oder Aufwand verfügbar. Die ultimative Idee hier wäre also, eine Reihe leistungsstarker Editoren und Designer zu erstellen, die nicht nur den Entwicklungsprozess, sondern letztendlich den Entwicklungsprozess unterstützen.

Auch dies ist alles visionär und (noch) ohne reale Grundlage. Das ist natürlich nicht ganz meine Idee, sondern inspiriert von der Gruppe Patterns and Practices mit ihrem Windows Forms-basierten Configuration Editor . Ich habe diesen Trottel einfach einen Schritt weiter gebracht und sehe, wie ich das durch die Kraft von Xaml nutzen kann.

Bitte lassen Sie mich wissen, wenn Sie weitere Fragen zu diesem @karelz haben. Wieder schätze ich den Dialog. Es bietet nicht nur die Möglichkeit, sich auszutauschen, sondern auch, meine Ideen und Überzeugungen zu bestätigen. Und mit dem Gedanken, alles zu wissen (ja, ich bin schuldig 👼), versuche ich, den Dingen gegenüber aufgeschlossen zu bleiben und zu erkennen, dass ich nicht alle Antworten habe. Dies ist definitiv ein Prozess, bei dem ich ständig versuche, besser zu werden. Danke noch einmal!

@karelz – Avalonia verwendet derzeit OmniXaml als XAML-Engine, und obwohl dies recht gut funktioniert, gibt es immer noch Fehler und fehlende Funktionen. Wie Portable.Xaml wird OmniXaml von einem Freiwilligen gepflegt, der nicht immer viel Zeit hat, daran zu arbeiten.

Wenn Sie sich tatsächlich entscheiden, System.Xaml nicht zu öffnen, wäre die Veröffentlichung Ihrer Testsuite vielleicht ein guter Kompromiss – zumindest könnten wir so sicherstellen, dass die Implementierungen von Drittanbietern wie OmniXaml und Portable.Xaml so konform wie möglich sind.

Ich denke, was das .net-Ökosystem braucht, ist ein standardmäßiges, für Menschen lesbares Serialisierungsformat – so etwas wie JSON in der Javascript-Welt. Dieses Format sollte Donet-Datentypen verwenden und POCOs direkt als Schema verwenden. Dann kann dieses Format verwendet werden, um POCO-Objekte zu beschreiben. Diese Beschreibungen sind stark und statisch typisiert. Dies kann ein UI-Layout, eine Laufzeit-App-Konfiguration, eine Projekt-/Workflow-Beschreibung oder sogar die Kommunikation zwischen zwei .net-Programmen sein. Und sogar die Kommunikation mit anderen Ökosystemen (wie Web/Javascript) ist ebenfalls möglich, sofern sie das Format implementieren. Aber es sollte um das .net-Ökosystem herum entworfen werden. Deshalb reicht JSON/BOND/Protobuf/XML nicht aus.

In der Vergangenheit hat XAML die Verantwortung in gewisser Weise erfüllt. Nun stellt sich die Frage, wie gut es für diese Rolle ist. Wenn es gut genug ist, sollte XAML meiner Meinung nach in netstandard und dann in .net-Implementierungen umgewandelt werden. Aber auch andere Formate sollten nach Möglichkeit berücksichtigt werden. Ich glaube, letzte Woche kam http://www.ammyui.com/ heraus. Ein UI-Beschreibungsformat, das sich auf Einfachheit konzentriert, aber in XAML übersetzt wird. Weil XAML nicht einfach genug war. Ich selbst habe ein Format in roslyn repodotnet/roslyn#16648 basierend auf (Objekt-, Sammlungs- und Index-)Initialisierern vorgeschlagen. Und mein Vorschlag wurde tatsächlich aus diesem Blogbeitrag von @bricelam vom Entity-Framework-Team entnommen (und dann leicht modifiziert). Sowohl sein Beitrag als auch mein Vorschlagsthread enthalten einige Beispiele.

Mein Punkt ist, dass es ein Standardformat für .net geben sollte, sei es XAML oder etwas anderes.

@grokys Ich wollte OmniXaml erwähnen und habe @SuperJMN zu dem Gespräch hier eingeladen, aber es scheint, dass er nie teilnehmen möchte. Ich bin mir nicht sicher, ob es an den Einstellungen liegt oder woran (ich habe es auch im Gitter versucht -- da Sie mit ihm arbeiten, haben Sie vielleicht mehr Glück, ihn hierher zu ziehen 😄 ). OmniXaml ist natürlich auch zu diesem Gespräch herzlich willkommen.

@gulshan +💯 👏 👏! Ha ha. Ein Teil des verwirrenden Teils von all dem ist, dass Xaml ein MSFT-Format und eine MSFT-Technologie ist. Bei all den Investitionen und Werkzeugen, die darum herum aufgebaut wurden – sowohl bei MSFT als auch in Unternehmen, ist es in der Tat unverständlich, warum es eine Lücke zu geben scheint, um seine Kontinuität sicherzustellen, damit bestehende Bemühungen und Investitionen genutzt werden können.

Trotzdem gefällt mir, was ich bei Ammy sehe, und ich bin dem gegenüber weiterhin aufgeschlossen. Oder versuchen Sie, einen zu haben. 👼

Ich denke, es ist wichtig zu wiederholen, warum wir uns überhaupt mit Datendateien beschäftigen, der Hauptwert bei der Verwendung von Datenformaten ist:

• Imperativsprache Agnostiker . Die Verwendung der Dateien erfordert keine Kenntnis einer Programmiersprache.
• Designer-/werkzeugfreundlich. _Der Einsatz eines visuellen Designers und/oder die Ermöglichung eines visuellen Designererlebnisses mit Ihrem Produkt führt zu geringeren Gesamtbetriebskosten _.

Dabei ist mir persönlich wichtig:

• Integrierter Workflow für Entwickler/Designer
• Visuelle Designer-Erfahrung für die manuelle Bearbeitung von Dateien.
  
  
  
  • PropertyGrid (Eigenschaftenfenster) mit erweiterbarer Editor-API wie oben beschrieben.
  
  
• Markup-Erweiterungen
• Sahnehäubchen der Großartigkeit: Fähigkeit, alle oben genannten Elemente in Szenarien außerhalb der Entwicklung zu nutzen (Beispiel für Entwickler oben).

Wenn all dies erfüllt ist, wäre ich bereit, ein "anderes .NET-Format" in Betracht zu ziehen, aber natürlich würde ich es vorziehen, Xaml als dieses Format beizubehalten und zu erweitern. Es ist schließlich eine MSFT-Technologie und damit geistiges Eigentum.

@Mike-EEE Wenn ein Format zu einem POCO deserialisiert werden kann, sollten alle diese Funktionen funktionieren. Das Eigenschaftenfenster in VS wird auch für Nicht-XAML-Szenarien angezeigt. Aber eine Sache, die mich stört, ist die Lesbarkeit ohne Editorunterstützung. In einigen Fällen müssen Sie eine Konfigurationsdatei auf einem Remote-Server bearbeiten und haben nur vim. Im Vergleich zu JSON ist XML (und XAML) in dieser Hinsicht meiner Meinung nach nicht so toll.

Aber XAML hat einige einzigartige Dinge (eigentlich Nicht-XML-Features) wie angehängte Eigenschaften, die in einem einfachen Serialisierungsformat schwer zu imitieren sind.

Ich würde zuerst für WPF stimmen (damit ich mich endlich von xamarin.froms verabschieden kann), dann für xaml

Das Eigenschaftsfenster in VS wird auch für Nicht-XAML-Szenarien angezeigt

Richtig, aber es ist nicht annähernd "beleuchtet" wie bei Xaml, mit vollständig anpassbaren Bearbeitungssteuerelementen usw. Korrigieren Sie mich, wenn ich hier falsch liege. Sie können in diesen Formaten nicht einfach den Cursor auf eine Eigenschaft setzen und ein Dropdown-Render für ein Aufzählungsfeld (z. B.) haben. Diese Erfahrung ist im Grunde die nächste Form und Version von WinForms, was einer der Gründe dafür ist, dass es so schön ist (WinForms ist immer noch beliebt!).

Im Vergleich zu JSON ist XML (und XAML) in dieser Hinsicht meiner Meinung nach nicht so toll.

Ja, ich stimme zu, Xaml ist nicht gerade knapp, und Sie werden Beschwerden darüber hören, wie ausführlich es ist. Hier macht sich OmniXaml einen Namen, indem es Verbesserungen rund um die Formatierung bereitstellt. Sie konkurrieren auch mit anderen Formaten wie TOML und YAML und so weiter.

Nicht-XML-Features) wie angehängte Eigenschaften ...

Und Markup-Erweiterungen. 😄 Das sind Merkmale seiner Vision.

Was (glaube ich) Sie hier @gulshan schürfen , ist im Wesentlichen ein "Daten-AST (abstrakter Syntaxbaum)". Wenn wir über eine ernsthafte Verbesserung von Xaml (oder .NET-Datenformat) sprechen, dann ist dies der richtige Weg. Es könnte sogar von Roslyn angetrieben werden. Tatsächlich habe ich eine Benutzerstimme für genau diese Idee (zusammen mit einem entsprechenden Blog-Post ). Leider ist es nicht sehr beliebt, da es schwer zu erklären ist, haha. Im Wesentlichen haben Sie einen AST-Baum (Datenbaum), der in eine beliebige Anzahl von Formaten geschrieben werden kann. Auf diese Weise können Entwickler (und Tools) damit arbeiten, je nachdem, welches Format für sie am sinnvollsten ist (ästhetisch oder anderweitig).

damit kann ich mich endlich von xamarin.froms verabschieden

Da stimme ich dir zu @groege. 😎

@Mike-EEE Ich habe mir Ihren Data-AST-Vorschlag noch nicht angesehen. Ja, es ist konzeptionell ähnlich dem Standardvorschlag für Serialisierung/Objektnotation für .net. Die Idee ist wegen ihrer Abstraktheit schwer zu verstehen. 😄

In Bezug auf XAML wird ein .net-basiertes, stark typisiertes Datenserialisierungsformat die Notwendigkeit vieler XAML-Markuperweiterungen verringern. Es werden jedoch einige verbleiben, die nicht durch einen Ausdruck (ohne Konstruktoren) initialisiert werden können. Ich wünschte, einige dieser Markup-Erweiterungsfunktionen wären Teil von C# selbst.

Nun, ich habe nichts von @karelz gehört, also kann ich nur annehmen, dass er seitdem als solcher vor seinem Monitor gehockt hat, als er erfuhr, dass Sie eine Konsolenanwendung in Xaml definieren können:

(Schlechte) Witze beiseite, bitte lassen Sie es mich wissen, wenn Sie weitere Fragen haben.

Außerdem sieht aus This Week in .NET wie eine ziemlich coole Engine aus, die in .NET Core gebraut wird . Der erste Kommentar dieses Beitrags sagt alles . :)

@Mike-EEE Ich weiß, dass ich dir eine Antwort schulde (sie ist in meinem Posteingang als wichtig markiert und im Browser geöffnet).
Bisher konnte ich die Antworten nur überfliegen (vielen Dank an alle für all die Details und Einblicke!), aber ich hatte keine Zeit, mich über Xaml weiterzubilden (wie Sie betonen) und alle Antworten gründlich zu lesen in der Lage zu antworten ... Entschuldigung, zu viele Brände und High-Pris sind im Moment im Gange :(, ich werde später darauf zurückkommen, versprochen!

Alles Gute @karelz! Schätzen Sie Ihre Bemühungen und Ihren Dialog hier sehr.

Hier ist eine Stimme für Open Source WPF, jede andere Version von XAML ist im Vergleich Müll. Und im Ernst, Leute, vervollständigt die Schleife, habt einen .net Core / XAML STORE für Unix und MacOS.

@Mike-EEE tut mir sehr leid, ich hatte immer noch keine Zeit, auf dieses Problem zurückzukommen :(

Oh Mann, mach dir keine Sorgen, @karelz Ich weiß, dass alle gerade beschäftigt sind. Ich schätze das Gespräch mehr als alles andere. Mir ist viel aus dem Kopf gegangen. Es ist gut, es da draußen zu sehen und darüber nachzudenken. Außerdem haben wir bis jetzt schon ein Jahr + darauf gewartet ... was sind noch ein paar Monate oder so? :)

Sie sollten Silverlight 5 öffnen. erbärmlich, du bist verloren in la la land wie hollywood oder was...

Wie kann man von Silverlight 5 zu all dem Mist kommen? WIE? Wie können Sie sagen, dass Sie Ihre Benutzer respektieren, wenn Sie immer Assembly-Schnittstellen unterbrechen. Sie benennen sogar Ihr eigenes Nuget-Paket um und geben keine automatische Möglichkeit an, in Nuget von den alten zu den neuen zu wechseln Beta-Tester, weil Sie zu dumm sind, klar zu denken, bevor Sie die Ideen erstellen und programmieren.

Sie müssen die Notwendigkeit von ios/android/uwp-Projekten in Xamarin-Formularen beseitigen. DENKEN SIE, dass es viel bessere Möglichkeiten gibt, mehrere Plattformen zu unterstützen, als ein Projekt für jede Plattform zu haben.

nun alles unter einen bringen f. framework you ass wipes (ich empfehle wpf/silverlight-Abdeckung und xaml-Sprache, aber zum Teufel, wenn Sie alles in xamarin bringen möchten, aber bitte können Sie Datentypen zu den Stilen/Vorlagen hinzufügen für einmal .. warum zum Teufel sollte ich ein Nuget-Paket in allen abhängigen Assemblys installieren müssen?das gleiche mit referenzierter DLL ..?Sie haben keine Vision ... niet keine ... capout ... die ganze Zeit in ms Mist stecken .. ich hätte meine eigenen f. weltklasse sdks bauen können..

Ich kann keinen Tag verbringen, ohne dass MS mir einen Scheißhaufen in die Straße wirft. Ich denke ernsthaft über Scala-Js oder einfach nur über Swift nach. Es ist Zeit, das Haus zu verlassen! Ich habe es satt

Nun, es hat fast zwei Jahre gedauert, aber UWP spezifiziert endlich Markup-Erweiterungen für ihr Xaml-Modell:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Bemerkenswert ist auch, dass Noesis letzte Woche sein v2.0-Produkt auf den Markt gebracht hat, und es sieht ziemlich beeindruckend aus. Sein Xaml-System verfügt bereits über Markup-Erweiterungen (in C++, mit C# auf dem Weg), und es dauerte keine sieben Jahre, bis sie die Spezifikation erreichten. Es ist jetzt auch für Indie-Entwickler kostenlos. Wenn Sie die AmmyUI-Unterstützung berücksichtigen , muss ich sagen, dass dies ganz oben auf meiner Liste steht, was Xaml-Modelle für ATM betrifft:

http://www.noesisengine.com/

Hey @karelz vielleicht kannst du das mal kommentieren. Aber wissen Sie, ob die UWP-Xaml-"Spezifikation", die jetzt passiert, irgendeine Korrelation zu diesem Problem hat? Wenn nicht, wissen Sie, ob es möglich ist? Verrückte Idee hier, aber es könnte nett sein, zwei Probleme zum Preis von einem zu lösen, wenn es geholfen werden kann. Ich habe dort auch eine Nachricht zur UWP-Abstimmung hinterlassen, aber ich dachte, ich würde auch hier pingen.

@Mike-EEE UWP Xaml "spec" wird wahrscheinlich von einer anderen Organisation gesteuert (ich glaube in Windows) - sie nach Details zur Benutzerstimme zu fragen, ist wahrscheinlich der beste Kanal.

Ja, das hatte ich befürchtet. 😛 Ich habe dort eine Antwort bekommen, aber ich muss ehrlich sagen, es ergibt für mich nicht viel Sinn.

Soweit ich weiß, scheint es, dass sie bei ihrem Spezifikationsprozess weiterhin einen geschlossenen Ansatz verfolgen werden. Dies ist besorgniserregend, da es den Anschein hat, dass dies zu den gleichen Ergebnissen wie beim letzten Mal führen würde und in einer API enden würde, die niemand verwenden oder übernehmen möchte.

Vielleicht genießen sie es insgeheim, wenn sich Entwickler über ihre Arbeit beschweren. :)

Wenn Sie dies lesen und ein Befürworter einer transparenten Open-Source-Zusammenarbeit und -Entwicklung sind und es genossen haben, Teil des Erfolgs der asp/.NET Core-Initiative in diesem Bereich zu sein, nehmen Sie sich bitte einen Moment Zeit, um vorbeizuschauen an die WPDev UserVoice und senden Sie ihnen eine Notiz, die sie ermutigt, dasselbe zu tun. Der Link wurde bereits erwähnt, aber hier ist er noch einmal für diejenigen, die dies aus der E-Mail lesen:
https://wpdev.uservoice.com/forums/110705-universal-windows-platform/suggestions/7232264-add-markup-extensions-to-and-improve-winrt-xaml

Ich muss @birbilis anrufen und ihm für seinen früheren Beitrag dort danken. Alle weiteren freundlichen Worte des Vertrauens, die irgendjemand zur Förderung des Prozesses, den wir alle hier verwenden, aussprechen könnten, wären sehr willkommen. 👍

seufz ... genau wie uservoice bringt man die Leute dazu, für Dinge zu stimmen und am Ende nichts dagegen zu unternehmen, selbst wenn es beliebt war!

Aktualisieren:
https://github.com/microsoft/xaml-standard

Ich bin sicher, @Mike-EEE wird sich sehr darüber freuen ;P

Das ist ein toller Schachzug. Danke für das Teilen von @RichiCoder1

Leider ist es nur UI. Andere Verwendungen von XAML wie Sharepoint und WF sind wahrscheinlich out.

Aber ja, zumindest wird es helfen, das XAML über alle unterstützten Plattformen hinweg zu standardisieren.

Guter Zug!

Ich hoffe, sie werden es in Schichten aufteilen

Abgesehen von der Nicht-UI-Basis-XAML-Schicht möchte ich zB die XAML-3D-Schicht sehen

@galvesribeiro Sieht so aus, als hätte jemand ein Problem erstellt: https://github.com/Microsoft/xaml-standard/issues/23 Ich würde +1 geben, kein Grund dafür, dass der eventuelle Standard nicht aufgeteilt wird.

Ich bin sicher, @Mike-EEE wird sich sehr darüber freuen ;P

Haha und Recht hast du, @RichiCoder1! Es ist alles falsch und kaputt und nirgendwo, wo es sein sollte, aber es ist ein Anfang. ;) Danke, dass du es uns hast wissen lassen. 👍

Und ich freue mich sehr, jemanden zu sehen, der https://github.com/Microsoft/xaml-standard/issues/23 erstellt, damit ich es nicht tun muss. ;) ;) ;)

Bitte erwägen Sie die Aufnahme von WF (Workflow Foundation) in den XAML-Standard!!.

@Suriman bitte upvoten!
https://github.com/Microsoft/xaml-standard/issues/23

Deshalb frage ich nur ungern – und ich tue dies im Interesse, ein guter Repo-/Issuer-Bürger zu sein, aber wird dieses Issue noch benötigt? Ich meine, dieses Repo hat bereits mehr als 50 Ausgaben, die viel mehr ins Detail gehen, als es diese Ausgabe jemals kann. Sieht aus, als hätte es schon ein Eigenleben!

Gibt es einen Grund, dieses Thema hier offen zu halten? Wenn ich nicht etwas völlig falsch verstehe (durchaus möglich), denke ich, dass wir das Ziel hier mit dem Xaml-Standard erreicht haben. Es ist Community-getrieben und alles, was mir persönlich am wichtigsten ist. :)

@Mike-EEE Es gibt einen feinen Unterschied zwischen den beiden Problemen; Bei dem einen scheint es mir darum zu gehen, die in XAML selbst verfügbaren APIs zu standardisieren (ausschließlich in XAML selbst), und bei dem anderen geht es darum, XAML als .NET Standard-Komponente ähnlich wie System.Xaml zu unterstützen.

@lokitoth ist definitiv offen für Gespräche darüber, da ich immer noch versuche, alle neuen Stücke zu groken. Ich nehme an, es ist am besten, mit dem Vorschlag zu beginnen, sich das ausgezeichnete und informative Video von @terrajobst anzusehen, das zeigt, wie Code mit dem neuen .NET Standard 2.0 „einfach funktioniert“. Ich persönlich habe mich nicht damit beschäftigt, wie sich dies auf System.Xaml auswirkt. Mein Gedanke war, dass es "einfach funktionieren" sollte, aber vielleicht fange ich an zu glauben, dass ich mich hier irre (ala zu schön, um wahr zu sein).

Und um ehrlich zu sein, nachdem ich ein paar dieser Threads im Xaml-Standard-Repo gelesen hatte, habe ich mich für meinen früheren Vorschlag irgendwie selbst getreten (☕️ der Kaffee hat mich dazu gebracht, ich schwöre! ☕️). So wie es aussieht, wird „Xaml Standard“ besser als „MSFT UX/UI Standard“ bezeichnet, da dies in erster Linie in diesem Repo diskutiert wird. So wie es aussieht, wird Xaml als leistungsstarke Serialisierungstechnologie überhaupt nicht präsentiert/dargestellt/hervorgehoben (außer den wenigen mutigen Stimmen hier, die sich dort bemüht haben), was auch zu einer gewissen Trennung/Verwirrung führt.

Ich persönlich habe mich nicht damit beschäftigt, wie sich dies auf System.Xaml auswirkt.

Wir müssten die Assembly untersuchen, um herauszufinden, ob ihre Abhängigkeitsstruktur in einem .NET Standard 2.0-Kontext ladbar ist. Wenn es sich um reines .NET handelt, funktioniert es wahrscheinlich (obwohl es eine ganze Reihe von Elementen zur Kompilierzeit gibt, z. B. BAML, eingebettete Ressourcen usw., die in die Toolchain von .NET Core gebracht werden müssten).

So wie es aussieht, wird „Xaml Standard“ besser als „MSFT UX/UI Standard“ bezeichnet, da dies in erster Linie in diesem Repo diskutiert wird.

Das liegt meiner Meinung nach eher an der Ankündigung im Zusammenhang mit UWP/Xamarin.Forms, was bedeutet, dass Entwickler, die sich auf diese beiden Plattformen konzentrieren – die möglicherweise nicht mit „BigXaml“ in Kontakt gekommen sind – diejenigen sind, die in erster Linie dazu beitragen. Obwohl Sie sehen, dass einige Probleme „Bringen Sie den gesamten WPF-XAML-Dialekt mit“ geöffnet wurden.

Angesichts der Tatsache, dass das Team eine Menge Aufräumarbeiten zu erledigen hat und die Rate neuer Probleme im Verhältnis zur Anzahl der Personen, die dazu beitragen, im Moment ziemlich hoch ist, würde ich dem Team etwas mehr Zeit geben, um zu sehen, wohin das Team führt.

@Mike-EEE @terrajobst @terrajobst @cwensley @mellinoe
Ich habe ein Problem in Xaml Standard erstellt.
https://github.com/Microsoft/xaml-standard/issues/57

Danke für die Hinweise und den Beitrag zum Gespräch, @juepiezhongren!

gut @lokitoth Ich bin froh, dass wir dieses Problem intakt gelassen haben, da entschieden wurde, dass https://github.com/Microsoft/xaml-standard/issues/23 nicht für Tageslicht geeignet ist.

Ich habe jedoch ein neues Problem erstellt, das meiner Meinung nach das vorliegende Problem besser beschreibt, und es wäre großartig, wenn Ihre positive Bewertung und/oder Beiträge hier hinzugefügt würden: https://github.com/Microsoft/xaml-standard /ausgaben/145

Zur Verdeutlichung: Was Sie suchen, sind eigentlich _JavaScript_+HTML5+CSS3-generierte Artefakte. TypeScript ist eigentlich ein Transpiler für JS. Anstatt einen .NET-Transpiler zu erstellen, um standardkonformes JS zu erstellen, das effektiv in einem Browser ausgeführt werden kann (wie JSIL ), entschied sich MSFT, die kostbare Zeit des C#-Entwicklers zu verwenden, um etwas zu erstellen, das effektiv und letztendlich damit konkurrieren würde.

Ich würde sagen, lass mich nicht damit anfangen, aber ich glaube nicht, dass ich jemals damit aufgehört habe. 😛

Ein weiterer Punkt ist, dass CSHTML5 dem, was Sie suchen, sehr nahe kommt @weitzhandler , aber keinen gemeinsam genutzten Code zwischen Client/Server-Assemblys (wie PCLs usw.) zulässt. Sie müssen also immer noch zwei separate, inkompatible Codebasen pflegen, was zu demselben Kosten-/Geschäftsproblem zwischen .NET und JS (oder TypeScript 😉) führt, das beispielsweise in einer reinen NodeJS-Lösung nicht existiert.

Mein Traum ist die Verwendung des Android-XML-UI-Schreibstils für Desktop-Apps mit Dot-Net-Core! ja wirklich!!

Jede Bemühung, XAML auf .NET Core zu portieren, unternehme ich freiwillig.

In meinen Änderungen an CoreWf (WorkflowFoundation on net standard 2.0) sehe ich, dass System.Xaml oder eine kompatiblere Portable.Xaml-Implementierung wahrscheinlich erforderlich sein wird, um das Laden von DynamicActivity aus Xaml zu ermöglichen. Ich habe CoreWf auf .net-Framework mit grundlegendem DynamicActivity-Laden mit System.Xaml ausgeführt, schlägt aber immer noch fehl, weil der Parsing-Status auf .net-Core mit Portable.Xaml ungültig ist.

Eine Frage ist, warum wird der Code zu System.Xaml nicht zum Mit-lizenzierten Referenzquellrepository hinzugefügt? Gibt es ein Lizenz-, Patent- oder anderes Problem? Wenn es kein Problem gibt, würde das Hinzufügen dieses Codes zur Referenzquelle uns, der Community, ermöglichen, die zur Unterstützung von CoreWf erforderliche Portierung vorzunehmen. Das Referenzquellrepo verpflichtet Microsoft nicht zur Unterstützung von System.Xaml. Sollte ich dort ein Problem hinzufügen, in dem nach dem Öffnen von System.Xaml gefragt wird?

Wenn System.Xaml nicht geöffnet ist, können wir dann ein Dokument (anders als die Xaml-Spezifikation) oder Unterstützung in Form von Tests haben, die die richtigen Schritte zum Analysieren und Tokenisieren des Xaml-Codes für WorkflowFoundation beschreiben?

Hey FWIW @karelz , ich habe hier einige Gedanken zum DevOps-Szenario gemacht:
https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/31381861-innovate-the-xaml-designer-dawg

Basierend auf einigen coolen Ereignissen im XAML-Designer von Visual Studio:
https://blogs.msdn.microsoft.com/visualstudio/2017/09/11/a-significant-update-to-the-xaml-designer/

Ich dachte, ich erwähne es hier, wenn ich schon dabei bin. 👍 Außerdem ist dieser Thread für eine Beule überfällig. 😆

@weitzhandler du musst aktualisiert werden, da mono-wasm auf dem alphaweg ist, ist es fast an der zeit js zu vergessen.

@weitzhandler 2 oder 3 Jahre erforderlich, aber es ist nicht nur ein Full-Stack, es ist ein Universal-Stack für .net.

CoreRT ist ebenfalls an Bord – https://github.com/dotnet/corert/pull/4480 . Ich hoffe auf eine produktionsreife HTML+CSS+C#-Kombination im nächsten Jahr.

Das vorgeschlagene .net-Kompatibilitätspaket enthält System.Xaml mit möglicherweise Status und ist mit diesem Problem verknüpft.

Anscheinend wurde dieses Problem für das Compat Pack 2.1 verlinkt? Kann jemand bestätigen? Ich sehe, dass es mit netfx-compat-pack gekennzeichnet wurde, aber nicht mit einer Version. Ich übernehme das jedoch über alles, was bisher passiert ist. 😄

Ich hasse es zu enttäuschen, aber ich glaube, ich habe dies versehentlich als 2.1 markiert, als ich die Ausgaben des Comapt-Pakets massenweise aktualisierte. Ich bin zu Future gewechselt, um den Vielleicht-Status im Vorschlag widerzuspiegeln.

@Mike-EEE es scheint, dass xamarin.wasm ankommen soll.
https://github.com/mono/mono/pull/5924#issuecomment -343551464

Danke für das Update Herren. Schön, dass du an mich denkst. :) @terrajobst , das ist in der Tat enttäuschend, aber ich weiß es zu schätzen, dass Sie sich die Zeit genommen haben, einzuchecken und zu aktualisieren. Ich war mir nicht sicher, ob du diesen Thread noch abonniert hast oder nicht. 👼

Da wir uns Zeit nehmen, um Projekte schamlos einzufügen (und dass es einige Zeit dauern wird, bis wir unseren offiziellen Xaml-Fix erhalten), werde ich kurz erwähnen, dass ich das letzte Jahr damit verbracht habe, bei v2 von ExtendedXmlSerializer zu helfen. die vor kurzem veröffentlicht wurde. Es bietet experimentelle Unterstützung für Markup-Erweiterungen und angehängte Eigenschaften (die auf POCO funktionieren, kein DependencyObject erforderlich) sowie parametrisierte Serialisierung im protobuf -Stil .

Wenn Sie nach Xaml-ähnlichen Funktionen suchen (oder diese hinzufügen möchten), während wir auf die Ankunft von System.Xaml warten, können Sie sie gerne ausprobieren, Feedback geben oder (noch besser) eine PR im Repository einreichen. 👍

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

@danmosemsft wird Workflow Foundation xaml in SDK-Projekten als Teil der 3.0-Desktop-Initiative unterstützt?

@lokki Ich kenne keine Pläne. @terrajobst @karelz?

@danmosemsft
Warum gibt es kein Problem mit der Aufschrift „Bereitstellen eines UI-Frameworks als Teil von .NET Core“?

In dieser Ausgabe geht es nicht speziell um das Fehlen eines UI-Frameworks, und es sieht nicht so aus, als ob die Leute hier das erkennen würden.
Siehe dazu: https://github.com/Microsoft/xaml-standard/issues/232

@weitzhandler Dieses Problem macht für mich jetzt VIEL mehr Sinn. Danke für die Klarstellung.

Ich kann sehen, dass es nützlich ist, System.Xaml in den .NET-Standard aufzunehmen, insbesondere neben XAML-Standard.

Wenn ich die "Desktop-Initiative" richtig verstehe, sollten Sie in der Lage sein, .NET-Bibliotheken zu verwenden, die Sie in der Vergangenheit verwenden konnten, solange Sie nur auf Windows abzielen (nicht sicher, ob sich Ihre App dynamisch an die Umgebung anpassen kann es ausgeführt wird, wenn die Haupt-App dies nicht tun kann [z. B. nicht starten würde, wenn es kein Windows-Betriebssystem findet], könnten Sie dies wahrscheinlich tun, indem Sie mehrere .NET Core-Assemblys erstellen, die die plattformspezifischen Dinge aufrufen und laden Sie sie bei Bedarf, abhängig von der Plattform, auf der die App erkennt, dass sie ausgeführt wird)

@birbilis nicht genug. Gleiches XAML muss auf allen Plattformen gleich gerendert werden.

Bei der Desktop-Initiative geht es nicht um XAML, sondern darum, dass .NET Core kein Silo mit dem kleinsten gemeinsamen Nenner ist, sondern Apps ermöglicht, die auf bestimmte Plattformen abzielen (oder idealerweise auch dynamisch an die Plattform angepasst werden können, auf der sie ausgeführt werden) und dies ermöglichen Nutzen Sie sie am besten, führen Sie plattformspezifische Integrationen durch usw. Man könnte auf dieser Funktionalität funktionsbasierte APIs aufbauen, sodass dann Apps geschrieben werden können, die nur die Verfügbarkeit einer bestimmten Funktion abfragen. Darauf können auch Abstraktions-/Kompatibilitäts-APIs aufbauen, die sich in verschiedene Implementierungen für jede Plattform einklinken, an deren Unterstützung die Autoren einer API interessiert sind.

Im Moment denke ich, dass Portable.Xaml jetzt so nah an System.Xaml ist. Wenn Sie ein Problem finden, geben Sie bitte Feedback.

Das WPF-Team (@dotnet/wpf-developers) hat soeben das Open-Sourcing von WPF für .NET Core 3.0 angekündigt . Als Teil davon enthalten die Preview-Builds für .NET Core 3.0 jetzt System.Xaml, und die entsprechenden Quellen sind unter https://www.github.com/dotnet/wpf verfügbar.

Übrigens