Hallo speedy,
erstmal vielen Dank für das Lob. Ja das Projekt macht schon sehr viel Arbeit und im Moment komme ich auch nur langsam voran, aber es macht dennoch Spaß.

Zu deiner Frage: derzeit gibt es diese Möglichkeit noch nicht. Das steht auf der ToDo-Liste, aber ich find im Moment für sowas die Zeit nicht - da haben andere Sachen Priorität.

Zur nächsten Frage: Es gibt ja mehrere Möglichkeiten. Du könntest in deinen Updatepaketen immer alle Dateien der jeweils aktuellen Version reinpacken.
Also wenn deine aktuelle Version v1.3.0 wäre, dann würde das Update dazu alle Dateien beinhalten für die Anwendung. Somit könnte man von jeder beliebigen vorherigen Version auf v1.3.0 updaten. Bedeutet natürlich auch einen gewissen Overhead. Denn wenn sich von v1.2.0 zu v1.3.0 nur eine Datei geändert hat, so würden dennoch alle Dateien übertragen werden, auch die die sich nicht geändert haben.

Will man die Updates klein halten, so arbeitet man mit inkrementellen Updates. Du packst in das Update von v1.3.0 wirklich nur die Dateien rein die sich seit der vorherigen Version geändert haben. Das bedeutet natürlich, dass du auch nur von der vorherigen Version aktualisieren kannst.

Beim K_Updater wirds da im Grunde drei Möglichkeiten geben:

1. Vorher werden bereits die Daten zur Impersonifikation mitgeben. So würde die updater.exe bei Bedarf (also wenn für einen Schreibvorgang nicht ausreichend Rechte gegeben sind) das Benutzerkonto gemäß den Angaben aus der Admin-Oberfläche heraus verwenden. Sollten hier Daten falsch angegeben sein oder die Rechte immernoch nicht ausreichen würde der Anwender eine Meldung und könnte dann manuell ein Benutzerkonto angeben.
   Diese Variante ist sicherlich nur dann relevant, wenn zum Beispiel eine Anwendung innerhalb einer Firma aktualisiert wird und auf jedem PC das gleiche Admin-Konto verfügbar ist.
2. Es wird vorher kein Benutzerkonto angegeben und bei Bedarf bekommt der Anwender eine Meldung und kann dann das Konto manuell wechseln.
3. Der Updateprozess erwartet von vornherein Adminrechte und startet auch entsprechend. Unter Windows Vista würde das eine Bestätigung des Anwenders erfordern (so wie man diese nervigen Dialoge eben kennt).

Im ersten Falle wird das Passwort verschlüsselt in der entsprechenden XML-Datei abgelegt die sich im Updatepaket befindet.
Sicherlich gibt es bei dieser Möglichkeit auch immer Sicherheitsrisiken. So wird zum Beispiel die Verschlüsselung immer mit dem gleichen Key gemacht. Jedoch ist das ja nur "halb so wild". Denn immerhin kann diese Methode eh nur in einem Umfeld vorkommen in dem ja die Benutzerkonten schon bekannt sind -> Firmenintern. Und an den Key muss man dann ja auch erstmal rankommen um das Passwort zu entschlüsseln.

Vielen Dank für den Hinweis und auch für die Analyse des Problems.

Das sollte definitv einstellbar sein wenn das Probleme machen würde. Eventuell werde ich auch einfach die Endung .zip ab der nächsten Version verwenden.
Ich werde zusehen das ich sowas für die nächste Version auch noch umsetze.

Mmh das wird ja eine richtige Wissenschaft. Im Grunde habe ich schon drüber nachgedacht ob die Administrationsoberfläche nicht sogar nur eine einzige "für alle" - Updatepakete zulassen sollte oder alternativ nur eine "aktiv" sein darf. Das würde aber ein neues Feature erfordern.

@DeadEye: Die Statistiken bleiben davon unberührt. Was genau meinst du mit dem Available-Flag?

Zum ersten: Ich möchte das bewusst deshalb so haben, da der Flag "für alle" ausdrücken soll, dass ich jede x-beliebige Version von vorher, egal welchen Zustand sie hatte, aktualisieren kann.

Wenn ich 3 Versionen auf "für alle" habe und eine der drei Versionen irgendwelche Abhängigkeiten hat, dann ist hier meiner Meinung nach eine falsche Wahl getroffen.

Das würde dann ja für das inkrementelle Update sprechen denke ich. Beziehungsweise müsste man dann in deinem Beispiel bei Version 1.3 nicht "für alle" einstellen, sondern "ab Version 1.2".

