CSDIL_PROGRAM_FILES in 32Bit/64Bit

[QuickAndDirty]

Hallo ich muss aus einem 32 Bit Programm heraus ermitteln
ob ein ein angeebener Pfad dem Programme Verzeichnis entspricht bzw. darin liegt.

Das muss auch funktionieren wenn das Programm auf einem 64Bit Betriebsystem läuft.

Ich mache das wie folgt:

Delphi-Quellcode:

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls,
  Registry,
  ActiveX,
  ComObj,
  ShlObj;

Function CheckForProgramFilesPath(aPath:String):Boolean;
var Ppath:String;
    hPath: PChar;
    pIdl: PItemIDList
Begin
  aPath := ExpandUNCFileName(aPath);
  PPath := '';
  if SUCCEEDED(SHGetSpecialFolderLocation(0, CSIDL_PROGRAM_FILES, pidl)) then
  begin
    hPath := StrAlloc(MAX_PATH);
    SHGetPathFromIDList(pIdl, hPath);
    PPath := hPath;
    StrDispose(hPath);
  end;
  FreePIDL(pIdl);
  Result := Ansipos(PPath, aPath) = 1;
End;

Ich bin mir nicht ganz sicher, kann es hier auch nicht testen, aber kann es sein das dieser Code auf einem 64Bit Betriebssystem nicht funktioniert?

Was gibt SHGetSpecialFolderLocation für CSIDL_PROGRAM_FILES zurrück wenn man es auf einem 64 Bit Betriebsystem mit einer 32 Bit Anwendung abfragt?

[DanielProgramming]

C:\Program Files (x86) bei mir (englisches Windows 7 x64, Delphi XE3 Testversion, Zielsystem: Win32)

[QuickAndDirty]

Uff.
Das könnte erklären warum das schief geht.

Kannst du auch ExpandUNCFileName('C:\Program Files')
testen?

Wenn das etwas anderes liefert als das Kompatibilitäts Verzeichnis habe ich ein Problem.

[DanielProgramming]

Kommt C:\Program Files raus

[QuickAndDirty]

Das erklärt dann mein problem!

Danke !

[RWarnecke]

Auf einem Windows 64Bit wird CSIDL_PROGRAM_FILES bei einem 32Bit-Programm C:\Program Files (x86) und ein 64Bit-Programm C:\Program Files als Ergebnis liefern.

[hathor]

"Wer nach Hunden sucht, wird keine Katzen finden."

Die Frage ist falsch gestellt:
Nimm KNOWNFOLDERID:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
.
http://msdn.microsoft.com/en-us/wind.../gg463051.aspx
.
FOLDERID_ProgramFiles

GUID: {905e63b6-c1bf-494e-b29c-65b732d3d21a}
Display Name: Program Files
Folder Type: FIXED
Default Path: %ProgramFiles% (%SystemDrive%\Program Files)
CSIDL Equivalent: CSIDL_PROGRAM_FILES
Legacy Display Name: Program Files
Legacy Default Path: %ProgramFiles% (%SystemDrive%\Program Files)

[QuickAndDirty]

Und wie bekomme ich damit Raus ob z.B.
'c:\Programski Fileski\MYProgramm'
ein Ort in einem SpecialFolder ist?

Ich muss verhindern das ein Setup etwas in das "Programme" Verzeichnis installiert, Weil unsere Anwendung dafür noch nicht ausgelegt ist.

[hathor]

Das ist doch in den Links oben genau beschrieben:
Mit einem 32Bit-Programm bekommst Du auch NUR den 32Bit-Ordner! Siehe Anhang...

Ich würde von den WINDOWS-Programm-Pfaden "die Finger lassen".

Alternative - da ist es gleich, ob 32Bit oder 64Bit:

Delphi-Quellcode:

