Aspnetcore: Trennen Sie die .NET Core-to-WASM-Erfahrung von Blazor

Hallo @EisenbergEffect! Die Kernarbeit von WebAssembly wird tatsächlich vom Mono-Team erledigt. Wir bauen Blazor auf dem, was sie bieten. Andere in der .NET-Community können dies ebenfalls tun, und einige tun dies bereits ( Ooui , Uno , cshtml5 ). Sie können den Fortschritt von mono.wasm im Mono- Repository verfolgen.

Ich bin nicht daran interessiert, Mono zu WebAssembly zu kompilieren. Ich interessiere mich nur für .NET Core. Was ich verlange ist in etwa so:

• Verwenden Sie die .NET-CLI, um ein .NET Core C#-Projekt zu erstellen.
• Verwenden Sie die .NET-CLI, um mein .NET Core-Projekt in WASM zu kompilieren, mit den drei oben beschriebenen Ausgaben.

@danroth27 Wird das heute unterstützt?

Die Mono-Leute arbeiten auch an der vollständigen AoT-Kompilierung von .NET-Code für WebAssembly zusammen mit dem unterstützenden MSBuild SDK. Das letzte Update, das sie zu diesem Versuch veröffentlichten, war http://www.mono-project.com/news/2018/01/16/mono-static-webassembly-compilation/. @mhutch ist wahrscheinlich der beste Kontakt, um den neuesten Stand zu

Mono interessiert mich nicht. Ich interessiere mich nur für .NET Core. Gibt es eine Geschichte für .NET Core WASM?

Gibt es eine Geschichte für .NET Core WASM?

Derzeit nicht. .NET Core wird heute hauptsächlich für plattformübergreifende Serverszenarien verwendet. Mono ist die .NET-Runtime, die heute für plattformübergreifende Client-Szenarien (Android, iOS, macOS, Gaming) verwendet wird. Die meisten WebAssembly-Szenarien sind heute Client-Szenarien, daher ist Mono derzeit der günstigste Weg. Im Laufe der Zeit ist davon auszugehen, dass es eine Konvergenz geben wird, aber das wird einige Zeit dauern.

FWIW Ich denke wirklich, dass dieses Problem der Laufzeiten und Plattformziele zuerst angegangen werden muss. Wenn ich höre, dass ich zwei verschiedene .NET-Varianten verwenden muss, um eine App zu erstellen ... Mono für Ihren Client und dann .NET Core für Ihren Server verwenden ... es regt mich überhaupt nicht auf. Ich möchte nur .NET Core verwenden und ehrlich gesagt vergessen, dass andere .NETs existieren. Eine .NET bitte :)

@EisenbergEffect Aus konsumierender Perspektive sollte es so ziemlich ein Implementierungsdetail sein, welche Laufzeit Ihren Code

Ich bin nicht einverstanden. Niemals in meiner Geschichte als Softwareentwickler habe ich in Betracht gezogen, welche Laufzeit meinen Code ausführt, um ein Implementierungsdetail zu sein, das ich ignorieren kann.

@danroth27 Nur ein paar Rückmeldungen von meinem Entwicklungsteam, wir möchten auch, dass Blazor irgendwann .NET Core verwendet. Wir interessieren uns weder für Mono noch für das vollständige .NET-Framework. Wir wollen die gleiche Laufzeit auf Client und Server.

Wir interessieren uns weder für Mono noch für das vollständige .NET-Framework. Wir wollen die gleiche Laufzeit auf Client und Server.

Nun, egal was wir machen, Sie werden nicht genau die gleiche Laufzeit auf dem Server und im Browser haben: Die Browser-Laufzeit muss WebAssembly-basiert sein, die Server-Laufzeit jedoch nicht. Es ist nicht unähnlich, wie sich die Ausführung auf iOS grundlegend von der Ausführung auf dem Server unterscheidet. Der verbindende Faktor auf Client und Server ist .NET Standard. Ich denke jedoch, dass wir Ihr Ziel teilen, eine einheitliche Laufzeitimplementierung zu erreichen. Es macht für Microsoft auf Dauer keinen Sinn, zwei Laufzeiten zum doppelten Preis zu besitzen und zu pflegen. Konvergenzarbeit findet bereits in vielerlei Hinsicht statt. Immer mehr Code in Mono und .NET Core wird geteilt. Das Erreichen einer einzigen Laufzeit ist jedoch immer noch ein großer Aufwand, der einige Zeit in Anspruch nehmen wird.

Inzwischen ist Blazor ein Experiment und wir experimentieren damit, was heute zum Laufen gebracht werden kann 😃

@danroth27 Danke für die ausgezeichnete Antwort, Dan!

Ausgezeichnet stimme voll und ganz zu

Am Di, 15. Mai 2018, 10:54 Uhr schrieb paulost [email protected] :

@danroth27 https://github.com/danroth27 Danke für das ausgezeichnete
Antwort, Dan!

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/aspnet/Blazor/issues/835#issuecomment-389046589 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ACnwPz_cCiVg6iti9VR9pQWY34_Hibf4ks5tymapgaJpZM4T-jpA
.

