DevcouchPodcast

Jeder der in der IT arbeitet sollte sich schon mit dem Thema befasst haben.

Wir sind der Meinung - wenn du eine native Windows-Only Desktop Anwendung schreiben willst, spricht nichts gegen WPF. Theoretisch kannst du auch WinForms nutzen, aber einer der Gründe für die Existenz von WPF ist ja, dass du dort moderne UI Pattern nicht nutzen kannst und keine gute Testbarkeit hast. Maui ist Cross-Plattform - und genau wie der Ansatz von irgendwelchen Web-Technologien in Electron macht das ja auch nur Sinn wenn du wirklich mehrere Plattformen supporten willst.

Ja, ich sehe spontan 2 Optionen. * Du kannst in der Projektdatei einstellen, dass der komplette Folder als Content eingebettet wird, egal welche Dateien drin liegen. oder (kommt drauf an was du mit den Images machst): Embedde die nicht, sondern lade die Grafiken und setze sie bei der Initialisierung der Contolls/Views. Dafür muss die Build-Action aber auf Copy to Output stehen, von daher bringt das vermutlich nicht viel.

Deine Anforderungen reichen für mich nicht aus um die Frage zu beantworten. Warum muss es eine native App sein? Wird es auch eine WebApp geben? Desktop-Anwendungen? Für welche Plattformen? Womit wird das Backend erstellt und welche Programmiersprachen und Frameworks kennen die Entwickler?

Hast du den Source der Anwendung? Würde ein Export als PDF aus der Anwendung heraus nicht ausreichen?

Ich würde mir jemanden suchen der das gut kann. Dann löst du z.B. die bereits erwähnten Katas oder Dojos und lässt dir zeigen, was der andere anders gemacht hätte.

Das war bei meinem ersten Job nach der Ausbildung auch so, ich war da generell permanent komplett überfordert und wurde auch zu Kunden gesendet (ohne irgendeine Ahnung zu haben worum es geht). 20 Jahre später ist das Fazit eigentlich, dass ich das damals nicht hätte mitmachen dürfen. Zur professionellen Arbeit gehört ja auch eine offene Kommunikation. Ich würde zu meinem Vorgesetzten gehen und ganz klar und sachlich kommunizieren, wo die aktuellen Probleme liegen, und was du dir wünschen würdest um die Probleme zu lösen. Das hier zu posten löst das Problem nicht.

Schwer zu sagen ohne die genauen Anforderungen zu kennen. Ich würde erstmal alles versuchen, um keine Windows-Desktop Anwendung schreiben zu müssen. Es gibt ja mit modernen Web-Frameworks kaum noch Gründe für reine Desktop-Anwendungen. Wenn es unbedingt ein Desktop-Client sein muss, würde ich so viel Logik wie möglich in einen Backend-Service packen und den Client möglichst dumm halten. Ich würde WinForms ausschließen, weil die Testbarkeit nicht gut ist. Ich würde WPF ausschließen, weil mir persönlich MVVM nicht gefällt und ich den Aufwand, den man für schöne und moderne WPF-Anwendungen betreiben muss, für zu hoch halte. (DataBindingConverters, globalisierung, RTL Support, Storyboards - das ist unter WPF alles eine Frechheit). Xamarin.Forms für Desktop setzt auf UWP und die WPF Anbindung ist nicht gut., UWP ist raus, Maui noch nicht fertig..tja - ich weiß auch nicht.

Das ist nicht richtig. Das Produkt heißt Json.Net, der Hersteller Newtonsoft und wird aktiv weiter entwickelt. Wir haben vor ca. 3 Wochen eine neue Major-Version veröffentlicht, siehe: https://github.com/JamesNK/Newtonsoft.Json/releases Die Microsoft-Json Implementierung ist nicht Feature-Complete und hat z.B. keinen Patch Support. Microsoft selbst empfiehlt dafür Json.Net ,siehe z.B.: https://docs.microsoft.com/en-us/aspnet/core/web-api/jsonpatch?view=aspnetcore-6.0 Hier gibts eine Auflistung mit Features, die von Microsoft Json nicht supported werden: https://docs.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-migrate-from-newtonsoft-how-to?pivots=dotnet-6-0#table-of-differences-between-newtonsoftjson-and-systemtextjson Gruß, Manu