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:

1. 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 😃

2. 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:

1. LoggedOnUserTemp: Das Temp-Verzeichnis des angemeldeten Benutzers wird zum Download der Dateien verwendet (Vorgehensweise wie bisher, diese Einstellung wird auch Standard sein)
2. 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
3. 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

1. Angemeldeter Benutzer, keine Adminrechte
2. Angemeldeter Benutzer, Adminrechte
3. Anderes Benutzerkonto, keine Adminrechte
4. 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.

OK - aber dann stellt dein Skin den du ausgewählt hast irgendwas um - die Auflösung müsste egal sein. Werde aber mal schauen dass ich das - zumindest mal für ein paar Fenster - in den Griff bekomme. Ist immer ein wenig verzwickt wo dann welche Anker gesetzt werden müssen damit das dann passt.

Welchen Skin hast du drauf? Dann kann ich das vllt in einer VM nachstellen.

@DeadEye: merci 😃 Die Statistik will ich um genau den Punkt sowieso erweitern. Customparameter sind eine gute Idee, werde mir da mal überlegen.

@Lumbra: Ich seh gerade dass da wohl das beim Obfuscating schief gelaufen ist. Normal sollte es bei "DataTypes.ProxyType" neben "Http" und "NoProxy" noch den Punkt "UseInternetExplorerSettings" geben. Leider wurde der jetzt beim Obfuscating in "a" umbenannt 😃

Sollte aber dennoch möglich sein das auszuwählen. Was nun passiert ist das dann ganz einfach nach den Einstellungen gesucht werden die im Internet Explorer (und somit im System) eingestellt sind. Das betrifft in diesem Build aber nur Proxyadresse und Port. Die automatische Verwendung einer eventuell angegebenen PAC-Datei wird im nächsten Build verfügbar sein. Leider kann ich gerade die Proxygeschichte nur sehr eingeschränkt testen und wäre dann sehr auf euer Feedback angewiesen 😃

Ah stimmt - sorry - das ist total untergegangen.
Also der Updatevorgang wird nicht einfach abgebrochen sondern Rückgängig gemacht - sprich: ersetzte Dateien werden wieder zurückgeschrieben (dafür wird vorher ein Backup aller Dateien angelegt).

Die Möglichkeit den Updateprozess abzubrechen bzw. das Abbrechen zu unterbinden werde ich für den nächsten Build als Property einbauen - danke für die Erinnerung.

Zudem möchte ich noch ein weiteres Property bzw. eine weitere Einstellmöglichkeit hinzufügen dass die Impersonifikation betrifft. Und zwar würde diese Einstellung erlauben einzustellen dass nicht nur im Fehlerfall versucht wird das Konto zu wechseln sondern immer gewechselt wird und das Update komplett unter dem angegebenen Benutzer durchgeführt wird.

P.S.: Seit gestern habe ich einen neuen Build draußen - einfach mal AutoUpdate anwerfen oder herunterladen.

Änderungen: klick
Download: klick

Im ersten Beitrag werde ich nun immer die aktuelle Version + die wichtigsten Links angeben.

Erst einmal Danke fürs Lob 😃

Ich schätze du hast die dpi-Zahl verändert oder? Bzw. Schriftgröße auf "groß" geändert.

Thx für den Hinweis. Sollte ich mal drüber nachdenken - wäre sicherlich ein wünschenswertes Feature.

Eigentlich nichts - nur wenn du noch die leeren Stellen entfernen willst wird ein Eintrag zur CSS-Datei gemacht.

Ich würde das gerne als Plugin machen, aber Plugins für Opera zu schreiben ist ein Ding der Unmöglichkeit. Mit C ist das gemacht und sau kompliziert - deswegen gibts bisher auch noch keins 😃

Mmh ich hab mit der Fehlerkonsole noch keine Probleme gehabt. Zumindest poppt sie bei mir nicht automatisch auf.

Schau mal bei "Extras", "Einstellungen", "Erweitert", "Inhalte", "JavaScript-Optionen" und dann "Bei Fehlern die Fehlerkonsole anzeigen". Wenn da der Haken ist erscheint sie - also einfach raus machen.

Gestern habe ich Version 1.3.0 veröffentlich: klick

Opera 10 wird unterstützt und auch der Proxy sollte funktionieren.

Kannst du mir da eventuell die Logdatei dazu schicken die während dem Update erzeugt wurde? Weiter oben ist beschrieben wie man die Erzeugen lässt. Dann einfach an webmaster@klausmoster.de.