function SpecialDirectory(const iID: Integer): string;
var aPath  : array[0..MAX_PATH] of Char; pilTemp: PItemIDList;
begin
   try
      if SHGetSpecialFolderLocation(0, iID, pilTemp)=S_OK then begin
         if SHGetPathFromIDList(pilTemp, aPath) then begin
            Result := string(aPath);
         end else Result := ''; CoTaskMemFree(pilTemp);
      end else Result := '';
   except Result := '';
   end;
end;

function GetConfigPath: String;
var AppDir: String;
begin
  AppDir := SpecialDirectory(CSIDL_APPDATA)+'\DEIN PROGRAMM-NAME'; //DEIN PROGRAMM-NAME
  if DirectoryExists(AppDir) = false then mkdir(AppDir);
    result := AppDir+'\';
end;

[Luckie]

Warum nicht ParamStr(0) oder ist es nicht das eigene Programm?

[QuickAndDirty]

Ich will nicht IN einen Specialfolder installieren.

Ich will verhindern das jemand einen Ordner angibt der ein Specialfolder ist. Insbesondere die WOW64 File System Redirection macht das recht schwer.

Ich habe jetzt folgende Lösung aus dem Guide den du Verlinkts hast zusammen gestrickt.

Delphi-Quellcode:

Function CheckForProgramFilesPath(aPath:String):Boolean;
var Ppath:String;
    i:integer;
  const PathVariable:Array[0..5] of string=(
                                            '%ProgramFiles%',
                                            '%ProgramFiles(x86)%',
                                            '%ProgramW6432%',
                                            '%CommonProgramFiles%',
                                            '%CommonProgramW6432%',
                                            '%CommonProgramFiles(x86)%'
                                           );

  function ExpandEnvStr(const szInput: string): string;
  var szBuf:String;
      r : Cardinal;
  begin
    result := '';
    try
      r := ExpandEnvironmentStrings(pChar(szInput), nil, 0);
      if r > 0 then
      Begin
        SetLength(szBuf, r);
        ExpandEnvironmentStrings(pChar(szInput), PChar(szBuf), r);
        result := PChar(szBuf);
      End;
    except
      Result := '';
    end;
  end;
{
  Function UnExpandEnvPath(const szPath: string):String;
  var szBuf:String;
      cchBuf:Cardinal;
  Begin
    setLength(szBuf, MAX_PATH);
    cchBuf := MAX_PATH;
    if PathUnExpandEnvStrings( Pchar(szPath),@szBuf[1],cchBuf) then
      Result := Pchar(szBuf)
    else
      Result := szPath;
  End;
}
  Function TestPath(ReferencePath,aTestPath:String):Boolean;
  Begin
    Result := (ReferencePath <> '') and
              (length(atestPath) > length(ReferencePath)) and
              (Ansipos(ReferencePath,aTestPath) = 1);
  End;

Begin
  result := false;
  aPath := ExpandUNCFileName(aPath);
  for I := 0 to 5 do
  Begin
    PPath := ExpandEnvStr(PathVariable[i]);
    if TestPath(PPath,aPath) then
    begin
      Result := true;
      exit;
    end;
  End;
End;

Nur weiß ich nicht ob das funktioniert.

[QuickAndDirty]

Zitat:

Zitat von Luckie (Beitrag 1182086)

Warum nicht ParamStr(0) oder ist es nicht das eigene Programm?

Ich will eine Installation in den Programme Ordner verhindern.
Das Problem ist zu prüfen ob der angegebene Pfad der Programme Pfad ist.

[DeddyH]

Zitat:

Zitat von QuickAndDirty (Beitrag 1182090)

Ich will eine Installation in den Programme Ordner verhindern.

Bist Du Dir sicher, dass das der richtige Weg ist? Immerhin ist das ja der vorgesehene Installationsordner.

[Bummi]

@DeddyH
Für manche Anwendungsfälle mag man den Nachteil den diese Ordner mit sich bringen vermeiden wollen. (Ich weiß dass das nicht Microsoftkonform ist, aber wenn man schaut wie es Microsoft mit den seinen Programmen bzgl. dieses Punktes bisweilen hält, relativiert sich das)

[DeddyH]

