Da muss ich dir absolut recht geben. Ich habs nie wirklich gesagt und habe es wohl tatsächlich falsch angegangen - das war mein Fehler und in dem Fall dann auch nicht eurer bzw. deiner - immerhin habe ich die kommerzielle Nutzung innerhalb der Lizenzbestimmungen ausdrücklich erlaubt.
Deine Unterstützung beispielsweise hat mir sehr geholfen und da bin ich nach wie vor sehr dankbar.
Somit mache ich von der Seite her auch niemandem einen Vorwurf. Ich muss es wohl auch mehr auf die Zeit schieben nachdem ich angekündigt hatte dass ich das Projekt gerne kommerzialisieren möchte. Da kamen teilweis schon sehr unverschämte E-Mails und vermutlich war es auch dass das mir dann erst die Lust verdorben hat 😦 Immerhin wurde mir mehrmals doch schon klar zugetragen dass zwar reges Interesse besteht das Programm zu nutzen aber nur noch wenn ich die alte Version fertig mache oder möglichst diese dann OpenSource mache und nur die neue Version unter dem Namen AppDater verkaufe.
Das kann ich aber tatsächlich nicht auf alle hier verallgemeinern und somit sollen sich auch nicht alle angesprochen fühlen.
Zunächst erst einmal vielen Dank an alle die das Projekt toll fanden - wenngleich es immernoch traurig finde dass ein Projekt dass man rege genutzt und "gemocht" wird so wenig unterstützt wird. Aber das ist ja ein anders Thema.
Zum Thema Quellcode freigeben:
Leider kollidiert das mit meiner Abneigung gegen OpenSource 😃 Ich weiß nicht ob ihr das nachvollziehen könnt - ich habe das Projekt unter anderem wegen dieser "Im Internet ist alles kostenlos"-Mentalität eingestellt. Es ist niemand mehr bereit für Arbeit Geld auszugeben und das habe ich anhand diesen Projekt sehr deutlich zu spüren bekommen. Gebe ich nun noch die Sourcen frei so kommt es mir noch viel mehr wie ein "verschenken" meiner Arbeit vor. Aber das ist nur meine persönliche Haltung zu diesem Thema, dass ich eine Abneigung habe diese Jahrelange Arbeit einfach zu verschenken. Ich dachte dass diese Leistung die ich erbracht habe irgendwem wenigstens 5€ wert gewesen wären so dass ich mir für das Opfern meiner Freizeit mal Abends ein Bier leisten kann - war es aber nicht, also sehe ich auch nicht wirklich ein weshalb ich es dann gleich verschenken sollte. Ich habe das Programm hauptsächlich während meiner Ausbildungszeit entwickelt und gerade da hat mir vorn und hinten das Geld gefehlt. Ich habe wirklich gedacht durch solch einen Einsatz etwas schaffen kann dass mir hier und da einen Obulus einbringt - manch einer nutzt es ja sogar innerhalb von Firmen und verdient indirekt damit Geld). Immerhin habe ich für das Projekt mein USBSynC geopfert und hatte selbst überhaupt keinen Nutzen vom AppDater - maximal um den AppDater selbst durch dich Komponenten zu aktualisieren. Offenbar war ich doch etwas zu naiv 😃
Auch wenn ich die Sourcen freigeben wollte - so ginge das gar nicht. Wie ich schon mehrere Male auf die Anfragen nach OpenSource geschrieben habe, nutze ich diverse kommerzielle Komponenten. Unter anderem edtFTPnet/PRO und SmartInspect. Ihr könnte ja mal danach googeln und euch anschauen was die Teile kosten. Um nun den AppDater OpenSource zu machen, müssten auch diese Komponenten ersetzt werden. Und das Program wird ohne FTP-Anbindung nicht wirklich funktionieren 😃
Na ja nun - so siehts derzeit leider aus.
Ich möchte euch nur mal darüber informieren dass ich den AppDater nun endgültig einstellen werde.
Ich dachte ich würde die Motivation das Projekt weiterzuführen nochmals aufleben lassen - und kurzfristig ist das auch geglückt. Die Tatsache wieviel Zeit dieses Projekt schluckt macht es mir jedoch schlicht und ergreifend unmöglich weiterzuarbeiten.
Erschwerend kommt die Tatsache hinzu dass ich kein Interesse mehr daran habe täglich meine Zeit mit einem Projekt zu verbringen das mir selbst nichts mehr bringt (sei es "Erfahrung" oder einfach nur eine gewisse Anerkennung in Form einer kleinen Spende oder dergleichen die schon lange nicht mehr kam und überhaupt nur 2-3 Mal stattgefunden hat).
Ich werde meine Freizeit in Zukunft Projekten widmen die mir Spaß machen und von denen ich selbst auch noch einen Nutzen habe.
Grundsätzlich tut es mir selbst Leid da ich sehr stolz auf das Projekt bin. Wirklich motivieren konnten mich "Beschwerde E-Mails" wieso dies und das denn nicht funktionieren würde und "Anforderungs E-Mails" mit O-Ton: "Ich hätte da noch eine Aufgabe für dich" überhaupt nicht - ich denke das können einige hier verstehen. Immerhin bin ich nicht der Auftragsprogrammierer der für kein Geld alles macht...
Es gibt ja wie ich gesehen habe im Forum mittlerweile ein zweites Updateprojekt. Ich bin gespannt wie lange der Entwickler Motivation aufbringen kann den Benutzern die Wünsche von den Lippen abzulesen nur dass diese dann die Software kostenlos in den Firmen einsetzen können. Sprich: Die Benutzer verdienen Geld - der Entwickler keins. Verdrehte Welt...
Denen die diese Software noch weiter verwenden wünsche ich dass alles glatt läuft.
Also den Pfad gibst du nicht in der Gui sondern schon in der Applikation selbst an - so wie du es richtig verstanden hast.
Ich dachte jetzt nur gerade dass der Temp-Pfad dann ja eventuell immer identisch ist. Wenn du jedoch immer eine neue Guid erzeugst ist dieser Pfad bei jedem Updatevorgang unterschiedlich und macht dann auch keine Probleme.
Gegen einen Netzwerkpfad würde nichts sprechen, werde das aber erst testen müssen.
Ja die Problematik mit dem fehlenden Benutzerkonto hattest du angesprochen. Ich denke mit den drei Möglichkeiten die ich dann biete sollte sich jedes Problem lösen lassen und somit auch genug sein.
Die Logik beim Löschen ist folgende:
Es werden alle Dateien gelöscht die beim Updatevorgang angelegt wurden. Ist nach dem Löschen der Ordner leer (was normalerweise der Fall ist), wird der komplette Ordner gelöscht - aber auch nur dann. Damit wirke ich einer eventuellen Fehleinstellung entgegen. Man nehme mal an der Entwickler gibt als Benutzer-Temp-Pfad ausversehen C:\Windows an oder einen Ordner in dem sich noch wichtige andere Dateien befinden. Dann würde der Ordner bestehen bleiben.
Läuft jedoch alles Reibungslos wird der Ordner wieder komplett gelöscht.
Ein Problem sehe ich allerdings dann wenn du bei 400PCs immer den Ordner \server$_936DA01F-9ABD-4d9d-80C7-02AF85C822A8 verwendest. Würden nun zwei PCs gleichzeitig ein Update durchführen würde ja vllt der eine Prozess dem anderen die Ordner weglöschen. Vllt könnte man hierbei überlegen ob das Temp-Verzeichnis als Wunsch nur als übergeordneter Ordner angesehen wird und darin dann das eigentliche Temp-Verzeichnis angelegt wird dass dann wieder gelöscht werden kann. Somit würde der Ordner zwar immer bestehen bleiben, wäre aber im Idealfall immer leer. Allerdings wäre das schon wieder eine Einstellung.
@Jelly: Habe nun das ganze WE mit Überlegungen und Recherchen verbracht und denke eine geeignete Lösung gefunden zu haben die ich auch schon weitestgehend umgesetzt habe.
Das AppDater-Objekt hat nun ein neues Flag "TempDirLocation" dessen 3 mögliche Werte die folgenden sind:
- LoggedOnUserTemp: Das Temp-Verzeichnis des angemeldeten Benutzers wird zum Download der Dateien verwendet (Vorgehensweise wie bisher, diese Einstellung wird auch Standard sein)
- DriveC: Ein Verzeichnis der Form C:$_936DA01F-9ABD-4d9d-80C7-02AF85C822A8 wird verwendet. Dabei ist dann sichergestellt dass beim Ausführen eines Updates unter einem anderen Benutzer auch tatsächlich ins Temp-Verzeichnis geschrieben werden kann
- UserSpecified: Verwende ein benutzerdefiniertes Verzeichnis
Das Problem dass du beschrieben hast, dass der Benutzer unter dem das Update durchgeführt werden kann nicht ins Verzeichnis des Benutzers schreiben kann der das Update veranlasst hat konnte ich nachstellen und durch Variante "DriveC" lösen.
An dieser Stelle wäre auch denkbar sich direkt in der DLL noch vor dem Aufruf der updater.exe per Impersonation am Konto des Benutzers anzumelden der das Update durchführen soll und in dessen Temp-Ordner zu schreiben. Eventuell füge ich diese Funktion dann später noch hinzu.
Auch habe ich nun die Einstellmöglichkeiten unter "Rechte" geändert. Bisher war es ja nur möglich entweder Adminrechte zu fordern oder ein anderes Benutzerkonto zu verwenden. Allerdings ist das ja quatsch. Denn das eine schließt das andere ja nicht aus. Somit stehen nun 4 Szenarien zur Verfügung unter denen ein Update durchgeführt wird
- Angemeldeter Benutzer, keine Adminrechte
- Angemeldeter Benutzer, Adminrechte
- Anderes Benutzerkonto, keine Adminrechte
- Anderes Benutzerkonto, Adminrechte
Die ersten Tests liefen eben erfolgreich. Nun schreibe ich noch die Routine die die Tempordner auch wieder löscht und dann gibts den nächsten Build.
Ein Szenario bereitet noch Probleme bei benötigten Adminrechten: Sollte ein Update unter dem angemeldeten Benutzer durchgeführt werden und auf Fehler auflaufen und will man dann während dem Update "händisch" das Benutzerkonto wechseln, so können noch keine Adminrechte angefordert werden.
@Zony: Deine Datei habe ich erhalten - vielen Dank. Jedoch kam ich heute noch nicht dazu das Problem zu lösen. Tatsächich erkennt die Routine die beiden identischen Versionsnummern und wählt dann dennoch das Update aus - also hat sih da irgendwo ein Fehler eingeschlichen.
Update: Habe gestern noch ne Weile dran gesessen und das Löschen der Temp-Dateien korrigiert. Nach einem Update werden sämtliche temporäre die angelegt wurden wieder gelöscht. Ein weiteres neues Flag "DeleteTempFilesAfterUpdate" dass standardmäßig auf "true" steht ermöglicht zu Debugzwecken das Löschen zu deaktiveren.
Schick mir sowas ruhig zu: webmaster@klausmoster.de
Für jeden Updatevorgang wird tatsächlich ein neuer Temp-Ordner angelegt.
Es steht zwar schon länger auf meiner Roadmap die Beschreibbarkeit zu prüfen - wurde aber nie wirklich akut wichtig. Jetzt wäre ein guter Anlass dass alles nochmals zu überdenken. Im Grunde lasse ich mir jede Temp-Datei vom System selbst anfordern Path.GetTemp (oder so ähnlich). Aber an dieser Stelle läuft das noch ziemlich altertümlich und händisch ab - werde ich mir direkt anschauen.
Zur Impersonifikation habe ich gestern Abend noch eine Einstellmöglichkeit ergänzt die es ermöglicht ein Update schon von vornherein unter dem gewünschten Benutzer durchzuführen - das aber nur nebenbei.
Deine Kritik nehme ich ganz und gar nicht persönlich sondern als das was es ist: Konstruktive Kritik. Da du selbst in dieser Branche tätig bist weißt du selbst vermutlich nur zu gut dass es Szenarien gibt an die man gar nicht denkt - somit bin ich unheimlich auf konstruktives Feedback angewiesen - an dieser Stelle also ein Dankeschön dafür 😃
Für mich würde das also bedeuten auch diese Tempordner vom System anfordern zu lassen - ggf. werde ich auch die Pfade ändern und es so machen wie es Microsoft selbst macht: C:$blabla verwenden und anschließend wieder sauber weglöschen - da recherchiere ich mal ein wenig was der Königsweg ist und ob Microsoft was im Styleguide zu solchen Problemen stehen hat.
Ich lese mich zudem auch gerade ins ShadowCopying ein um echtes Updaten im Hintergrund zu ermöglichen. Ich denke das wäre ein durchaus interessantes Feature wenn das System bzw. die Applikation im Betrieb geupdated werden können und beim nächsten Rechnerstart dann die neuen Versionen zur Verfügung stehen.
@Zony: Ab dem nächsten Build wird die Datei im Ordner preBeta/AppDater erzeugt. Von welchem Changelog-Fenster genau sprichst du?
@Jelly: Das Property ist umgesetzt und kommt in den nächsten Build - denke heute Abend. Werde mir dann die Geschichte mit dem Benutzerwechsel nochmal genauer ansehen. Normaler sollten alle Dateien die gelöscht werden auch gesichert werden, dass geschieht allerdings in einem Temp-Ordner - vllt läuft da aber auch etwas schief. Den Rollback-Mechanismus muss ich sowieso nochmal überarbeiten.
@Lumbra: Ja der Text hängt überall rechts raus, darum gehts aber nicht - er meint die Buttons die überall raushängen.
@Zony: Ja das ist unschön - das korrigiere ich dann.