Ich häng mich mal gerade aus dem Fenster und gebe mal meine beschränkte Sichtweise wieder.
- Ohne dass ich die Anforderungen kenne -
Das was jetzt kommt, kann auch gaaaanz anders gesehen werden - man darf mich gerne dafür rügen ;-)
Insbesondere die Framework-Frage ist religiös.
Hier ein einfacher Entscheidungsbaum:
1.
Ihr könnt C#/.NET Framework und könnt mit WPF/WinForms UIs bauen.
Ihr habt noch wage Erinnerungen an PHP-Experimente und habt gehört, dass HTML5 und Bootstrap ganz gut sein sollen.
Ihr findet Responsive Webdesign gut https://de.wikipedia.org/wiki/Responsive_Webdesign.
Der Gedanke, dass man sich mit Progressive enhancement auf das Notwendigste konzentriert und später fancy Javascript hinzunimmt gefällt euch.https://de.wikipedia.org/wiki/Progressive_Verbesserung
Eure Website ist nicht besonder dynamisch und wenn man auf eine Button auf der Website klickt, dann darf sich die Seite auch mal neuladen.
->
.NET Core (≥2) + ASP.NET Core
serverseitiges Rendern von HTML (Razor, MVC)
Bootstrap als CSS-Framework
Ihr habt es voll drauf mit JavaScript/TypeScript. OO ist euch nicht immer wichtig. Ihr scheut nicht vor "bleeding edge"-Technologien.
Eure Entwickler brauchen keine Leitplanken. Die Gefahr von big-ball-of-techo-mutt seht Ihr nicht. Gerne baut ihr eure Microservice neu.
Die Halbwertszeit eure Anwendungen ist gering. Webpack-Config schreiben rockt.
->
.NET Core (≥2) + ASP.NET Core ... oder doch lieber node.js
WebApi (RESTful oder GraphQL)
React oder Vue
PWA
Nach Remoting hätte man sicherlich WCF gesagt.
Man kann aber der Meinung sein, auch wenn man das .NET Framework verwendet, dass man das jetzt auch nicht mehr sagt.
Daher z.B. WebAPI (ASP.NET (core)) oder gRPC.
Auch wenn das oben schon gesagt wurde. Nochmal verstärkt für die Nachwelt.
Auch wenn MVVM nicht gerade einfach für Anfänger aussieht, sollten man das so nicht bauen!
Auch wenn der Code erstmal das tut was er tuen soll.
Später wird sowas die Wartungshölle!
All dein Code in Window_Loaded zu packen ist etwa so wie: Beim Hausbau die Heizungsinstallation im Vorgarten installieren zu lassen - Kann man machen, ist halt *nicht wirklich gut*
@MrSparkle: Oh ja hast ja recht :-). Das man "Serialisierung" nicht selber implementiert, wurde ja schon diskutiert. Der Rest des MSDN-Artikels wird Glowhollow sicherlich weiter bringen.
1. Erstelle ein .NET Projekt (.NET Core oder FF - ist egal)
2. Installiere dir über nuget Edge.js (https://www.nuget.org/packages/Edge.js/).
3. Installiere auf dem Rechner Node.js
4. im Projekt-Folder "npm init" und "npm install mathjax-node"
5. C#-Code (quick and dirty!):
Bezüglich "Product activation" gibt es eine Vielzahl von kommerziellen Lösungen.
Ich habe gut Erfahren mit codemeter gemacht (sowohl mit Hardware Dongle als auch mit SmartBind-"Software-Dongle"):
Nächstes Jahr frage ich nach Blazor ... aber heute ist nicht der Tag ;-)
Ich würde mal gerne von euch hören, was Ihr aktuell für Meinungen und Empfehlungen aussprecht, bezügliche der allseits beliebten Frage: "Welche Library bzw. welches Framework soll es sein? Angular, React oder Vue?"
Hier das fiktive Szenario:
Eine Horde von .NET/WPF/WinForms-Entwicklern (alle sehr erfahren) will nun mehr Web machen. Der eine oder andere hat ASP.NET- bzw. ASP.NET-Core-Erfahrung.
Auch hat der eine oder andere mal Knockout, Backbone.js, jQuery, Bootstrap ... gesehen.
Wir gehen mal davon aus, dass es eine SPA werden soll/muss.
The T:System.IO.FileStream object created by this method has a default T:System.IO.FileShare value of F:System.IO.FileShare.None; no other process or code can access the created file until the original file handle is closed.
Ja nach Lizenzmodell gibt es auch noch einen klassischen "static activation key".
Volumenlizenzversionen verwenden in diesem Fall den gleichen Key ... soviel ich weiß.
Wir haben das gerade beim Kaffee diskutiert.
Wenn es so kommt, dann finde ich das persönlich ne feine Sache.
Man kann gespannt sein, wie TFS/VSTS und GitHub verschmelzen.
Vielleicht bekommen wir dann auch private Git-Repos in GitHub für lau.
Auch wenn das BitBucket wohl unter druck setzen wird.
- Läuft der Call im STA oder im MTA?
- Wird der Call nach WPF im Main-Thread dispatched (prüf den SynchronizationContext) ?
- Ist das wirklich ein COM-Problem oder kannst du den Fehler isoliert (ohne Cobol und COM) reproduzieren?
- Nutze WinDbg und die SOS-Extension um mehr vom CallStack zu sehen