Derzeit funktioniert der Proxy nur wenn du direkt bei den AppDater-Einstellungen den Proxyport und ggf. Username und Password angibst. Die die pac-Datei bzw. die IE-Einstellungen werden noch nicht übernommen.

Ich bin aber derzeit dabei genau dass umzusetzen. Es würde dann ein Flage "UseIESettings" oder ähnlich geben und dein Problem sollte sich damit erledigen.

@Jelly: Führt er das Update erst gar nicht durch oder nur unter dem falschen Benutzerkonto. Derzeit ist die Logik die, dass der Updater versucht die Dateien auszutauschen und erst wenn eine Aktion (Löschen oder Kopieren) fehlschlägt es nochmals mit dem angegebenen Benutzerkonto versucht.
Das andere muss ich mal prüfen.

@ymarviny: Das könnte durchaus hilfreich sein 😃 Ich mach auch nix kaputt.

Wenn ich dich richtig verstanden habe verwendest du einen MS-SQL und keinen MySQL-Server? Den MSSQL-Server habe ich bisher nicht getestet und unterstütze ich im Moment auch nicht. Somit wird dir dann nichts anderes übrig bleiben als dateibasiertes Logging zu verwenden wobei das bei Windows-Servern noch Probleme macht. Ich arbeite da aber gerade dabei. Allerdings wirst du dann das Projekt ganz normal aufsetzen können - nur eben wird das Logging wohl nicht richtig klappen.

Werft mal die Updatesuche an, ich hab einen neuen Build draußen. Der sollte die oben beschrieben Fehler erstmal alle beheben.

Changelog hier: Klick

Leider hat sich ein Fehler in der Administrationsoberfläche breit gemacht. Durch einen Fehler beim Obfuscation wird in die Updatedatei beim Erzeugen eines Updates nicht "final" sondern "c" geschrieben.
Ich sitze gerade dabei den Fehler zu lösen und hoffe schnellstmöglichst ein Update Bereit zu stellen.

Derweil könnte ihr die updates.xml vom FTP-Server laden und dort im Tag <releasestatus> und dort in <status> das c in „final“ ändern. Laded die Datei anschließend wieder hoch und das Update müsste durchlaufen.

Aktiviere bitte mal das Logging in der DLL.
Das macht du in dem du bei den Updateeinstellungen folgendes angibst:

LogFolderPath = System.Environment.GetFolderPath(Environment.SpecialFolder.Desktop)

Es würde dann auf dem Desktop eine Datei "appdater.sil" erzeugt weden. Schick mir die bitte mal zu. Vllt seh ich woran es liegt.

@Lumbra: du scheinst noch die alte Dll zu verwenden? Schau mal im AppDater-Installationsverzeichnis und dort im Ordner Lib nach. Dort liegt die aktuelle Dll.

Leider bin ich mit dem neuen Wiki noch nicht ganz durch, deswegen stimmt die Anleitung an dieser Stelle nicht mehr. So wie es Zony beschrieben hat ist es richtig. So müsste es bei dir funktionieren.

Du kannst mir mal die Logs zuschicken. Unter "Einstellungen" kannst du den Pfad zu den Logs öffnen, dort gibt es einen SmartInspect-Ordner. Such mal die Logs raus die in dem Zeitraum angelegt wurden - oder lösche einfach alle raus und starte das ganz neu - dann wird eine neue angelegt. Die könntest du mir dann zusenden. Eventuell kann ich da was sehen.

Du meinst nun mit Bearbeiten wenn du auf "Bearbeiten" klickst oder scheitert schon das Laden des Projektes?

Und das ist auch gut wenn zum Testen alles angeklickt wird 😃
Dass sich der Ordnername ändert habe ich für Beta2 schon geplant. Wollte es dann nicht mehr in Beta1 aufnehmen dass ich irgendwann mal fertig werde g

@Zony: "Übernehmen" musst du nicht anklicken - das ist ein Fehler dass der Button noch da ist - einfach auf Weiter oder Fertig stellen klicken und dann müsste es funktionieren.

Dass die Versionsanzeige nicht sofort aktualisiert wird habe ich direkt notiert 😃

@V4yd: Das kannst du im Moment für dich selbst entscheiden. Der AppDater ist zum K_Updater kompatibel. Das heißt die Applikationen die du ausgeliefert hast können sich auch dann aktualisieren wenn du bereits den AppDater verwendest. Als "wichtig" sehe ich die Vista-Kompatibilität an. Ansonsten gibt es soweit also noch keinen zwingenden Grund sofort zu wechseln.