Zum Thema inkrementellen Update gebe ich dir absolut recht. Die Möglichkeit alles in einem Rutsch runterzuladen möchte ich auf jeden Fall zeitnah drinhaben, schon alleine deswegen weil ich selbst fast nur diese Methode nutze. Das möchte ich angehen nachdem auch die Registryeinträge geändert werden können.

Aber mal zu was anderem. Ich schaffe es wohl bis Sonntag die nächste Version soweit fertig zu machen. Dann sollte auch die Impersonfikation gehen. Da dies aber erstmal getestet werden will, werde ich die Version dann nicht über meine Seite anbieten oder übers Update sondern erstmal hier im Forum zum Testen freigeben.

Ich habs nun umgesetzt. Hier mal ein Screenshot eines möglichen Szenarios mehrere "für alle"-Updates und was der Updater nun auswählen würde wenn die ursprüngliche Anwendungsversion 1.0.0.0 wäre:

@DeadEye: das liegt daran, dass die Versionen nicht übersprungen werden weil ich es noch nicht implementiert habe 🙂 Ich bin aber gerade dabei eine Logik dafür zu schreiben um immer die neueste Version zu selektieren.

Das würde bedeuten, wenn man 3 "für alle" Pakete hat mit den Nummern:
1.1.0
1.2.0
1.3.5

so würde der updater die Version 1.3.5 wählen. Bis zu nächsten Version schaffe ich das noch das umzusetzen.

OK so macht das dann Sinn. Ich werd mich da mal ranhalten und versuchen den Updater so anzupassen, dass es auch Sinn machen würde Teilupdates runterzuladen.

Bei der Gelegenheit werde ich mich aber mal drum kümmern und meine Doku für den Aufbau sämtlicher xml-Dateien ins Wiki stellen. Ich denke das wäre eine Hilfe für alle die da n bissl dran rumbasteln wollen.

@SunboX:
Erstmal vielen Dank für das Lob. Sowas liest man gerne.
Zum zweiten finde ich es klasse, dass du dir die Mühe mit dem Auslesen der Updatepakete machst.

Sowas stand bei mir selbst auf dem ToDo - eventuell wende ich mich da mal per PM oder Mail an dich und vllt können wir deine Skripte direkt im K_Updater verwenden.

Dennoch aber eine Frage zum Verständnis: was genau macht es derzeit für einen Sinn direkt auf die *.update - Datei zuzugreifen? Ich wollte für die übernächste K_Updater-Version die Möglichkeit einbauen, die Updates manuell zu laden (falls keine INet-Verbindung verfügbar wäre) und diese dann in den Programmordner zulegen, so dass der K_Updater die .update-Dateien direkt erkennt und das Update ohne Herunterladen durchführen kann. Da dass aber ja in der aktuellen Version nicht funktioniert frage ich mich gerade was man genau für einen Nutzen hat 🙂 Vllt steh ich aber auch grad aufm Schlauch g

Mmh das ist sonderbar - das werd ich mal näher überprüfen woran das liegen kann grübel Aber jetzt hab ich dein Problem verstanden 🙂

Aufm IIS gibts da aber eh immer irgendwelche Probleme bei der Statistik. Im Moment versuch ich alle IIS-Sachen zu lösen - deswegen dauerts auch gerade alles n bissl länger.

Im Zuge mit der neuen Statistik sollte das Problem dann auch behoben sein.

Danke für die Hinweise.

zu Punkt 1: werde ich versuchen nachzustellen und der Fehler sollte leicht zu beheben sein.

zu Punkt 2: Da versteh ich nicht genau was du mit dem Updateverlauf sagen möchtest. Der mit der CheckBox werde ich beheben.

zu Punkt 3: Den Fehler kenne ich, konnte leider aber bisher noch nicht ermitteln woran das liegt 😦

zu Punkt 4: Das sollte in der nächsten Version bereits behoben sein. Es sei denn natürlich der Pfad den du unter "Vollqualifizierter Pfad" angegeben hast stimmt nicht.

Beim Flag "Test" werden nur Testpakete gezogen. Das hat aber den Grund, dass dieser Flag nicht für Betaversionen gedacht ist oder dergleichen.

Es kommt ja ein Flag Beta dazu der genau das dann abdecken würde. Suche nach allem, aber auch nach Beta-Paketen.

Um das aber nochmal ganz deutlich zu machen:
Der Flag "Test" ist einzig dafür gedacht um ein Updatepaket zu "testen" bevor man es veröffentlicht. Mehr erstmal nicht.