Das will ich gar nicht bestreiten, aber das sind dann doch eher Ausnahmefälle. Wenn ein Programm Probleme bekommt, weil es in diesem Ordner installiert wurde, liegt der Verdacht nahe, dass man etwas falsch gemacht hat (Schreiben ins Programmverzeichnis ist da immer ein Kandidat).

[Sir Rufo]

Genau das wollte er ja auch mit der Aussage nahe bringen, dass das Programm dafür noch nicht vorbereitet ist.

Allerdings würde ich versuchen bei der Installation dem Programmverzeichnis die entsprechenden Schreibrechte mitzugeben. Das Loch wird dadurch auch nicht größer als es für die Funktionsweise des Programms benötigt wird.

[Dalai]

Zitat:

Zitat von QuickAndDirty (Beitrag 1182087)

Nur weiß ich nicht ob das funktioniert.

Das funktioniert im Prinzip und ist dabei eine der beiden einzigen Möglichkeiten (die ich kenne), von einem 32 Bit Programm an den Pfad "%SystemDrive%\Program Files" eines 64 Bit OS zu kommen. Die andere Möglichkeit wäre das Auslesen von [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Curr entVersion], Wert ProgramFilesDir aus der Registry mit dem Flag KEY_WOW64_64KEY für die Funktion OpenKey(). Ein ähnliches Problem hatte ich in diesem Thread vor einem halben Jahr geschildert und mit der Verwendung beider Methoden auch gelöst.

Im Grund schließe ich mich aber den Vorschreibern an, dass es besser wäre, die Installation zuzulassen und die Zugriffsrechte entsprechend zu setzen.

MfG Dalai

[QuickAndDirty]

Ich glaube das Problem ist das ich in diesem Ordner keine Freigaben machen kann.
irgendwas war zumindest da, was macht das unser Programm so wie es jetzt ist nicht im Programme Ordner funktioniert,
obwohl NetShareAdd + Access_All
und SetFileSecurityRecursive + Userid #1#1#0#0#0#0#0#1#0#0#0#0 + DACL mit Vollzugriff
usw. gesetzt wird.

Um das Windows konform zu machen müssen wir noch ne menge Arbeit reinstecken...und da das keine Features sind die der Kunde würdigt ist das für Kunden Quasi leerlauf....entwicklungsstillstand...


Besonderen Dank euch, Dalai, Hathor, DanielProgramming, für die Info.
@All: ich weiß es ist nicht der beste weg, aber ich muss mir meine Zeit einteilen. So ist das Problem schon mal vom Tisch des Support, die keine Installationen mehr in Ordnung bringen müssen, Ich kann denen nicht sagen sie sollen mal eben 3-6 Monate mit dem Problem leben bis ich die beste aller Lösungen umgesetzt habe.

[himitsu]

Nur mal dem ganzen Verzeichnisstringvergleichen einhalt zu gebieten...

Dein Programm hat also Probleme, wenn es in einem Verzeichnis installiert ist, wo es keine Schreibrechte besitzt, weil es immernoch in seinem eigenem Programmverzeichnis rumschreibt?

Dann wäre es besser, wenn du prüfst, ob es Schreibrechte besitzt und nicht einfach nur wahllos mit irgendwelchen Verzeichnisnamen vergleichst.
Oder du machst es wie alle Programme und prüfst garnichst, sondern vertraust darauf, daß der Benutzer es ordentlich installiert. (und erwähnst es wenigstens spätestens im Setup)
Oder du reparierst dein Programm, so daß es endlich ordnungsgemäß arbeitet. (was man eigentlisch schon seit mindestens Win200 hätte machen sollen)

Tipp:
- Es gibt noch mehr Verzeichnisse, wo man nicht schreiben darf.
- Der Benutzer kann die Rechte ändern, wie er lustig ist.
- Ist dir bekannt, daß man das selbe Verteichnis unterschiedlich ansprechen kann? (lange Namen, kurze 8.3-Name, UNC-Pfade, Hardlinks, Softlinks, Verzeichnis/Partition mehrfach gemountet, ...)
- ...