Ich habe soeben die Beta 1 vom neuen AppDater veröffentlicht.
Heruntergeladen werden kann sie hier: klick

Ich hoffe es läuft soweit alles reibungslos und es sind keine groberen Schnitzer drin. Ich verfolge nun das Ziel alle zwei Wochen ein neues Beta-Release herauszubringen und ggf. in unregelmäßigem Abstand große Fehler schnell zu fixen.

Dann darf getestet werden und ich bin auf das Feedback gespannt.

Es gibt nun erste Lebenszeichen von der Beta-Version 😃
Habe gestern die neue Homepage begonnen einzurichten und irgendwann im Laufe dieser Woche wird sich dort dann wohl auch die Beta wiederfinden.

http://www.prebeta.info

Version 1.2.0 hab ich nun veröffentlich.
Es können nun alle installierten Operas konfiguriert werden + Opera@USB.

Für alle die meinen Blog nicht lesen:

Ich bin derzeit damit beschäftigt die Beta vorzubereiten. Sprich: ich bin soweit durch und kontrolliere den reibungslosen Ablauf der Applikation vor allem beim Umstieg von K_Updater auf AppDater (wie das Projekt in Zukunft heißen wird).

Genaueres hier: Klick

Ich bin also guter Dinge die Tage (vllt Ende der Woche / Anfang nächster Woche) die Beta zu veröffentlichen und euch endlich testen zu lassen 😃

Update:
Ich arbeite gerade das letzte Feature zu Ende für die Beta1. Man kann nun seinem Update einen Releasestatus zuweisen: Alpha, Beta, Final. Sollte man Alpha oder Beta verwenden kann man zusätzlich den Step (für Alpha1, Alpha2, ...) und einen Codenamen vergeben wenn man möchte.

Sobald ich dieses Feature dann fertig habe (heute oder morgen) bereite ich die Beta vor. Sieht also so aus als obs diese Woche dann endlich was wird 😃

@Sun: Kann dich durchaus verstehen. Mach mir ruhig Dampf. Ich sitze auch permanent am Entwickeln. Die neue Projektstruktur (sprich dass in Ordner gespeichert wird) ist fertig und ich räume das Projekt noch auf und beseitige letzte Fehler.

Derzeit bin ich an den Wochenenden häuftig nicht daheim und kann so leider nur eingeschränkt arbeiten. Für die Zukunft möchte ich dem aber durch die Anschaffung eines Laptops entgegenwirken (laut Dell sollte es am 3. da sein).

Mich freut es dass ihr das Projekt trotz der langen Pause immer noch verwendet. nach wie vor gilt allerdings dass die nächste Version dann bald kommt (ich peile wieder Ende dieser Woche an). Ich hoffe diesmal mein Versprechen halten zu können.

OpenSource kommt für mich aus mehreren Gründen nicht in Frage. Das betrifft zum Einen meine generelle Einstellung zu OpenSource die ich jetzt aber nicht weiter ausführen möchte. Zum anderen habe ich im Updater jetzt drei kommerzielle Komponenten drin. Somit scheitert daran schon die OpenSource-Umsetzung.

Generell soll das nie wieder passieren dass dann soviel Zeit zwischen den Versionen ist. Ich hatte zu dieser Version wirklich eine taktisch fatale Entscheidung getroffen. Ich wollte möglichst viele neue Features in diese Version packen. Statt somit monatlich ein Update liefern zu können kämpfe ich nun immernoch mit den Folgen, war die Applikation doch stellenweise eine große Baustelle 😃

Ich hoffe ihr bleibt mir erst einmal treu.

Eventuell kann ich dir nächste Woche auch einfach einen Schnappschuss zusenden, denn die DLL und die updater.exe sind fertig. Lediglich an der Admin-Oberfläche bastle ich noch. Das heißt theoretisch kannst du die neuen Funktionen sogar schon benutzen. Mir wird da was einfallen.

Dann ist ja die gute Nachricht zunächst dass beides funktioniert mit der nächsten Version. Ich glaube fest daran, dass ich die nächste Version Ende nächster Woche soweit fertig haben müsste dass man sie testen kann. Bin zwar nun erst einmal ein paar Tage im Urlaub, aber Laptop und Motivation sind dabei 😃

