WoFloEasy: Lokaler Start vor Packaging und Lösungsvorschläge
Status: Arbeitsnotiz / Prüfcheckliste, aus Nutzerfragen abgeleitet. Keine technische Code-, Windows- oder Packaging-Prüfung in diesem Wiki-Cron-Lauf.
Quelle
- Nutzerfrage
27073, Discord, 2026-06-29T12:44:10.827000+00:00: „Mhh läuft unsere app denn jetzt lokal noch vor dem packen?“
- Nutzerfrage
27165, Discord, 2026-06-29T13:40:33.330449+00:00: Duplikat derselben Rückfrage.
- Nutzerfrage
27206, Discord, 2026-06-29T13:53:31.659000+00:00: „ok lösungsvorschläge?“
Zusammenfassung
Die neuen Fragen ergänzen den WoFloEasy-Fehlercluster um eine wichtige Reihenfolge vor dem nächsten Packaging-Schritt: Vor dem Packen/MSIX-Build sollte die App lokal im Entwicklungsmodus reproduzierbar starten und die Kernnavigation funktionieren.
Das ist dauerhaft nützlich, weil es die Grenze zwischen zwei Fehlerklassen markiert:
- App-/UI-Fehler: Die App crasht bereits lokal, z. B. durch Dashboard-Initialisierung, fehlende Services, Nullwerte, Migration/Seed-Daten oder Menü-/Routing-Regression.
- Packaging-/Installationsfehler: Die App läuft lokal, startet aber nach MSIX/AppInstaller-Installation nicht oder anders, z. B. wegen Manifest, Signatur, Capabilities, Pfaden, Dependencies oder Startkontext.
Solange der lokale Entwicklungsstart nicht sauber bestätigt ist, sollte Packaging nicht als Hauptursache angenommen werden. Erst wenn lokal ein Smoke-Test grün ist, lohnt sich die isolierte Analyse des MSIX/AppInstaller-Pfads.
Validierung
Aus den Nutzerfragen sicher ableitbar:
- Es besteht Unsicherheit, ob WoFloEasy aktuell lokal vor dem Packen noch läuft.
- Die Frage wurde wiederholt und anschließend wurden Lösungsvorschläge angefragt.
- Der Kontext überschneidet sich mit dem bereits dokumentierten Dashboard-Crash, der fehlenden Menü-Wiederherstellung und dem MSIX/AppInstaller-Startproblem.
Nicht validiert in diesem Cron-Lauf:
- Ob ein lokaler Entwicklungsstart tatsächlich fehlschlägt.
- Ob der Dashboard-Crash lokal, nur installiert oder in beiden Modi auftritt.
- Ob bereits ein Fix im Code existiert, der nur noch gebaut/installiert werden muss.
- Welche konkrete Technologie-/Startkette aktuell verwendet wird (z. B. Visual Studio, dotnet, WinUI/WPF/MAUI, MSIX-Projekt).
Lösungsvorschläge / Prüfreihenfolge
-
Packaging stoppen, zuerst lokalen Smoke-Test herstellen
- App im Entwicklungsmodus starten.
- Mindesttest: Startfenster öffnet, Dashboard lässt sich aufrufen, Menü ist sichtbar, alle Hauptpunkte sind anklickbar.
- Ergebnis mit Datum/Build-Stand notieren.
-
Dashboard-Crash isolieren
- App ohne Dashboard-Autoload bzw. mit sicherer Fallback-Startseite starten, falls möglich.
- Dashboard-Datenquellen prüfen: KW/Jahr-Auswahl, fehlende Aufträge/Kunden, leere Listen, Nullwerte, ungültige Default-Auswahl.
- Exception/Stacktrace aus Entwicklungsstart oder Windows-Logs sichern.
-
Menü-/Navigation-Regression getrennt prüfen
- Erwartete Hauptpunkte gegen den aktuellen UI-Stand abgleichen: Dashboard, Regieberichte, Arbeitszeiten, Material, Wochenberichte, Export/Sync, Einstellungen.
- Prüfen, ob das Menü nur visuell fehlt oder ob Routing/ViewModels/Commands nicht registriert sind.
-
Erst danach MSIX/AppInstaller prüfen
- Wenn lokal grün: identischen Build packen und Installation testen.
- Manifest, Signierung, Dependencies, AppInstaller-URL und Startlogs prüfen.
- Abweichungen zwischen Entwicklungs- und Installationskontext dokumentieren.
-
Smoke-Test als Pack-Gate festlegen
- Kein neues Paket veröffentlichen, solange der lokale Smoke-Test nicht bestanden ist.
- Nach jedem Fix: lokale App starten, Dashboard öffnen, Menü prüfen, dann erst packen.
Offene Punkte
- Lokalen Entwicklungsstart von WoFloEasy konkret prüfen und Ergebnis dokumentieren.
- Klären, ob Dashboard-Crash lokal oder nur nach Installation auftritt.
- Menü-Wiederherstellung gegen erwartete Navigation abgleichen.
- Falls lokal grün, MSIX/AppInstaller-Problem isoliert weiterverfolgen.
- Offene technische Details später gegen Code/Windows-Logs validieren.
Verknüpfungen