@EisenbergEffect Ich hatte eine ähnliche Meinung zu Mono, aber als ich erfuhr, dass Mono seit der Übernahme von Xamarine durch Microsoft Microsoft-Technologie ist ... Und für Client-Szenarien optimiert ist ... Und ich kann damit meinen ".net-Standard" -Code ausführen Browser heute... Alle Bedenken wurden beiseite gewischt.

So greifen Sie nur auf Browser-Laufzeitkomponenten zu:
https://jenkins.mono-project.com/job/test-mono-mainline-wasm/label=ubuntu-1804-amd64/

... Jetzt komme ich wieder dazu, meinen eigenen XAML-basierten UI-Stack in C# zu erstellen, der auf WebGL abzielt

Um es klar zu sagen, es geht nicht darum, Nicht-Microsoft-Technologie zu verwenden. Es geht darum, nur .NET Core verwenden zu wollen. Ich suche nach einem Open-Source-, plattformübergreifenden .NET mit einer einheitlichen plattformübergreifenden CLI. Nicht zwei oder drei .NETs oder mehrere Compiler. Ich hätte gedacht, dass sich neue Bemühungen auf .NET Core und die Vereinheitlichung konzentrieren würden, daher fand ich es überraschend, dass WASM nur für Mono war und eine andere Toolchain erforderte.

Ich persönlich fordere seit über 10 Jahren die Vereinheitlichung der .NET-Plattform. Verzeihen Sie mir, wenn ich in diesem Thread etwas aufgeregt bin, da ich nach 10 Jahren immer noch 3 .NETs benötige, um meine Dienste und Clients aufzubauen. Es gibt nur sehr wenige Dinge, auf die ich bereit bin, 10 Jahre zu warten. Ich habe .NET vor einigen Jahren verlassen und schaue seit Dezember zurück, um zu sehen, ob sich die Situation verbessert hat. Ich bin mehr als ein wenig entmutigt, dass viele der gleichen Probleme, die ich zurückgelassen habe, immer noch bestehen.

Ich meine das mit aller Aufrichtigkeit, ich möchte .NET wieder lieben. Bitte nehmen Sie dies ernst.

Ich meine das mit aller Aufrichtigkeit, ich möchte .NET wieder lieben. Bitte nehmen Sie dies ernst.

Wir nehmen dieses Thema ernst und arbeiten aktiv an der Konvergenz der verschiedenen .NET-Laufzeiten. Aber es wird Zeit brauchen, und wir können sehr wohl entscheiden, dass es kurzfristig aus praktischen Erwägungen sinnvoll ist, mit Mono mit einer längeren Roadmap für die Konvergenz mit .NET Core fortzufahren.

Ich benötige noch 3 .NETs, ​​um meine Dienste und Clients aufzubauen

Ich gehe davon aus, dass die drei .NETs, ​​auf die Sie sich beziehen, .NET Framework, .NET Core und Mono sind. Die gute Nachricht ist, dass wir auf der BUILD angekündigt haben, dass .NET Core 3 Windows-Desktopanwendungen unterstützen wird, was hoffentlich den Bedarf an einer dieser Laufzeiten verringert und einen weiteren Beweis dafür liefert, dass Konvergenz unser gemeinsames Ziel ist.

FWIW, Mono ist bereits auf den Roslyn-Compiler und das msbuild-Build-System umgestiegen, es handelt sich also nicht wirklich um eine andere Toolchain. Sie können .Net Core- und Mono-basierte Projekte in einer einzigen Lösung mit demselben Build-System und Compiler erstellen. Mono verwendet auch große und ständig wachsende Teile der .NET Core-Klassenbibliotheken.

WASM ist ein ziemlich ungewöhnliches Ziel. Es ist nicht nur nicht möglich, JIT zu kompilieren, Dinge wie Threading, Datei und Sockets haben auch ganz andere Modelle als die meisten anderen Plattformen. Mono hat viele bestehende Technologien für Ports auf andere ungewöhnliche/eingeschränkte Plattformen wie iOS, watchOS, PS4 usw. entwickelt, die bei der WASM-Portierung helfen, wie der IL-Interpreter, kooperativer GC-Suspend, Full AOT (überraschend schwer für Generika) mit Generika-Sharing , LLVM-Bitcode-Backend und Managed Linking.

Ich gehe davon aus, dass der WASM-Projekttyp von Mono Projekte im SDK-Stil verwendet, wobei ein MSBuild-SDK über NuGet bereitgestellt wird und ab dotnet .

Ich glaube, ich rieche hier etwas Mono-Hass, nicht wahr?
Bitte seien Sie nicht so schnell, Mono wegwerfen zu wollen. Erinnern Sie sich, als Microsoft Linux nicht liebte? Mono war für C#-Entwickler da. Erinnern Sie sich, als Microsoft Mac OS nicht liebte? Mono war wieder da. Jetzt isst JavaScript unser Mittagessen, rate mal, wer auftaucht? Sie können darauf wetten, Mono ist hier, um den Tag zu retten, da es das erste vollständige .net ist, das auf Wasm läuft. Bitte zeigen Sie etwas Respekt!