[WM_CLOSE]

Tipp: Schreib ganz oben in deine EULA, die beim Setup angezeigt wird:
"Nicht ins Programme-Verzeichnis installieren, da es sonst zu Fehlfunktionen führen kann!". Damit ist das Problem vorerst umgangen. (Bis auf DA-User, die es trotzdem falsch installieren)

Danach überarbeitest du das Programm, dass es ins Benutzerverzeichnis bzw. ins Allusers-Verzeichnis schreibt. Es gibt genug dazu hier im Forum.

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1182556)

Nur mal dem ganzen Verzeichnisstringvergleichen einhalt zu gebieten...

Dein Programm hat also Probleme, wenn es in einem Verzeichnis installiert ist, wo es keine Schreibrechte besitzt, weil es immernoch in seinem eigenem Programmverzeichnis rumschreibt?

Das ist nicht GANZ das Problem.
Das Problem ist eigentlich das es eine Freigabe benötigt.
Mit schreib und lese Rechten für Daten (Ich glaube das geht für die Spezialverzeichnisse nicht).
Selbst wenn das ginge ist die andere Sache das sich die Clients selbstständig über die Serverfreigabe updaten können. Das Update wird im Bedardsfall beim Start des Clients ausgelöst und das Programmverzeichnis dann kopiert.

Zitat:

Zitat von himitsu (Beitrag 1182556)

Dann wäre es besser, wenn du prüfst, ob es Schreibrechte besitzt und nicht einfach nur wahllos mit irgendwelchen Verzeichnisnamen vergleichst.

Ich versuche bei der Installation Fehler die unserem Support Aufwand erzeugen zu verhindern. Das ist Sinn und Zweck dieser Maßnahmen. Natürlich kann ich nicht jeden scheiß vorhersehen. Aber so das typische auswählen den Progamme Verzeichnis kann ich verhindern.
Desweiteren verhindere ich das Auswählen von Netzwerkpfaden oder Netzlaufwerken als Installationsort, da wir einen FB-Server mit ausliefern und der mag das auch nicht.
Und natürlich prüfe ich nicht nach Schreibrechten, da das Setup nur mit Administrator rechten ausgeführt werden kann, setze ich direkt Vollzugriffs-Rechte für "Jeder" und gebe den Ordner frei.

Zitat:

Zitat von himitsu (Beitrag 1182556)

Oder du machst es wie alle Programme und prüfst garnichst, sondern vertraust darauf, daß der Benutzer es ordentlich installiert. (und erwähnst es wenigstens spätestens im Setup)

Wir erwähnen so ziemlich alles im Setup...leider scheitern wir dennoch daran das der Admin oder "User dem das Admin Passwort bekannt ist" die Informationen die wir Vermitteln möchten auch aufnimmt.
Aber ich arbeite an einem Comic um das vermitteln der Handlungsanweisungen im Setup interessanter zu gestallten.
Zur Zeit scheint der Einzige nutzen von Erklärendem Text und Handlungsanweisungen im Setup darin zu bestehen, dafür zu sorgen das man einem Kunden der sich aufregt RTFM sagen kann...natürlich höflich verklausuliert. Das bleibt dann natürlich trotzdem beim Support hängen und der belästigt mich damit...

Zitat:

Zitat von himitsu (Beitrag 1182556)

Oder du reparierst dein Programm, so daß es endlich ordnungsgemäß arbeitet. (was man eigentlisch schon seit mindestens Win200 hätte machen sollen)

Wir sind dabei, aber ich brauchte eine schnelle Lösung.

Zitat:

Zitat von himitsu (Beitrag 1182556)

Tipp:
- Es gibt noch mehr Verzeichnisse, wo man nicht schreiben darf.

übelst...zum Glück gab es noch keine Installationen im System32 Ordner...und so einen kram.

Zitat:

Zitat von himitsu (Beitrag 1182556)

- Der Benutzer kann die Rechte ändern, wie er lustig ist.

