Es ist wieder Zeit für einen neuen Release. Dabei gibt es kaum funktionale Änderungen, sondern eher ein paar technische Umstellungen, die die Weichen für die Zukunft von VidUp stellen.
Kleines Entwicklertagebuch und Hintergründe
Microsoft hat ja das .NET Framework als Entwicklungsplattform für die "einfache" Windows Entwicklung in c# und Visual Basic ins Leben gerufen, alles was man damit gebaut hat, lief nur auf Windows. In letzter Zeit ist Microsoft aber deutlich offener geworden und sie haben .NET Core als quelloffene und systemunabhängige Variante in Leben gerufen (ähnlich wie Java), Programme die damit geschrieben werden, laufen auch relativ einfach auf Linux oder Mac. In letzter Zeit war auch absehbar, dass die Lebenszeit des klassischen Frameworks begrenzt ist und MS voll auf .NET Core gehen wird, die Umstellung haben sie jetzt mit der Veröffentlichung von .NET 5 auch vollzogen. .NET 5 ist der Nachfolger von .NET Core und signalisiert mit dem neuen Namen auch, dass es das zukünftige Zugpferd ist, .NET Framework 4.8 wird die letzte Version bleiben und nur noch Sicherheits- und Maintenance Updates bekommen für eine gewisse Zeit.
VidUp basierte zuletzt auf dem .NET Framework, obwohl es als .NET Core App gestartet ist, weil damals schon klar, dass .NET Core die Zukunft ist. Ich hatte aber in .NET Core das Problem, dass sämtliche Uploads immer erst in den RAM gebuffert wurden und bei Youtube Uploads, die gerne bis zu über 100GB groß sein könne, wird das mit dem RAM eng (oder wer hat hier über 100GB RAM? :)). Außerdem fällt dann sowas wie Drosselung auch schwer, weil man die Drossel quasi nur beim Lesen der Datei ansetzen kann, wenn man den Upload nicht wirklich komplett selbst implementieren möchte. Dann wäre das Kopieren in den RAM gedrosselt, aber nicht unbedingt das Schreiben ins Netzwerk. 
Der gleiche Code wies mit dem .NET Framework ein anderes Verhalten auf, die Daten wurden sofort nach dem Lesen ins Netz geschickt. Ich hatte das Problem auch auf Stackoverflow gepostet, aber keine Antwort bekommen und deswegen aufs .NET Framework gewechselt. Vor Weihnachten hab ich aber auf mein Problem unbemerkt eine Antwort bekommen, das habe ich letzte Woche bemerkt. Und es liegt daran, dass ich auf einen veraltete HTTP Funktion gesetzt habe (HttpWebRequest) von der bekannt war, dass sie in .NET Core verbugt war. Aber Microsoft hat das nie gefixt, weil die Funktion wie gesagt veraltet ist und auch irgendwann rausfliegt, die Änderung nicht trivial ist, und es einen funktionierende Alternative in Form des HttpClients gibt. Und da jetzt wie gesagt der strategische Wechsel auf .Net 5 eh seitens MS vollzogen wurde und die ganzen Tools etc. auch nur noch dafür verbessert werden, war es zeit die HTTP-Aufrufe durch die neue Funktion zu ersetzen und wieder zurück zu .NET 5/Core zu gehen... Das war relativ zeitintensiv, weil ich die Projektdateien alle umstellen musste, schauen musste, dass die neuen Funktionen überhaupt funktionieren, wie ich sie in meinen bestehenden Code gedengelt bekomme, wie ich sowas wie die Upload Stats und die Drosselung reinbekomme, das ganze noch testen und neue Bugs fixen, die durch die Umstellung aufgetreten sind etc. etc.
Das Setup habe ich auch wieder umgestellt. Bisher habe ich die WiX Tools genutzt, die ich damals genommen hatte, weil es für .NET Core (noch) keine Setup Unterstützung von MS gab und das die offizielle Empfehlung von MS war, das hat mich aber schon immer genervt, weil es von WiX schon lange keine offiziellen Releases mehr gab und man nicht ohne weiteres prüfen kann, ob das benötigte .NET Framework installiert ist, weil es die neuen Versionen nicht kennt. Und das ist ein von MS propagiert und von MS Mitarbeitern geschaffenes Tool! Mittlerweile unterstützt das Visual Studio aber Setup Projekte für .NET 5/Core, also habe ich auch das ausgetauscht. Das MS Setup ist zwar nicht ganz so Feature mächtig, aber einfach. Da das MS Setup unterstützt z.B. nur 3stellige Versionsnummern, deswegen gibt es jetzt nur noch 3stellige Versionsnummern. 
Also kleine Updates und Bugfixes erhöhen beide die letzte Ziffer...
Ich hatte erst überlegt, ob ich daraus überhaupt einen Release machen soll, aber bevor ich funktionale Dinge im größeren Stil änder wäre es gut zu wissen, ob die technische Basis stabil läuft. Ich hatte beim Testen ein paar komische Effekte, die ich nicht lokalisieren konnte, die aber auf einmal weg sind, evtl. standen sie im Zusammenhang mit anderen Bugs, die ich gefixt habe. Zum Beispiel hatte ich einmal den Eindruck, dass er doch die Uploads erst wieder im RAM buffert und dann hochlädt. Solltet Ihr abseits von harten Fehlern also schwankende Upload Raten, nicht aktualisierende Upload Stats oder sonstige Ungereimtheiten bemerken, lasst es mich bitte wissen. Harte Fehler natürlich auch. Evtl. wäre es gut auch das Tracing einzuschalten, damit ich es besser nachvollziehen kann, falls es hakt. Ich hab jetzt einen Testupload am laufen und der scheint gut durchzulaufen, ich wünsche Euche ebenfalls viel Glück. 
Version 1.6.0 ist online: https://1drv.ms/u/s!AlNGd4g1Vh9rmHAvaCyZ5nvtOkDF?e=5vhucP
Neue Features:
- Kommunikation mit der Youtube Api neu implementiert.
- Neues Setup. Eigentlich sollte es die alte Version deinstallieren und die neue installieren, ich hoffe das klappt. =) Schaut mal in die Apps & Features Liste nach doppelten Einträgen. Oder deinstalliert vorsichtshalber manuell...
- Wird ein Upload mit Failed zurückgesetzt, geht der erst auf Stopped zurück, damit geht der Uploadfortschritt nicht verloren. Wird er nochmal zurückgesetzt, geht er auf Ready for Upload und damit ist der Upload Progress weg.
Bugfixes:
- Zur Berechnung von Veröffentlichungsdaten werden jetzt alle Uploads berücksichtigt, auch die mit Status Failed oder Paused Foxhunter
- Dateien werden jetzt wie gewollt in 40MB Paketen und nicht in 10MB Paketen hochgeladen.
Fand OBS von den Einstellungen her schon immer anstrengend...