Also man hat die Anwendung beim "Kunden" draußen mit Test=false. Man selbst hälte die identische Anwendung mit Test=true und kann so erstmal testen ob das Updatepaket funktioniert. Hat es geklappt veröffentlicht man es durch entfernen des Hakens.

Der Beta-Flag den ich einbauen möchte ist dann dafür gedacht um diese Pakete auf Wunsch auf miteinzubeziehen.
Will der Kunde auch Beta-Updates kann man in der Anwendung das Flag zur Laufzeit auf true setzen.

So hab ich mir das mal gedacht.

Der Punkt mit der Combobox ist bestimmt umsetzbar.
Zum zweiten Punkt: wie genau? Die Statistiken werden ja für immer gespeichert also kann man das ja schon vergleichen. Oder was genau meinst du?

Die Impersonifikation ist jetzt umgesetzt.
Ein kleines Demovideo könnt ihr euch hier anschauen: Klick

Ich werde nun zusehen das ich das alles soweit jetzt fertig mache und dann gibts die neue Version. Die Proxygeschichte verschieb ich dann auf die nächste Version, dann ist wenigstens mal diese Funktion verfügbar.

Japp genau so hab ich das dann für den Beta-Flag gedacht.
Aber bis der implementiert ist kann man das natürlich auch mit dem Test-Flag umsetzen.

Dazu gibts ja das Property "Test".
Steht das auf true werden nur die Pakete gezogen die das Flag "Testpaket" gesetzt haben. Andernfalls die anderen. Ist gedacht um Updatepakete vorher zu testen.

Man könnte dann die Anwendung mit Flag = false rausgeben und man selbst hat die Anwendung mit dem Flag = true daheim und somit kann man das schonmal vor der Veröffentlichung testen.

Das was du machen möchtest geht damit dann natürlich auch.

Später soll das ganze dann noch einen Flag "Beta" bekommen. Im Grunde der gleiche Zweck aber so kann man den Benutzern einen Haken "Nach Beta-Versionen suchen" geben.

Nein das sollte schon durchaus gehen. Die Idee ist auch nicht schlecht. Allerdings derzeit müssen erst andere Sachen gelöst werden.
Im ersten Schritt werde ich es mal möglich machen das Downloadfenster von der Hauptapplikation abzukoppeln und in den Tray zu minimieren.
Der nächste Schritt wäre dann den Download im Hintergrund.

Ja das ist dann ein TimeOut weil ich da irgendwas beim KeepAlive falsch mache glaube ich 🙂

Ja so Probleme tauchen eh gerne mal auf... benutzen ja so wie es aussieht nicht wenige Free-Hoster und die begrenzen ja ziemlich gerne. Aber da schau ich mal ob es in dem Umfeld ein Problem gibt.

Ja klar - genau in dem Moment in dem ich mich anmelde kann man das vermutlich irgendwie auslesen.

Aber das bringt diese Methode vermutlich nun so mit sich.
Die Credentials muss man ja nicht mitliefern.

Es gibt ja nicht viele Möglichkeiten das zu machen. Wenn man das automatisiert haben will, also in einem Umfeld in dem nur eingeschränkte Benutzer sind und man dennoch das Update gestattet will muss man irgendwie Zugriff auf das Adminkonto gewähren.

Möglichkeit 1 wäre dann die Methode die ich gerade umsetze.
Möglichkeit 2 wäre einen Dienst zu installieren der im System-Kontext läuft und somit die Berechtigung hätte. Das kann ich mir mal für später irgendwann vornehmen.

Wie was?

Ich hab mir das nochmal alles überlegt wie es wohl optimal wäre.
Möglich sollte von seiten der Updatepaket-Konfiguration sein entweder direkt die Credentials für die Impersonifikation zu vergeben oder alternativ auch direkt den Admin-Modus vorauszusetzen. Im zweiten Falle führe ich den Prozess updater.exe auch direkt mit requireAdmin aus.

Sollte beides nicht gewählt sein würde im Falle eines Fehlers beim Löschen oder beim Schreiben einer Datei der oben gezeigte Dialog erscheinen und dort müsste dann eben noch die Möglichkeit rein das Benutzerkonto zu wechseln.

Ja an der Stelle muss ich mir das mal überlegen.
Ich werd mal versuchen rauszufinden wie man ermitteln kann ob eine Datei gerade in Benutzung ist.