Absolut richtig. Ich will nun auch nichts neues mehr reinpacken. Ich arbeite noch an der neuen Projektverwaltung. Die ist aber so gut wie durch. Sobald dieser Teil dann abgeschlossen ist gibts ne neue Version. Ich hätte die neue Projektverwaltung wohl nicht mehr in die 1.4er reinnehmen sollen. Dann könnte ich jetzt schon was veröffentlichen. Da ich aber mit der 1.4er den Namen ändern möchte wollte ich das noch komplett haben.

Das ist schonmal gut, denn mindestens das hatte ich auch vor. Ich dachte mir zudem ob man bei Projekterstellung aber nicht einen Projektordner angeben sollte, standardmäßig ein Eigene Dateien\AppDater oder so. Dort könnte der AppDater zumindest die Projekteinstellungen ablegen. Das hätte nun diesen Vorteil, dass nach einer Neuinstallation zumindest die Projektdaten alle wieder da sind und man die Einstellungen auch über SugarSync, DropBox oder dergleichen syncen könnte. Das eine schließt ja nun aber das andere nicht aus.

@Hallo T_B__: der Fehler ist bereits korrigiert, wird also in 1.4.0 nicht mehr auftreten. Aber danke dass du deinen "freundlichen" Tonfall editiert hast...

Ich hätte da mal eine Frage: ich überlege gerade ob es Sinn macht so eine Art "Projektmappe" oder sowas anzulegen. Sprich: ein zentraler Ort an dem die Dateien verwaltet werden. Bisher wird ja immer nur auf die Dateien referenziert.

Da könnte man also einen Ordner anlegen und sobald man eine Datei hinzufügt wird sie dorthin kopiert. Na ja so irgendwie. Der Vorteil wäre dann dass ich einen Ort hätte an dem ich auch die Dateien wieder aus dem Updatepaket herausextrahieren könnte. Sprich: man löscht die Datei ausversehen lokal, geht in die Updatepaket-Verwaltung und zack kann man nichts mehr editieren weil die Datei lokal nicht mehr vorhanden ist. Hätte ich einen zenatralen Speicherort auf der Platte, also sowas wie Eigene Dateien\AppDater, so könnte sich der AppDater diese Dateien bei Bedarf einfach wieder vom FTP holen.

Mir ist da bisher noch nichts gescheites eingefallen, deswegen würde mich mal interessieren wie ihr eure Updatepakete verwaltet. Könnt ihr auch gerne als PM an mich schicken.

Die Variante dass es Updatepakete gibt hat den Grund, das ein Update oft nicht nur aus Dateien besteht, sondern auch aus Diensten die gestartet, beendet werden müssen - eventuell auch Registry-Keys. Ein striktes versionieren der Updates ist so viel sinnvoller.

Aber wie gesagt möchte ich den anderen Mechanismus wieder drin haben, so das man für einzelne Dateien sagen kann: "such immer die neueste Version der Datei und lade sie" - ohne auf die Versionen achten zu müssen.

So war das ganz früher mal, da hab ich einfach einen Hash über alle Dateien gemacht. Das hatte aber genau den Nachteil, das man wirklich immer nur "einen" aktuellen Stand auf dem Server hatte auf den das Programm aktualisiert hat. Klar war es dann sehr einfach möglich einzelne Dateien wir Plugins zu aktualisieren. Aber mehrere Updates parallel anzubieten war eben nicht möglich.

Ich werde aber genau dieses Verfahren wieder einsetzen wenn man einzelne Dateien aktuell halten will.
Es ist soweit aber schon richtig, das es sinnvoll ist entweder nur inkrementell zu arbeiten oder gleich immer "für alle".

Aber da kommt es immer auf den jeweiligen Anwendungsfall an.

Ah jetzt weiß ich was du ansprichst. Du meinst du hättest 3 Updatepakete:

1.1.0
1.2.0
1.3.0

und jeweils alle auf "für alle". Nun vermutest du der Update sucht sich automatisch die "nächst höhere" heraus, also wenn Programmversion = 1.0.0 dann kommt 1.10.
Wenn Programmversion = 1.2.0, dann kommt 1.3.0.

Mmh so ist die Logik derzeit nicht umgesetzt. Ich glaube aber so funktioniert es sogar - aber nur durch Zufall. Derzeit nimmt er einfach "das nächste" das er findet. Hast du deine Updatepakete zufällig in der Reihenfolge wie oben angelegt würde das auch passen. Aber hättest du ind er Liste erst 1.3.0, dann 1.2.0 und dann 1.1.0 würde er glaub ich zuerst 1.3.0 ziehen.

Da muss ich wohl nochmal ran und das überprüfen.