Hören Sie, wir C#-Entwickler dieser Seite lieben Mono. Sie machen einen fantastischen Job. Lass Mono in Ruhe. Wenn cooles Kind .Net Core feiern möchte, ist das auch in Ordnung, ABER MONO BLEIBT!

@humbersoft Wenn du einen Grund willst, warum wir Mono "hassen" gebe ich dir einen. Es werden Fehler wie diese in Ihrer Browserkonsole angezeigt: "WASM: Es sollte im Verzeichnis `/Users/builder/jenkins/workspace/test-mono-mainline-webassembly/label/highsierra/sdks/out/wasm-interp/ installiert worden sein. lib/mono/4.5/mscorlib.dll'-Verzeichnis." Wer ist Jenkins? Was für eine seltsame Botschaft! Ein Mono-Entwickler hat offensichtlich seinen persönlichen Weg in der Laufzeit fest codiert.

@paulost Jenkins ist ein kontinuierlicher Build-Dienst. Suchen Sie danach. Es ist sehr beliebt.

Danke @MisinformedDNA, aber warum sagt mir Mono, dass es genau in diesem Pfad auf meinem System installiert werden sollte? Ich versuche nicht, Mono zu erstellen, sondern verwende es nur, um eine Blazor-App auszuführen. Eine ausgelieferte Laufzeit sollte Ihnen nichts über ihren Build-Service-Pfad sagen.

Ich habe nicht den vollständigen Kontext des Fehlers, aber ich kann Ihnen garantieren, dass zusätzliche Debug-Informationen angezeigt werden, da Blazor kein ausgeliefertes Produkt ist. Mono wird möglicherweise ausgeliefert, aber wir verwenden möglicherweise auch Vorschauversionen von Mono oder Vorschaubibliotheken, die auf Mono aufbauen. Denken Sie daran, wir befinden uns noch in der experimentellen Phase.

Schließlich läuft Xamarin auf Mono, auf dem wahrscheinlich Tausende von mobilen Apps ausgeführt werden. Es ist eine gut gemachte Technologie. Wäre es besser eine Laufzeit zu haben? Natürlich. Aber .NET Framework ist nur für Windows und Mono wurde später als Port für die Kompatibilität mit Linux erstellt und .NET Core wurde dann für eine bessere Skalierbarkeit in der Cloud erstellt. Glauben Sie wirklich, dass MS es vorzieht, drei separate Laufzeiten zu verwalten? Natürlich nicht. Aber nicht jede Sprache hat das Ausmaß oder den Ehrgeiz von .NET. Falls Sie es verpasst haben, portiert MS WPF, WinForms und UWP auf .NET Core 3.0 . .NET Core ist die Zukunft, aber es wird Zeit brauchen.

Ja, die Mono-Webassembly-Unterstützung befindet sich in der Vorschauphase und wird noch in keiner Version ausgeliefert.

In diesem speziellen Fall versucht die Laufzeit, das Laufzeit-Assembly-Verzeichnis (das Dateien wie mscorlib.dll enthält) basierend auf dem aktuellen Speicherort des Dateisystems zu ermitteln, und der letzte Fallback ist der Pfad, in dem die Laufzeit kompiliert wurde. Auf wasm trifft das Konzept eines "Dateisystemspeicherorts" nicht wirklich zu ... Bei anderen ähnlichen eingebetteten Setups registriert der Einbettungscode normalerweise einen benutzerdefinierten Assembly-Resolver (z wurde hier noch eingerichtet.

@PaulOst
Das ist die Sache mit dem Leben am Rande, Sie werden wahrscheinlich geschnitten. Mono für WASM befindet sich in einem frühen Stadium und ist sehr experimentell, aber es ist vollständiger als das DotNet Anywhere, auf dem Blazor ursprünglich basierte. Es ist noch nicht sicher, also sind Fehler wie die, die Sie erleben, zu erwarten.

Manche Entwickler mögen die heißen Teile, manche warten lieber, bis alles kühl und ruhig ist. Dies sind heiße Teile, vielleicht müssen Sie Ihre Erwartungen ein wenig anpassen. Ich verstehe die Perspektive jedoch, Sie wollen ein poliertes Produkt. Können Sie sich vorstellen, darauf zu warten, dass .NET Core auf Wasm abzielt? Sie kommen möglicherweise erst nach 3 Jahren dazu. Mono ist ein solides Produkt und es ist ein Glück, dass Microsoft sie hat, sonst hätten wir keine .NET-Geschichte für WASM und so viele andere Plattformen.

Eine andere Sache, ich möchte Ihnen sagen, dass die meisten Entwickler das neue Microsoft bevorzugen, das wichtige Technologien wie diese offen entwickelt. Am Ende haben wir ein besseres Produkt.

Trotz all dessen erblickt Blazor aus einer Vielzahl von guten Gründen möglicherweise nicht einmal das Licht der Welt. Planen Sie auch das ein.

Ich machte weiter und begann mit dem Aufbau einer Xaml-Engine, die nativ im Browser ausgeführt wird. Sie können es hier überprüfen: https://github.com/XamlEngine/Samples

Ich schließe mich dieser Diskussion etwas spät an, bin aber überrascht, dass so viele Leute besorgt sind, wie ihr .NET-Standardcode ausgeführt wird. Fügen Sie der Laufzeit ein beliebiges Label hinzu – Mono, .NET Core, FlubberGast – unabhängig davon, ob die tatsächliche Laufzeit anders ist. Es gibt keine Möglichkeit, dass .NET Core auf dem Server mit .NET Core auf WASM identisch ist oder gegen WASM kompiliert wird. Also wen zum Teufel interessiert das wirklich?

Wichtig ist, wie der Gummi auf die Straße trifft oder wie einfach es ist, auf diesen Laufzeitcode zuzugreifen. Ich stimme @EisenbergEffect zu , dass ein einfacherer niedrigerer Pfad zum .NET-Bootstrapping für .NET im Allgemeinen ein großer Schub sein könnte.

Warum nicht zusätzlich zu Blazor einen ernsthaften Vorstoß machen, da dies sicherlich Innovationen in Bezug auf verschiedene Arten der Verwendung von .NET im Browser vorantreiben würde. Dies kann nur ein großes Plus für die Sichtbarkeit von NET sein, wenn viele neue Projekte auftauchen, die .NET auf neue und innovative Weise im Browser verwenden. Ich bin mir sicher, dass Rob fragt, weil er einige Ideen hat, wie man ein neues Framework bauen könnte :-)