Der Dialog hat selbstverständlich noch Zeit. Habe an der Anwendung sowieso noch andere Sachen zu schaffen. Somit macht das nichts wenns heute nichts mehr wird.

Ich hab nun mal ein kleines Szenario nachgestellt.

Der Benutzer befindet sich auf einem XP-Rechner mit eingeschränkten Benutzerrechten.
Es sind keine Impersonifikationsinformationen hinterlegt. Das Update wird durchgeführt und versucht Dateien zu löschen.

17:09:40 [Main][deleteFiles] Delete old files...
17:09:40 [Main][deleteFiles] -> Delete C:\Programme\Testapplikation\Update\5239-sd.jpg...
17:09:40 [Main][deleteFiles]    - 1. try
17:09:40 [Main][deleteFiles]    - Could not delete file
17:09:40 [Main][impersonifyUser] Try Impersonification
17:09:40 [Main][impersonifyUser] -> No Informations
17:09:40 [Main][deleteFiles]    - 2. try
17:09:40 [Main][deleteFiles]    - Could not delete file
17:09:44 [Main][deleteFiles]    - 3. try
17:09:44 [Main][deleteFiles]    - Could not delete file
17:09:45 [Main][deleteFiles]    - 4. try
17:09:45 [Main][deleteFiles]    - Could not delete file

Nach dem ersten Versuch wird versucht dem Benutzer mehr Rechte zugeben, es sind aber keine Informationen hinterlegt. Jetzt bekommt der Benutzer einen Dialog angezeigt der derzeit noch so aussieht:

Er hat nun mehrmals auf "Wiederholen" geklickt, daher oben die mehreren Versuche.

Nun der zeite Fall:
Es wurden Impersonifikationsinformationen hinterlegt. Diese Informationen können natürlich auch nachträglich noch geändert werden, es muss ja nur das Updatepaket bearbeitet werden.

Nun schaut das ganze so aus:

17:12:26 [Main][deleteFiles] Delete old files...
17:12:26 [Main][deleteFiles] -> Delete C:\Programme\Testapplikation\Update\5239-sd.jpg...
17:12:26 [Main][deleteFiles]    - 1. try
17:12:26 [Main][deleteFiles]    - Could not delete file
17:12:26 [Main][impersonifyUser] Try Impersonification
17:12:26 [Main][impersonifyUser] -> OK
17:12:26 [Main][deleteFiles]    - 2. try
17:12:26 [Main][deleteFiles] -> Delete C:\Programme\Testapplikation\Update\96910.jpg...
17:12:26 [Main][deleteFiles]    - 1. try
17:12:26 [Main][deleteFiles] -> Delete C:\Programme\Testapplikation\Update\1247319464lpb8.jpg...
17:12:26 [Main][deleteFiles]    - 1. try

Das Update läuft ohne murren durch und der Anwender wird keine einzige Meldung sehen.

@Jelly: Das sollte jetzt so ziemlich genau dem Ablauf entsprechen den du dir vorgestellt hast.

Genau das wäre der Ablauf dann.

So in etwa könnte das dann bei der Updateerzeugung aussehen:

Ist das eigentlich so korrekt wenn man das dann auch als "Impersonifikation" bezeichnet oder ist da eine andere Bezeichnung üblich?

Ich habe es nun so umgesetzt:

Man kann bei der Erzeugung eines Updatepaketes die Konto-Daten für die Impersonifikation angeben, wenn diese schon vorher bekannt sind.

Tritt beim Update ein Fehler auf (Dateien können nicht gelöscht oder geschrieben werden) wird - falls Informationen angegeben wurde - per Impersonifikation der Benutzer kurzfristig gewechselt. Daraufhin wird erneut versucht die Datei zu löschen oder zu kopieren. Klappt das wieder nicht bekommt der Anwender eine Meldung mit einem entsprechenden Hinweis. Er hätte dann die Möglichkeit das Update abzubrechen, die Aktion zu wiederholen oder dann eben die Kontoinformationen manuell anzugeben.

Ich glaube das müsste dann in dieser Weise ok sein oder?

So wie du dir das vorstellst wäre es gut. Passwort in SecureString wäre auch gut.

Dann bin ich mal gespannt und schonmal vielen Dank an der Stelle.

Richtig, das müsste reichen an der Stelle.
Wenn du das machen könntest wäre das natürlich klasse. Dann könnte ich mich an der Stelle dann schonmal auf das korrekte Impersonifizieren konzentrieren.