Das würde nicht wirklich Sinn machen.

Grund ist der: du hast nun 2 Programmversionen im Umlauf:

1.0.0
1.1.0

Nun willst du die Version 1.2.0 raushauen und die würdest du dann "für alle" machen.
Das wäre soweit ja ok. Würdest du nun aber inkrementelle Updates machen, also jeweils nur die Dateien reinpacken die sich von Version zu Version geändert haben, so müsste ja 1.0.0 erstmal auf 1.1.0 updates. Somit machst du ein Updatepaket für 1.1.0 und stellst ein "für Version 1.0.0". Somit ist sichergestellt, dass die Version 1.0.0 nicht direkt 1.2.0 zieht, sondern erstmal 1.1.0.

Gleiches gilt natürlich auch wenn du eine bestimmte ältere Version ersteinmal "vorbereiten" willst.

Beispiel: du hast 2 Versionen draußen:

1.0.0
2.0.0

Und nun machst du die Version 2.1.0. Du weißt nun dass das Update nur dann korrekt läuft, wenn wenigstens Version 2.0.0 aufgespielt ist. Du machst also ein Updatepaket für 2.1.0 mit "für alle", oder meinetwegen auch "ab 2.0.0" und ein Updatepaket auf Version 2.0.0 und stellst ein "für Version 1.0.0". Somit ist sichergestellt, dass Benutzer mit Version 1.0.0 immer ersteinmal auf 2.0.0 updaten.

Zumindest wären das die Fälle wo es sinnvoll ersteinmal die Updates zu ziehen die für eine ganz bestimmte Version gedacht sind.

Hallo,
erstmal Danke fürs Lob. Kurz zum Stand: Ich habe nun soweit alle Features umgesetzt die ich in 1.4.0 haben will, lediglich mit der Vista UAC muss ich noch ne Kleinigkeit bereinigen. Diese Woche will ich dann ne Beta zusammenschnüren.

Die Logik im Updater ist die:

Erste Priorität haben "für"-Updates, also "für Version 1.1.0"
Zweite Priorität haben "ab"-Updates, also "ab Version 1.2.0", was in diesem Falle nicht greifen würde.
Dritte Priorität haben die "für alle"-Updates.

Er müsste also das 2. Update "für Version 1.1.0" liefern.

Das mit dem DLL-Update ist derzeit tatsächlich nicht möglich. Sprich: einzelne Dateien updaten ohne dass sich die Programmversion ändert.
Das möchte ich aber in der nächsten Version ermöglichen. So dass man ggf. auch Plugins oder Sprachdateien aktualisieren kann ohne die Programmversion ändern zu müssen.

Hier nochmal kurz der Ablauf:

Das SelfUpdate-Objekt hat ein neues Property "ValidateStrings". Vllt benenn ich das auch noch um - zum Beispiel in "ValidationString" oder so. Is ja aber auch erstmal egal.

Alle Werte die man prüfen will oder die man im PHP-Skript will kommen da rein, also zum Beispiel:

Dictionary<string, string> dict = new Dictionary<string, string>();
dict.Add("licensekey", "12345-123-12345");

SUpdate.ValidateStrings = dict;

Im PHP-Skript stehen dann die Variablen per $_REQUEST zur Verfügung:

[php]$licensekey = $_REQUEST["licensekey"];

if( $licensekey == "12345-123-12345" )
echo "Sie verwenden eine illegale Version";[/php]

Ich denke das ist leicht zu verwenden.

Also es ist so umgesetzt:

1. Setze ich das Property zum validieren nicht, so frage ich auch erst gar nicht ab ob die Datei da ist, also ich rufe sie nicht auf. Von daher wäre es an der Stelle auch egal ob PHP da ist oder nicht.
2. Setze ich das Property und will somit eine Validierung haben, so wird die validate.php aufgerufen. Kann die Datei ohne Fehler aufgerufen werden entscheidet der Inhalt ob das Update durchgeführt werden kann oder nicht. Gibt es einen Fehler weil die Datei nicht da ist oder eben nicht ausgeführt werden kann, so wird das Update auf jeden Fall abgebrochen.

Unterm Strich also: falls ich kein PHP habe, so können in Zukunft dennoch Updates gefahren werden. Will ich jedoch eine Validierung brauche ich PHP.
Denkbar wäre die Validierung auch über einen Webservice laufen zu lassen. Aber egal wie man es dreht: auf dem Server muss etwas aktives laufen wenn ich Daten validieren will.