Dies ist heute mit dem aktuellen Mono.wasm-Modul und in Zukunft mit .NET Core oder zumindest dem Mono AOT-Compiler machbar, aber ich denke, der Aufbau einer Standard-Hosting-Schnittstelle, die das Einbinden von .NET in den Browser erleichtern könnte, würde einen großen Beitrag dazu leisten dieses Ziel. Die eigentliche Laufzeit kann dann angeschlossen und ausgetauscht werden, sobald aktualisierte Technologie und Ressourcen verfügbar sind.

Dies scheint eine große Chance für .NET zu sein, ein Early Adopter im Web Assembly-Bereich zu werden. Was ich bei Blazor gesehen habe, sieht sehr vielversprechend aus, aber ich denke, es ist nicht fortschrittlich genug, wenn dies der einzige offizielle WASM-Exponierungspunkt von .NET ist. Ich mag das Blazor-Modell wirklich und was es ermöglicht, aber ich denke, das ist nur die Spitze des Eisbergs dessen, was möglich wäre, wenn das Ökosystem zum Ausführen von .NET so einfach wäre wie das Erstellen einer Standard-.NET-Anwendung. Ich spreche hier nicht unbedingt von UI-Frameworks - sondern sogar nur in der Lage zu sein, lose .NET-Klassen entweder als Einstiegspunkt und Web-Worker-ähnliche Verarbeitung zu booten und aufzurufen oder sogar als Mittel zur Interoperabilität von bestehenden JavaScript-Anwendungen. Sogar dafür können die Vorteile der Weitergabe von Geschäfts-/Validierungscode unglaublich wertvoll sein.

Viel Potenzial - es wäre cool, dies so weit wie möglich zu ermöglichen, indem die Verwendung dieser Technologie, auch der Bits der unteren Ebene, einfach gemacht wird!

@RickStrahl Es Dies gibt Ihnen eine bessere Vorstellung davon, was sie überlegen.

Oh, ich glaube nicht, dass Blazor nicht progressiv ist - habe ich in meiner obigen Nachricht klargestellt. Selbst wenn ich nur damit herumspiele, kann ich absolut sagen, dass dies eine großartige Möglichkeit sein wird, Apps zu erstellen. Es gibt so viele kleine Momente, in denen man einfach hingeht - das wäre in Javascript/Typescript so ein Schmerz.

Mein Punkt ist hauptsächlich, dass ich denke, dass sie zusätzlich zum Blazor-Zeug auch die rohe .NET-Funktionalität hinzufügen sollten. Diese Infrastruktur muss sowieso erstellt werden, um Blazor zu unterstützen. Warum also nicht sie auf eine benutzerfreundlichere Weise bereitstellen, damit es kinderleicht ist, das .NET-Hosting in einer Client-App abzulegen.

Ich bin mir nicht sicher, ob ich das verstehe, Blazor lässt uns die meisten .NET-Funktionen verwenden. Welche Funktionen fehlen Ihrer Meinung nach?

Ich muss Blazor benutzen. Was ist, wenn ich eine vorhandene HTML-Anwendung habe oder etwas mit einem anderen Framework erstelle und Blazor nicht benötige? Es gibt immer noch einen großartigen Anwendungsfall für den Zugriff auf .NET-Code im Browser außerhalb eines HTML-Frameworks (Freigabe von Validierungscode, Dienstprogrammen usw. usw.).

Ich muss Blazor benutzen. Was ist, wenn ich eine vorhandene HTML-Anwendung habe oder etwas mit einem anderen Framework erstelle und Blazor nicht benötige? Es gibt immer noch einen großartigen Anwendungsfall für den Zugriff auf .NET-Code im Browser außerhalb eines HTML-Frameworks (Freigabe von Validierungscode, Dienstprogrammen usw. usw.).