Da ich die Rechte beim Installationsverlauf selbst setzte, hat das Setup alles erfüllt was es soll. Der Rückbau von Rechten liegt in der Verantwortung des Administrators.

Zitat:

Zitat von himitsu (Beitrag 1182556)

- Ist dir bekannt, daß man das selbe Verteichnis unterschiedlich ansprechen kann? (lange Namen, kurze 8.3-Name, UNC-Pfade, Hardlinks, Softlinks, Verzeichnis/Partition mehrfach gemountet, ...)

Ja das ist mir bekannt. Seltene Exoten landen im Support.

[p80286]

Zitat:

Zitat von QuickAndDirty (Beitrag 1183211)

Mit schreib und lese Rechten für Daten (Ich glaube das geht für die Spezialverzeichnisse nicht).

Zumindestens XP kann das noch.

Zitat:

Zitat von QuickAndDirty (Beitrag 1183211)

Selbst wenn das ginge ist die andere Sache das sich die Clients selbstständig über die Serverfreigabe updaten können. Das Update wird im Bedardsfall beim Start des Clients ausgelöst und das Programmverzeichnis dann kopiert.

Da frage ich mich, wofür ist das gut, es klingt als ob alle 3 Tage ein Update notwendig wäre

Zitat:

Zitat von QuickAndDirty (Beitrag 1183211)

Und natürlich prüfe ich nicht nach Schreibrechten, da das Setup nur mit Administrator rechten ausgeführt werden kann, setze ich direkt Vollzugriffs-Rechte für "Jeder" und gebe den Ordner frei.

Vollzugriff für "Jeder"? Damit macht man sich Freunde.
Aber wo ist dann das Problem?

Zitat:

Zitat von QuickAndDirty (Beitrag 1183211)

Wir erwähnen so ziemlich alles im Setup...leider scheitern wir dennoch daran das der Admin oder "User dem das Admin Passwort bekannt ist" die Informationen die wir Vermitteln möchten auch aufnimmt.
Aber ich arbeite an einem Comic um das vermitteln der Handlungsanweisungen im Setup interessanter zu gestallten.
Zur Zeit scheint der Einzige nutzen von Erklärendem Text und Handlungsanweisungen im Setup darin zu bestehen, dafür zu sorgen das man einem Kunden der sich aufregt RTFM sagen kann...natürlich höflich verklausuliert. Das bleibt dann natürlich trotzdem beim Support hängen und der belästigt mich damit...

Ich agiere manchmal auch als Admin, rate mal wie ich auf ein Comic als Installationsanweisung reagieren werde.

Und "so ziemlich alles" ist nicht alles.
Ich bevorzuge RTFM aber wenn das Handbuch/Installationsanweisung nicht vollständig ist...

Gruß
K-H

[QuickAndDirty]

Zitat:

Zitat von p80286 (Beitrag 1183215)

Zumindestens XP kann das noch.

Cool. Haben die ab Vista damit angefangen?

Zitat:

Zitat von p80286 (Beitrag 1183215)

Da frage ich mich, wofür ist das gut, es klingt als ob alle 3 Tage ein Update notwendig wäre

Es sorgt dafür das ein Update nur einmal auf dem Server eingespielt werden muss, die clients versorgen sich dann selbstständig mit Updates. Das spart Zeit und Kosten, vor allem in Unternehmen die von externen IT-lern abhängig sind. Und es macht das verkaufen eines Updates profitabler, denn es gibt kaum jemand der für das "einspielen" eines Updates bezahlt. In der Regel ist das verschenkter Support.
Aber wir müssen das Problem auf lange sicht sowieso lösen. Und von der dämlichen Freigabe wegkommen. Nur im Moment hängt da ne Menge dran und das sind viele große Aufgaben, nach deren Erledigung wir ein Produkt mit keinem einzigen Feature mehr oder Fehler weniger hätten.

Zitat:

Zitat von p80286 (Beitrag 1183215)

Vollzugriff für "Jeder"? Damit macht man sich Freunde.