Ich hab das zudem durch ein Dictionary<string,string> gelöst.
Dabei ist das paar <key>,<value> im PHP durch $_REQUEST[key] abfragbar.
Es können somit beliebig viele Wertpaare an die validate.php gesendet werden.

Das ist richtig - ich glaub die beiden Produkte hab ich wirklich verwechselt... die Lizenzpolitik von Microsoft ist an dieser Stelle auch ne Katastrophe.

An gerade in Arbeit befindlichen Dateien anderer Leute kann man durchaus arbeiten - anschließend werden diese dann halt zusammengemergt. Oder von welchem Szenario redest du?

Bei der TeamSuite sind doch alle einzelnen Editions dabei und pro Editions eine Lizenz. Zudem bekommt man bei der Team Suite den TFS dazu.

Nun es ist zunächst wie du schon richtig schreibst - eine wirklich andere Möglichkeit gibt es nicht.
Der Updater braucht davon abgesehen für das Logging auch PHP. Daher empfinde ich diese Anforderung als nicht schlimm.

@Th69: Ist das schon so lange her? Wie die Zeit vergeht 😃

Ich habe gerade ein neues Feature umgesetzt. Es geht darum Applikation gezielt von Updates auszuschließen. Zum Beispiel möchte man ja eventuell die Seriennummer der Applikation überprüfen um dann das Update zu verweigern.

Das ganze wird so laufen:
Bei der Updateanfrage kann man einfache Zeichenfolgen anhängen. Diese werden per POST an eine Datei validate.php gesendet die Standardmäßig immer ihr OK gibt.
Diese Datei kann nun nach belieben verändert werden und die gesetzte Zeichenfolge (zum Beispiel die besagte Seriennummer) kann überprüft werden. Sollte aus welchen Gründen auch immer kein Update erlaubt sein, so kann zum durch Beispiel durch ein einfaches

[php]echo "Sie verwenden eine ungültige Seriennummer.";[/php]

das Update verhindert werden.

Das ganze wird für Version 1.4.0 erstmal in dieser einfachen Art umgesetzt. Da man sich in der validate.php - Datei jedoch frei austoben kann ist es meiner Meinung nach schon einmal sehr "offen". Falls euch da noch weitere Ideen einfallen nur raus damit. Ansonsten seht ihr es dann in der Beta.

MS Entwickler sind es gewohnt ihre Projekte in ihre Arbeitsmappen "Auszuchecken",
wer aber mal mit SVN gearbeitet hat, weiss wie bequem es ist, mal eben ( irgendwo auf der Welt )
das Projekt neu zu ziehen, und mal eben einen fix zu machen, den man dann
einchecken kann, ohne andere Entwickler zu fragen, das mal eben Freizugeben.
Zumal es beschwerlich sein kann, wenn man das um 17 Uhr macht, aber z.b. in
Orlando, da sind die Entwickler hier meist schon im Bett.

Wieso sollte genau das nicht mit dem TFS funktionieren? Ganze Projekte auschecken geht doch.

Ich arbeite nun schon eine ganze Weile mit dem TFS. Ich finde es traumhaft. Das komplette Paket setzt sich ja nicht nur aus Quellcodeverwaltung und Issuetracker zusammen.
Gerade den automatisierten Ablauf finde ich beeindruckend. So ist es einfach zu sagen: "Lasse mir beim erzeugen des Daily Builds mal die Tests inkl. CodeCoverage durchlaufen, erzeuge ein MSI, teste das MSI in mehreren VMs und leg das fertige Paket dann nach xy".

Auch die Nachverfolgbarkeit von Aufgabe bis hin zur geänderten Zeile ist schön.
Sicherlich geht das alles auch anderes. Aber gerade die Einfachheit wie "simpel" so ein TFS im Grunde aufzusetzen ist und wie schön integriert ins Visual Studio das Teil ist spricht absolut für dieses System.

Der Preis hält sich stark in Grenzen. Hier kann man nicht 8000€ + Mitarbeiter oder so rechnen. Mit der TeamSuite bekommt man ja 5 Lizenzen für den TFS und die liegt bei um die 8000€ wenn ich mich nicht irre. Dann gibts natürlich noch Volumenlizenzen und dergleichen.

Billig ist es sicherlich nicht, aber auf der anderen Seite auch nicht viel teuerer als für jeden Mitarbeiter ein Visual Studio Professional anzuschaffen. Hier denke ich steht die Leistung mehr als nur im Verhältnis zum Preis.