Ich verstehe nicht. Blazor ist im Wesentlichen:

1. Razor-Syntax für Webkomponenten,
2. verschiedene JS-Interop-Helfer,
3. Mono-basierte WebAssembly .NET

Vermutlich willst du das zweite und dritte davon, und das erste schadet dir nicht.

Mein Punkt ist hauptsächlich, dass ich denke, dass sie zusätzlich zum Blazor-Zeug auch die rohe .NET-Funktionalität hinzufügen sollten. Diese Infrastruktur muss sowieso erstellt werden, um Blazor zu unterstützen. Warum also nicht sie auf eine benutzerfreundlichere Weise bereitstellen, damit es kinderleicht ist, das .NET-Hosting in einer Client-App abzulegen.

Das ist sicherlich die Absicht der mono.wasm-Bemühung, wie ich sie verstehe. Wir bezeichnen Blazor und mono.wasm oft in einem Atemzug, aber in Wirklichkeit ist Blazor nur ein Web-Framework. Es ist mono.wasm, das die zugrunde liegende WebAssembly-basierte .NET-Laufzeit bereitstellt. Andere Frameworks können kostenlos auf derselben Laufzeit aufbauen, und es gibt bereits alternative Frameworks ( Ooui , Uno ). @kumpera @mhutch sind wahrscheinlich die richtigen Leute im Xamarin-Team, um mit den Entwicklern zu sprechen, die sie bei der Verwendung von mono.wasm unabhängig von einem bestimmten UI-Framework ermöglichen möchten.

Die ZIP-Datei bietet heute extrem rohe Unterstützung für das Schreiben von C#-Apps ohne Blazor. Es ist gut genug, um die Technologie zu validieren, erfordert jedoch viel manuelle Arbeit.

Unser Ziel ist es, eine vollständige Toolchain mit umfangreichen Bindungen und Debugging bereitzustellen, was diese Problembeschreibung vorschlägt.

Welche Zip-Datei?

@EisenbergEffect Worum Sie sich kümmern sollten, ist .NET Standard, nicht .NET Core.
Stellen Sie sicher, dass Ihre abhängigen APIs auf .NET Standard basieren und Sie gut sind.

@weitzhandler Ich denke, Sie verpassen vielleicht meinen Punkt. Wenn ich mit .NET etwas bauen möchte, muss ich einige konkrete Tools installieren, nicht wahr? Ich habe vor über 15 Jahren angefangen, mit .NET zu arbeiten, daher finde ich persönlich nichts davon abschreckend oder verwirrend (obwohl ich es vorziehe, keine quasi-duplikativen Tools auf meinem Computer zu installieren). Aber stellen Sie sich jemanden vor, der keine Erfahrung mit .NET hat und ein Mac-Benutzer ist. Sie beschließen, eine .NET-App zu erstellen, sowohl als Front-End als auch als Back-End. Sie hören, dass .NET Core das neueste, schicke Ding ist, also gehen sie die Rigamarole durch, um die .NET-CLI und den VS-Code zu installieren. Dann stellen sie fest, dass sie ihr Frontend damit nicht aufbauen können. Sie müssen sich andere Werkzeuge besorgen (mit einem anderen Namen, von einem anderen Ort, mit einer anderen Führung usw.). Stellen Sie sich erneut vor, sie haben keine Vorgeschichte mit .NET. Dies ist keine gute erste Erfahrung. Ok, jetzt stellen Sie sich vor, diese Person ist ein Architekt oder CTO, der versucht, .NET zum ersten Mal oder nach einigen Jahren neu zu bewerten. Vielleicht geben sie die Richtung für ihr Unternehmen vor. Ist dies die Erfahrung, die Sie dieser Person oder ihren technischen Beratern wünschen? Sie werden es mit Go, Node, Rust usw. vergleichen.

Was meine persönlichen Gefühle angeht, ist meine Toleranz nach so vielen Jahren und so vielen Versionen von .NET ziemlich gering. Ich versuche, Leuten wie @danroth27 zu helfen, ein bisschen zu verstehen, was passieren muss, damit sich Leute wie ich wieder für .NET interessieren. Es steckt noch viel mehr dahinter, aber ein bisschen mehr Vereinheitlichung würde sicherlich helfen. Ich möchte nur eine einzelne CLI und VS-Code installieren. Das Einrichten und Ausführen einer Full-Stack-.NET-App auf Nicht-Windows-Plattformen sollte nicht komplizierter sein.

Mein ursprünglicher Beitrag sollte ein einfaches Bild davon zeichnen, wie ein WASM-"Nordstern" aus einer Entwicklungs- und Ausgabeperspektive aussehen sollte. Ich installiere die CLI, schreibe C#-Code (mit einem beliebigen Editor) und führe dann einen CLI-Befehl aus, um meinen C#-Code in WASM zu erstellen und einen vernünftigen Satz von Ausgabedateien (wasm, Bindings, Typen) zu erzeugen. Das sollte das Ziel sein. Wenn es heute nicht da ist, ist das verständlich. Aber lassen Sie uns sicherstellen, dass wir das .NET-Schiff in die richtige Richtung segeln, um das bestmögliche Erlebnis zu erreichen, und uns nicht mit dem zufriedengeben, was für Microsoft-Ingenieure einfach am einfachsten oder schnellsten ist.