Es kommt drauf an.
-Kleine Firmen ohne IT-Fachkraft ziehen daraus nur Vorteile, weil sie oft nicht wissen wie man eine Freigaben macht.
-Firmen mit Internen Adminsitrator sind meist größer und der hat dann Arbeit damit das "Jeder" passgenau anzupassen. Allerdings hat die Software dann funktioniert bevor er an den Rechten gebastelt hat und so erkennt er meist selbstständig das das was nicht geht in seinem Verantwortungsbereich passiert ist und bringt es in Ordnung.
-Firmen mit Externen Administrator sind meist von mittlerer Größe und auch dem machen wir damit die Arbeit das im Nachhinein passgenau zu ändern. Leider gibt es so Amateur externe die nach dem Fire und forget Prinzip arbeiten und natürlich nur Vorort. Wenn dann nach einer Aktion die Rechte weg sind, bekommen in der Regel wir den Anruf.

Zitat:

Zitat von p80286 (Beitrag 1183215)

Aber wo ist dann das Problem?

Das einzige Problem war das ich unter W64Bit die Installation in das Programme verzeichnis nicht verhindern kann.

Zitat:

Zitat von p80286 (Beitrag 1183215)

Ich agiere manchmal auch als Admin, rate mal wie ich auf ein Comic als Installationsanweisung reagieren werde.

Du würdest dich getrieben von der Identifizierung mit dem Hauptcharackter durch die gesammte Anleitung lesen. Und das ansprechen der visiospatialen, den episodischen als auch phonologisch-lingualen Hirnfunktionen würde zu einer leichteren Aufnahme der Information führen. Du würdest dich über diese an die Fähigkeiten des Gehirns angepassten Vermitlungsweise freuen und dich fragen warum nicht das gesammte Programm noch eine Gamifizierung erfahren hat. Wenn du am Ende der Anleitung angekommen wärst, würdest du in Heureka-Rufe ausbrechen und tanzend über den Büroflur wirbeln.

Korrekt antizipiert?

Zitat:

Zitat von p80286 (Beitrag 1183215)

Und "so ziemlich alles" ist nicht alles.

Ja wir fangen zum Teil bei Adam und Eva an. Die Installationsanleitung richtet sich durchaus an User.

Zitat:

Zitat von p80286 (Beitrag 1183215)

Ich bevorzuge RTFM

Meist helfen wir den Usern einfach.
Wir mögen es nur nicht wenn leute persönlich werden. Zum Glück sind die meisten Menschen in der Lage ihre Fragen auf zivilisierte Weise vorzubringen.

Zitat:

Zitat von p80286 (Beitrag 1183215)

aber wenn das Handbuch/Installationsanweisung nicht vollständig ist...

Ich denke nicht das unser Handbuch wirklich vollständig ist. Zumindest würde ich sowas niemals behaupten. Ich kenne allerdings kaum Handbücher die wirklich alle meine Fragen beantworten. Ehrlich gesagt halte ich es sogar für sehr wahrscheinlich das Vollständige Handbücher für Software nicht existieren(Trivialsoftware mal ausgenommen).
Was in der Anleitung wirklich fehlt sind Beispiel Szenarios. So nach Kochbuchmanier.
Noch besser als ein Handbuch wäre eigentlich ein Buch in Form eines Kurses. Haben wir aber nicht.

[p80286]

Zitat:

Zitat von QuickAndDirty (Beitrag 1183387)

Zitat:

Zitat von p80286 (Beitrag 1183215)

Zumindestens XP kann das noch.

Cool. Haben die ab Vista damit angefangen?

keine Ahnung, am Arbeistplatz hab ich noch XP.
Nein warte, ich hab da noch ein 32BitW7, muß mal schauen. Kann aber bis morgen dauern.

Zitat:

Zitat von QuickAndDirty (Beitrag 1183387)

Zitat:

Zitat von p80286 (Beitrag 1183215)

Ich agiere manchmal auch als Admin, rate mal wie ich auf ein Comic als Installationsanweisung reagieren werde.