Exakt. Genauso stell ich mir das auch vor.
Und genau diese Aufforderung benötige ich jetzt nämlich. Und da komm ich grad nicht weiter. Weil genau da stell ich mir dann vor, dass solch ein Dialog wie oben erscheint.

Ja das ist ja schon klar. Aber das Problem ist doch, dass ich doch hier noch nicht die Konteninformationen eines x-beliebigen Benutzers da draußen kenne, also muss ich ihn zu Laufzeit auffordern Benutzer und Passwort einzugeben.

Aber um das Update durchführen zu können braucht er ja vorrübergehende Admin-Rechte. Und wie genau soll das dann ablaufen?

Also er braucht ja zwingend Adminrechte sonst kann er ja auf keinen Fall in den Programmordner schreiben.

Ich bin nun dabei dieses Problem mit den Adminrechten zu lösen.

Schritt 1 ist mal gelöst: es ist möglich - wenn man das will - die Benutzerinformationen unter dessen Rechten die updater.exe ausgeführt werden soll direkt anzugeben. Das bedeutet der Anwender müsste nichts mehr bestätigen und das Update würde durchlaufen.

Ich konnte das auch unter XP erfolgreich testen. Der Benutzer hatte eingeschränkte Rechte, konnte das Update aber dennoch durchführen und im Programmeordner wurden die entsprechenden Dateien angelegt. Diese konnten im Anschluss aber auch nicht mehr vom Benutzer gelöscht werden, da dieser ja keine Rechte dazu hatte. Ich denke das ist vom Verhalten her korrekt.

Jetzt kommt aber eben noch der andere Punkt: die Kontoinformationen sollen ja nicht unbedingt schon mitgegeben werden, bzw. können sie ja auch im Normalfall gar nicht mitgegeben werden.
Wie ist in so einem Falle vorzugehen? Kann mir an dem Punkt jemand helfen wie ich eine Anwendung starte, so dass daraufhin diese Meldung aufpoppt und der Benutzer aufgefordert wird entsprechende Kontoinformationen anzugeben?

Ich denke dabei an diese Meldung:

Um mal einen kleinen Vorgeschmack zu geben was die neue Statistikauswertung so bietet hab ich n kleines Video davon gemacht.

Hier der Link zum Video: Klick

Also in dem Punkt muss ich dir Recht geben... PHP auf einem IIS einzurichten... Himmel... das musste ich zweimal hier in der Firma machen und ich saß jeweils n halben Tag dran. Müsst ich mir mal anschauen wieviel Zeit das genau in Anspruch nehmen würde.

Übrigens kommt in der nächsten Version nun auch endlich die Möglichkeit die Nachricht am Ende des Updatevorgangs zu unterdrücken. So muss nicht mehr mit OK bestätigt werden.

Das Proxyproblem bin ich gerade dabei zu lösen.

Der Sinn an der Stelle ASP zu verwenden erschließt sich mir jetzt auch nicht.
Die Unterstützung von MS-SQL ist für später (etwa 1.8.0) geplant.

Japp natürlich. Sollte ja eigenltich jetzt schon gehen, aber ich habs nie wirklich durchgetestet. Ich kümmer mich aber drum. Ich schau mal, dass ich zumindest die Unterstützung in der DLL bis v1.4.0 drin hab.

@dennisspohr:
OK, dann funktionierts zumindest generell mal, aber 20 Sekunden nicht natürlich deutlich zu viel.

@t-master:
Das ist natürlich nachzuvollziehen und auch machbar. Aber erst später, ich habs mal im Bugtracker zu Version 1.10 geschrieben 🙂

"/" wird nicht akzeptiert, dass ist richtig. Das liegt an einer doofen Sachen. Ich lösche vorher immer den Ordner den man ausgewählt hat und lege ihn neu an. Somit stelle ich sicher, dass er auch leer ist.

Das ist recht unelegant und "/" kann ich natürlich nicht löschen. Deswegen der Fehler. Ich werde das aber beseitigen und das mal korrekt überarbeiten.

Das andere ist ein TimeOut-Problem. Das kämpfe ich noch mit, denn eigentlich stelle ich vor jeder Aktion die Verbindung zum FTP-Server her. Mal sehen was ich da mit KeepAlive oder dergleichen machen kann.

Mmh das Problem mit dem Cross-Thread ist sonderbar. Das hatte ich jetzt auch noch nie gehabt... grübel hat da einer eine Idee?

Ansonsten zur Sache mit der Impersonifikation. Ich brauche da durchaus Leute die Testen und die mir dabei eventuell etwas helfen können.
Wenn ihr nichts dagegen habt wende ich mich wenn ich aktiv damit anfange per PM an euch - sehe ja hier im Thread wer es schon alles gefordert hat.