@EisenbergEffect
Rob, ich stimme zu, dass das Ziel letztendlich darin bestehen würde, .NET Core überall laufen zu lassen und sogar Mono damit zu ersetzen.
Ich möchte sogar, dass ein " .NET UI-Standard ", der überall gleich rendert, in .NET Core enthalten ist, aber .NET Core ist relativ neu. .NET Standard war die beste Lösung, um diese Divergenz in Form zu bringen, und derzeit sieht es so aus, als könnte man sich nichts Besseres wünschen.

Meine Stimme ist für das Ersetzen von Mono durch .NET Core für die gleichen Punkte, die @EisenbergEffect gemacht hat.

@EisenbergEffect Ich habe einen Traum von einem Caliburn-Mikro für das Web, haben Sie das im Sinn? Ich habe tatsächlich vor einiger Zeit angefangen, an spirituellen Nachfolgern mit Knockout und Duocode (JavaScript-Portierung von mscorlib) zu arbeiten, bevor Webassembly eine Sache war.

@AndersMalmgren Aurelia ist heute Caliburn.Micro für das Web sehr ähnlich. Die vNext-Version, an der wir in diesem Jahr arbeiten, unterstützt sogar alternative Renderer, sodass sie nicht nur in HTML, sondern auch in native Desktop-, 3D- und Konsolen-Apps rendern kann. Es ist jedoch in TypeScript geschrieben, nicht in .NET. Es könnte möglich sein, Aurelia irgendwann in der Zukunft auf .NET Core zu portieren, wenn diese Technologie etwas ausgereifter ist.

Da Microsoft Blazor entwickelt, ist es jedoch weniger wahrscheinlich, dass ich persönlich etwas für .NET WASM entwickle, da ich damit in Konkurrenz zu Microsoft treten würde. Aus der Geschichte wissen wir, dass keine Open Source im .NET-Ökosystem jemals etwas bringt, wenn Microsoft beschlossen hat, etwas Ähnliches zu entwickeln, unabhängig davon, ob diese Open Source besser gestaltet, erweiterbarer, leistungsfähiger usw. ist. Ich gebe zu, dass ich hübsch bin hier abgestumpft. Das einzige, was sich wahrscheinlich ändern wird, ist, wenn Microsoft mich anstellen würde, ein .NET Core-basiertes Front-End-Framework und -Ökosystem zu leiten. Es wäre jedoch nicht Blazor. Blazor ist nicht richtig entworfen (es wiederholt .NET-Anti-Muster von vor 10 Jahren), noch ist es meiner Meinung nach ehrgeizig genug, standardkonform oder zukunftsorientiert genug. Für Microsoft steht eine größere Chance auf dem Spiel, aber das Fenster schließt sich. Ich habe versucht, verschiedene Leute bei Microsoft davon zu überzeugen, das zu akzeptieren, was sie tun könnten, aber bisher war ich erfolglos. Front-End scheint für Microsoft im Moment keine große Priorität zu haben.

@EisenbergEffect Das Problem für mich ist, dass Blazor Razor verwendet, bei dem es sich um MVC handelt. Wir brauchen eine echte MVVM, die die Leistung einer vollständigen Clr-Laufzeit aufnehmen kann. Wie Type Convention Based Templating usw. Ich habe diese Arbeit mit DuoCode und Knockout begonnen und meine Knockout.BindingConventions verwendet, um sie zusammenzukleben. Ich habe sogar Syntax wie diese funktioniert

public IEnumerable<IResult> Save()
{
    var confirm = new ConfirmResult("Proceed?");
    yield return confirm;

    if (confirm.Result == ConfirmResults.Cancel)
        yield break;

    yield return new service.SendCommand(new SaveSomethingCommand(this.something));
}

https://github.com/AndersMalmgren/Knockout.BindingConventions.DuoCode/wiki/IResult-state-machine

Knockout starb aus und mein Interesse daran. Aber der Traum lebt weiter :D

Nun, ich könnte die Arbeit wieder aufnehmen, aber mit Vue oder ähnlichem.

Vielleicht Aurelia statt Vue, da Aurelia von Durandal abstammt, die von Caliburn.Micro stammt. Außerdem hat Aurelia Konventionen, Vanilla-JS-Modelle, funktioniert besser, hat eine starke Standardkonformität und viel mehr Güte, die andere Frameworks nicht haben 😄

Es wäre jedoch nicht Blazor. Blazor ist nicht richtig entworfen (es wiederholt .NET-Anti-Muster von vor 10 Jahren), noch ist es meiner Meinung nach ehrgeizig genug, standardkonform oder zukunftsorientiert genug.

Was stimmt damit nicht?