Du würdest dich getrieben von der Identifizierung mit dem Hauptcharackter durch die gesammte Anleitung lesen. Und das ansprechen der visiospatialen, den episodischen als auch phonologisch-lingualen Hirnfunktionen würde zu einer leichteren Aufnahme der Information führen. Du würdest dich über diese an die Fähigkeiten des Gehirns angepassten Vermitlungsweise freuen und dich fragen warum nicht das gesammte Programm noch eine Gamifizierung erfahren hat. Wenn du am Ende der Anleitung angekommen wärst, würdest du in Heureka-Rufe ausbrechen und tanzend über den Büroflur wirbeln.

Korrekt antizipiert?

OK, wir verstehen uns!:lol::lol:

Gruß
K-H

[Zacherl]

Habe nicht alles durchgelesen, aber vielleicht hilft dir bei deiner Überprüfung im Hauptprogramm die Wow64DisableWow64FsRedirection API. Damit kannst du die WOW64 Redirection temporär für dein Programm deaktivieren.

[musicman56]

@QuickAndDirty

Vieles von dem was du schreibst kommt mir bekannt vor. Ein Grundproblem deiner Vorgehensweise beim Updaten von Clients über's Netzwerk liegt darin, dass die Clients Zugriffsrechte auf den Server brauchen. Ich hab das Problem vor etwa 10 Jahren schon gelöst, indem ich auf dem Server nach der Installation und nach jedem Internet-Update (das vom Server aus via FTP von meinem WEB-Server heruntergeladen wird) ALLE Programmdateien in eine Datenbank (in ein Blob-Feld) einlese, natürlich zusammen mit Datum und Größe in separaten Feldern. Der Client vergleicht dann einfach seine lokal vorhandenen Dateien mit denen in der Datenbank, und wenn eine älter ist, wird mit TBlobField.SaveToFile einfach die Datei aktualisiert. Mit jeder Haupversion ändere ich dann ein Datenfeld in der Datenbank-Struktur und damit verhindere ich dann sogar noch, dass sich Clients mit inkompatibler (älterer) Version im Netzwerk anmelden.

Einziger Nachteil: Ca. 150MB Speicherplatz für die Datenbank, aber ist das wirklich ein Nachteil?

[p80286]

Es sieht so aus, als dürften unter W7(Enterprise) auch Administratoren nicht an der Berechtigung von
C:\Programme drehen, das könnte allerdings auch an den Richtlinien liegen.

Da fehlen mir allerdings die notwendigen Infos.

Gruß
K-H

[QuickAndDirty]

Zitat:

Zitat von musicman56 (Beitrag 1183470)

@QuickAndDirty

Vieles von dem was du schreibst kommt mir bekannt vor. Ein Grundproblem deiner Vorgehensweise beim Updaten von Clients über's Netzwerk liegt darin, dass die Clients Zugriffsrechte auf den Server brauchen. Ich hab das Problem vor etwa 10 Jahren schon gelöst, indem ich auf dem Server nach der Installation und nach jedem Internet-Update (das vom Server aus via FTP von meinem WEB-Server heruntergeladen wird) ALLE Programmdateien in eine Datenbank (in ein Blob-Feld) einlese, natürlich zusammen mit Datum und Größe in separaten Feldern. Der Client vergleicht dann einfach seine lokal vorhandenen Dateien mit denen in der Datenbank, und wenn eine älter ist, wird mit TBlobField.SaveToFile einfach die Datei aktualisiert. Mit jeder Haupversion ändere ich dann ein Datenfeld in der Datenbank-Struktur und damit verhindere ich dann sogar noch, dass sich Clients mit inkompatibler (älterer) Version im Netzwerk anmelden.

Einziger Nachteil: Ca. 150MB Speicherplatz für die Datenbank, aber ist das wirklich ein Nachteil?

Wir machen das bereits so mit Ausnahme des DB teils.
Garantiert wird es niemals passieren das wir alle Unsere Update relevanten dateien in die DB laden.
Aber einen Update Server wird es geben. Nur eben nicht jetzt.