Mit Impersonifikation und UAC hab ich von der Programmierseite selbst noch fast keine Erfahrung und da bin ich für jede Hilfe dankbar.

Ja das ist wirklich zu lange.
Mal sehen wie ich das schneller machen könnte 🙂

@dennisspohr:
Zu dem Problem mit der Firewall. Ich hab das mal getestet und nach kurzer Zeit (ich glaube 15-30 Sekunden) wird der Code 800 als Ergebnis der Updateprüfung geliefert. Prüfe das mal bitte ob das bei dir auch passiert.

Habe eben Version 1.3.2 veröffentlicht. In dieser Version sind Fehler behoben.

Änderungen hier: Klick

Der Fehler, dass die Administrationsoberfläche beim Abruf der version.xml hängen bleibt besteht noch. Ich arbeite aber daran.

Hallo Jelly,
erstmal vielen Dank für das Feedback.

Zum ersten Punkt: Das ging in der letzten Version auch nicht - zumindest nicht explizit. Aber auch mich nervt es bereits, dass der letzte Ordner nicht gemerkt wird. Das werd ich nachreichen.

Zweiter Punkt: Das kann tatsächlich passieren wenn man zulange nichts macht. Das trage ich gleich ein und werds dann beheben.

Dritter Punkt: Das müsste ich jetzt näher analysieren. Wenn das vorher einwandfrei funktioniert hat, dann könnte ich mir vorstellen woran das liegt.

Ich hoffe die ganzen Punkte übers WE gelöst zu haben. Am Sonntag sollte dann eigentlich die neue Version kommen.

@ChMaster: Am SFTP-Zugang hab ich noch nicht weitergearbeitet. Das muss leider noch etwas warten 😦

Mmh das ist mir etwas schleierhaft wie das zusammenhängen kann - mmh.

Mir ist da offenbar aber ein Fehler unterlaufen weswegen der Fehler mit der version.xml auftreten könnte. Ich werde versuchen den heute noch zu lösen.

Das war wohl doch falscher Alarm. Aber seit heute hab ich das auch öfters mit der version.xml... komisch... na ja es wird irgendworan liegen und dann find ich das auch 🙂

Logs würden eventuell helfen. An webmaster@klausmoster.de
Versuch das Projekt mal mit einem Unterordner zu erzeugen. Also nicht direkt in den Root rein.
An der Stelle gab es schonmal ein Problem an dem ich gerade arbeite.
Jetzt fällt mir gerade ein... eventuell kann der auch mit dem www37 Probleme haben...

Hast du das beim Vollqulifizierten Pfad korrekt angegeben?

Standardfrage: Was benutzt ihr für Server? Wie heißt der Pfadname auf dem Server den ihr verwendet? Hat der Leerzeichen oder keine?

Ansonsten irgendwelche besonderheiten? UAC aktiviert? Temp-Ordner voll? Irgendwas in dieser Hinsicht das von der Norm abweicht?

Vielen Dank. Wie ist das mit dem Problem - ist das jedes Mal bei Projektöffnung so?

Verschlüsselung wollte ich unbedingt einbauen. Wenn du da bereits was gutes hast würde ich mich freuen. Dann kann ich das direkt einbauen.

Ich hatte das demletzt auch ein paar Mal mit der version.xml. Allerdings wenn ich die Administration.exe abgeschossen habe und nochmal gestartet habe gings wieder. Muss ich mal nachschauen woran das wieder liegt 🙂

Mmh also ich kann mir da immer noch gar nichts drunter vorstellen.
Meinst du jetzt die PHP-Sessions gehen nicht mehr? Ich kann mir dann nämlich nicht vorstellen wie das zusammenhängen sollte. Im Ordner den du für das Projekt verwendest ist sonst nichts mehr drin oder?

Ich glaub das musst du mir mal jetzt genauer beschreiben was du da genau machst und was dann genau nicht mehr passiert.

Mmh also ich muss zugeben, dass ich keine Ahnung habe. Ich kann mir noch nicht mal wirklich vorstellen was da nun genau nicht gehen soll.

Bitte gib mir mal genauere Infos. Was für einen Server hast, in wie fern gehen Sessions nicht mehr? Unter PHP?

Eventuell auch eine genaue Information wie du die Ordner benannt hast, zum Beispiel gibts beim IIS Probleme mit Leerzeichen - allerdings wirkt sich das nicht auf Sessions aus.