@EisenbergEffect oder Aurelia. Ich mag Aurelia, aber da es JavaScript oder Typescript verwendet, eine Sprache zum Löschen von Typen, verlieren Sie all die süße CLR-Laufzeitmagie, die Sie tun können. Außerdem ist JavaScript DI ehrlich gesagt Mist im Vergleich zu dem, was Sie mit einer richtigen clr-Laufzeit tun können. Ich habe einen kleinen DI-Container für Duocode für das gleiche Projekt implementiert, das zuvor erwähnt wurde, und die typbasierte Injektion im Frontend ist meiner Meinung nach der richtige Weg. Ich muss mir die Modularität von Aurelia ansehen, Knockout war damals sehr erweiterbar und Vue scheint diesen Trend fortzusetzen.

@AndersMalmgren Aurelia ist heute wahrscheinlich das am besten erweiterbare Front-End-Framework. Die vNext-Implementierung, an der wir arbeiten, bringt es ebenfalls auf eine andere Ebene. Sie werden vielleicht auch überrascht sein, was wir mit unserem DI machen können :) Es ist typbasiert und hat erweiterbare Lebensdauern usw. Da JS native Klassenunterstützung bietet, gibt es keine Löschung. Wir können Schnittstellen auch mit einer DI-Hilfsmethode oder einem Vanilla JS Symbol modellieren. So kann TS diese mit TS-Schnittstellen zusammenführen und die gleichen Muster wie .NET ermöglichen. Mit anderen Worten, Sie können IAuthenticationService zur Laufzeit problemlos in eine Klasse injizieren lassen 😄 Soweit ich weiß, sind wir das einzige Framework, das dies tun kann. Ich habe versucht, möglichst viele der guten Teile von Xaml und Caliburn.Micro ins Web zu bringen, während ich die schlechten Teile hinter mir gelassen habe. So ist MVVM auch in Aurelia noch viel einfacher und leistungsfähiger. Ich werde eine Reihe von Blogbeiträgen zu Aurelia für Xaml-Entwickler und Aurelia für ASP.NET MVC-Entwickler zusammenstellen. Das könnte den Leuten helfen, die Punkte zu verbinden und zu verstehen, warum/wie es die Frontend-Entwicklung nicht nur schnell und einfach, sondern auch SOLID macht.

@manigandham Ich habe viele, viele Jahre als .NET-Entwickler, .NET-Open-Source-Leader und Microsoft MVP verbracht und Microsoft viel Feedback zu

Und für diejenigen, die mich nicht kennen, möchte ich nur hinzufügen, dass ich über all das oder eine wütende Person nicht wütend bin. Ich weiß, manchmal scheinen die Dinge ein bisschen so zu sein, wenn man mich nicht kennt und nur hier oder da meine Kommentare liest. Allerdings bin ich sehr, sehr leidenschaftlich über Front-End. Ich habe fast meine gesamte Karriere lang Front-End-Frameworks, Bibliotheken und Tools entwickelt. Es sind kurze 15 Jahre, aber es ist vergleichsweise lange, um sich auf diesen Bereich zu konzentrieren. Also, ich habe viel gesehen, viel gemacht und habe absolut starke Meinungen. Ich bin leidenschaftlich und frustriert, wenn ich sehe, dass Microsoft alte Fehler wiederholt oder Dinge tut, die ich an anderer Stelle bereits gesehen habe. Also, ich habe hier keinen bösen Willen. Ich möchte wirklich, dass Microsoft erfolgreich ist. Ich möchte, dass sie im Frontend führend sind. Ich werde einfach frustriert und ein bisschen traurig, um ehrlich zu sein, wenn ich sehe, dass das nicht passiert. Ich möchte das Beste für .NET und seine Community.

Du musst mir verzeihen, wenn ich meinen Samstag nicht damit verbringen möchte, ein 10k-Wort-Papier über die Designprobleme mit Blazor zu schreiben

Der Punkt ist, dass Sie einen Anspruch geltend gemacht haben und jemand Sie dann einfach gebeten hat, näher darauf einzugehen:

Blazor ist nicht richtig entworfen (es wiederholt .NET-Anti-Muster von vor 10 Jahren), noch ist es meiner Meinung nach ehrgeizig genug, standardkonform oder zukunftsorientiert genug.

Auf konkrete Beispiele wäre ich auch gespannt.

Und angesichts der Natur von Blazor bin ich mir nicht sicher, ob es fair ist, es mit einem durchschnittlichen Microsoft-Produkt zu vergleichen. Es _ist_ noch kein Produkt, und es wird weit mehr offen entwickelt, als es es wäre.

@chucker ich verstehe. Es ist billig von mir, so etwas zu behaupten und nicht ins Detail zu gehen. Ich freue mich, dass Sie daran interessiert sind, mehr zu erfahren.

Aus meiner Sicht ist das meiste, was ich jedoch sagen würde, Feedback, das ich Microsoft schon einmal gegeben habe, oft schon mehrmals. Obwohl es für Sie interessant wäre, bin ich mir nicht sicher, ob es für Microsoft einen Unterschied machen würde. Ich weiß nicht, ob sich etwas ändern würde.

Das heißt, ich werde versuchen, etwas zu skizzieren. Es würde jedoch zu lange dauern, einen GitHub-Kommentar einzufügen. Ich habe ein bisschen Angst vor Gegenreaktionen, wenn ich einen Blog darüber veröffentliche. Ich wurde in meiner Karriere oft von verschiedenen Gruppen gemobbt und gehasst, die nicht gerne kritisiert wurden. Während dies in letzter Zeit hauptsächlich Facebook/React-Teammitglieder waren, bin ich mir nicht sicher, ob ich mich noch einmal dafür öffnen möchte.

Vielleicht kann ich einen solchen Beitrag irgendwie so gestalten, dass er einen Unterschied macht und nicht viel negativ einlädt. Es ist ein schwieriges Spiel. Ich werde mir trotzdem ein paar Gedanken machen.

Ich kann bestätigen, dass sowohl bekanntes als auch unbekanntes Blazor in vielerlei Hinsicht nicht perfekt gestaltet ist und wir freuen uns über jedes konstruktive Feedback, um es besser zu machen. Wie unser Issue Backlog zeigt, gibt es viel zu tun! Und während Designperfektion mit ziemlicher Sicherheit schwer zu erreichen bleibt, ist es am Ende wirklich wichtig, ob Entwickler die Verwendung von Blazor als produktiv und nützlich empfinden. So viel scheint erreichbar.

@EisenbergEffect Ich natürlich über jede objektive und konstruktive Kritik oder Feedback, die Sie haben. Wie bei jeder objektiven Kritik kann ich nicht versprechen, dass sich daran etwas ändert. Ich kann nur sagen, dass wir unser Bestes tun werden, um es sorgfältig zu prüfen.

Außerdem verdient niemand gemobbt oder gehasst zu werden, und ein solches Verhalten verstößt ausdrücklich gegen unseren Verhaltenskodex .

Meiner bescheidenen Meinung nach ist Blazor bereits gelungen. In meinen 20 Jahren, in denen ich sowohl mit Microsoft- als auch mit Nicht-Microsoft-Technologien entwickelt habe, habe ich jedes Mal das gleiche Muster gesehen. Immer wenn etwas Neues herauskommt, sieht man zwei Arten von Entwicklern. Einer, der das Programmiermodell als Vehikel sieht, um irgendwohin zu kommen, und der gerne stundenlang an verschiedenen Bibliotheken herumbastelt. Ich habe versucht, mich davon zu überzeugen, dass die Verwendung all dieser verschiedenen js-Bibliotheken von all diesen verschiedenen Unternehmen mir als Entwickler mehr Mobilität und Freiheit gibt, aber bald finde ich heraus, wie sie alle in Vision, Mission und leider irgendwann Kompatibilität auseinanderdriften. Ich habe immer nach einem einheitlichen Programmiermodell gesucht und erkannt, dass strenge Konventionen nicht immer schlecht sind. Zusamenfassend. Mir liegt die Lösung am Herzen und Microsoft hat mich nie im Stich gelassen. Einige meiner besten und am häufigsten verwendeten Web-Apps werden alle auf Microsoft-Technologie erstellt und ich glaube, dass Blazor ein gutes einheitliches Programmiermodell bieten wird, das gut funktioniert, aber nicht von Hunderten anderer Bibliotheken abhängt, die zusammenarbeiten.

Meiner bescheidenen Meinung nach ist Blazor bereits gelungen. In meinen 20 Jahren, in denen ich sowohl mit Microsoft- als auch mit Nicht-Microsoft-Technologien entwickelt habe, habe ich jedes Mal das gleiche Muster gesehen. Immer wenn etwas Neues herauskommt, sieht man zwei Arten von Entwicklern. Einer, der das Programmiermodell als Vehikel sieht, um irgendwohin zu kommen, und der gerne stundenlang an verschiedenen Bibliotheken herumbastelt. Ich habe versucht, mich davon zu überzeugen, dass die Verwendung all dieser verschiedenen js-Bibliotheken von all diesen verschiedenen Unternehmen mir als Entwickler mehr Mobilität und Freiheit gibt, aber bald finde ich heraus, wie sie alle in Vision, Mission und leider irgendwann Kompatibilität auseinanderdriften. Ich habe immer nach einem einheitlichen Programmiermodell gesucht und erkannt, dass strenge Konventionen nicht immer schlecht sind. Zusamenfassend. Mir liegt die Lösung am Herzen und Microsoft hat mich nie im Stich gelassen. Einige meiner besten und am häufigsten verwendeten Web-Apps werden alle auf Microsoft-Technologie erstellt und ich glaube, dass Blazor ein gutes einheitliches Programmiermodell bieten wird, das gut funktioniert, aber nicht von Hunderten anderer Bibliotheken abhängt, die zusammenarbeiten.

Wenn Microsoft keinen Einfluss von außen nehmen würde, würden wir bei Winforms und Webforms stecken bleiben

https://devblogs.microsoft.com/dotnet/introducing-net-5/
Heute geben wir bekannt, dass die nächste Version nach .NET Core 3.0 .NET 5 sein wird. Dies wird die nächste große Version der .NET-Familie sein.

Es wird in Zukunft nur noch ein .NET geben, und Sie können es für Windows, Linux, macOS, iOS, Android, tvOS, watchOS und WebAssembly und mehr verwenden.

Als Teil von .NET 5 werden wir neue .NET-APIs, Laufzeitfunktionen und Sprachfeatures einführen.