DLL Side-by-side registration & redirection

[Der schöne Günther]

Herzlich Willkommen zu einem spannenden Thema :roteyes:

Warnung: Ich kenne mich nicht wirklich aus. Ich will noch nicht einmal alles verstehen, ich möchte nur etwas hinbekommen.


Eine Delphi-Anwendung verwendet eine ActiveX-Komponente. Bisher musste man hingehen und auf jedem PC mit Adminrechten einmal mit

Delphi-Quellcode:

regsvr32 someLib.dll

diese DLL "registrieren". Und die musste auch an diesem Pfad bleiben!

Ich möchte nun diese tolle "Side-by-side" registration nutzen: Ich kann mir diesen ganzen Registrierungsvorgang komplett sparen wenn ich

• Der DLL
  Delphi-Quellcode:

  someLib.dll

  in ihrem Manifest eine
  Delphi-Quellcode:

  assemblyIdentity

  (sowie ein paar weitere Infos) gebe
• Der Anwendung in ihrem Manifest eine
  Delphi-Quellcode:

  assemblyIdentity

  gebe
• Der Anwendung
  Delphi-Quellcode:

  myApp.exe

  ins Manifest gebe dass sie die DLL
  Delphi-Quellcode:

  someLib.dll

  (genau spezifiziert mit Versionsnummer und allem) verwendet

Fortan brauche ich keine Registrierung mehr. Tolle Sache, das funktioniert wirklich :thumb:


Mich stören die Beschränkungen dass die DLL im gleichen Verzeichnis wie die .exe-Datei liegen muss. Es gibt ein paar weitere Regeln wo sie auch liegen darf, aber ich mag die alle nicht:

Zitat:

The first time side-by-side searches for a private assembly, it determines whether a language-specific subfolder exists in the application's directory structure. If no language-specific subfolder exists, side-by-side searches for the private assembly in the following locations using the following sequence.
Side-by-side searches the WinSxS folder.
\\<appdir>\<assemblyname>.DLL
\\<appdir>\<assemblyname>.manifest
\\<appdir>\<assemblyname>\<assemblyname>.DLL
\\<appdir>\<assemblyname>\<assemblyname>.manifest

Quelle: MSDN: About Isolated Applications and Side-by-side Assemblies > Assembly Searching Sequence


Meine Frage: Gibt es eine Möglichkeit dass ich z.B. die .exe unter

Delphi-Quellcode:

.\myApp.exe

haben kann und die DLL unter

Delphi-Quellcode:

.\fancyLibraries\someDll.dll

oder ist das nicht möglich?

[KodeZwerg]

Zitat:

Zitat von Der schöne Günther (Beitrag 1405470)

Meine Frage: Gibt es eine Möglichkeit dass ich z.B. die .exe unter

Delphi-Quellcode:

.\myApp.exe

haben kann und die DLL unter

Delphi-Quellcode:

.\fancyLibraries\someDll.dll

oder ist das nicht möglich?

Wenn ich das richtig verstehe wäre die Antwort:

Zitat:

It is important to remember that Windows has a strict rule regarding loading DLLs: if the DLL name passed to any of the LoadLibrary* APIs contains a path, even a partial path, Windows will not search for the DLL. It will try the path as requested and quit. If the DLL name contains no path, Windows will try the activation context first then the standard Windows places (application directory, system directories, path etc.)

[Der schöne Günther]

Danke für die Antwort.

Da ist mein Problem dass ich ja im Endeffekt gar nichts mit

Delphi-Quellcode:

LoadLibrary

mache, das tun wohl irgendwelche Delphi-Automatismen im Hintergrund. Wenn ich den Absatz richtig verstehe dann greift die ganze Side-by-side-Geschichte sowieso nicht wenn ich explizit einen Pfad angebe? Wäre schön das auch auf einer offiziellen Microsoft-Seite zu lesen.

[Bernhard Geyer]

SideBySide macht doch nur wirklich Sinn wenn man selbst die DLLs mitliefert und nicht eine DLL nimmt die irgendwo liegt.

[Der schöne Günther]

Tue ich doch. Ich hätte nur immer gerne im Stammverzeichnis nichts außer der .exe-Datei und die .DLL-Dateien alle in einem separaten Unterordner gesammelt. Mehr ist das nicht.

Wahrscheinlich einfach nur Spinnerei, aber ich würde mich trotzdem freuen wenn es geht.

[KodeZwerg]

Zitat:

Zitat von Der schöne Günther (Beitrag 1405475)

Da ist mein Problem dass ich ja im Endeffekt gar nichts mit

Delphi-Quellcode:

LoadLibrary

mache, das tun wohl irgendwelche Delphi-Automatismen im Hintergrund.

Nur eine Überlegung, in was auch immer für Unterordner, was passiert wenn Du dann RegSvr32/TRegSvr darauf loslässt?
Also SxS so wie Du es bereits machst nur die Typbibliothekregistrierung umverfrachten.

edit
Wobei, wenn ich das aus meinem Link da oben richtig verstehe, der Unterordner sich im %PATH% befinden sollte.

[EWeiss]

Zitat:

Mich stören die Beschränkungen dass die DLL im gleichen Verzeichnis wie die .exe-Datei liegen muss. Es gibt ein paar weitere Regeln wo sie auch liegen darf, aber ich mag die alle nicht:

Keine DLL muss im EXE Pfad liegen wenn du es nicht willst.
Vorausgesetzt man macht es richtig.

Was hier abgeht ist letztendlich nur Raten und ein Glücksspiel, geht dies geht das.
Wenn ich ein DLL außerhalb meines Anwendungspfad verwenden will dann setze ich die Umgebung und gut ist.

Zitat:

Wahrscheinlich einfach nur Spinnerei, aber ich würde mich trotzdem freuen wenn es geht.

Klar geht das wenn du wie schon gesagt die Umgebung setzt. (setzen kannst)

Ist das gleiche wie mit der Bass.dll da wird auch immer gesagt sie muss sich im EXE Pfad befinden das ist aber absoluter quatsch.
Sie darf nur nicht in den System Pfad verlegt werden weil sich die Versionen unterscheiden und andere Anwendungen dann nicht mehr laufen.
Auch meine DLL Bass_Vis lege ich nicht im Anwendungspfad genauso wenig wie im Pfad der Bass.DLL

MeinPfad\Player.exe
MeinPfad\Bass_Lib\Bass.dll
MeinPfad\Bass_ADDOn\Bass_Vis.dll
MeinPfad\Bass_ADDOn\bass_fx.dll

Du siehst also ich habe auch eine Struktur angelegt wo ich meine DLL's ablege.
Ich mag es genauso wenig wie du wenn alles im Anwendungspfad geklatscht wird.
Also du bist der Boss deiner Anwendung und legst selber fest wo sich deine DLL's befinden sollen.

gruss

[KodeZwerg]

Emil, er benutzt nicht LoadLibrary() wie Du mit Bass.dll. Was er beschreibt ordne ich eher .OCX (ActiveX) zu.

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1405495)

Emil, er benutzt nicht LoadLibrary() wie Du mit Bass.dll. Was er beschreibt ordne ich eher .OCX (ActiveX) zu.

Ich verwende kein LoadLibrary wer sagt dir das? ;)

Das einzige Problem das er haben könnte wenn er die Umgebung setzt das der seltsame Compiler von Delphi die DLL selber lädt bevor er die Umgebung setzen kann.
Wenn also die DLL dann nicht gefunden wird startet das Programm erst gar nicht.
VB zum Beispiel tut das nicht.

Beispiel:

Delphi-Quellcode:

var
  MeinDLLPath: string;

begin

  MeinDLLPath := ExtractFilePath(ParamStr(0)) + 'Meine_Lib';
  SetEnvironmentVariable(PWideChar('Path'), PWideChar(MeinDLLPath));
  if not FileExists(ExtractFilePath(ParamStr(0)) + 'Meine_Lib\Meinelib.dll') then
    Halt;
end;

Ich befürchte aber das es trotz meiner Aussage bedingt durch den Compiler von Delphi nicht funktionieren wird wenn es keinen Schalter gibt
der verhindert das die Anwendung sich beendet wenn die DLL nicht gefunden wird bevor man die Umgebung setzen kann.

Zumindest unter VB gibt es diesbezüglich keine Probleme ohne LoadLibrary.
Vielleicht kann man das umgehen wenn man vorher eine Batchdatei erstellt. (nicht getestet)

gruss

[EWeiss]

Hier ein Beispiel in Sharp..
Von meinem BassVis Example in C# (Sharp) :lol:

Code:

private void BassInit()
{
  string BassPath;
  string BassVisPath;
  BASS_DEVICEINFO info;

  BassPath = Path.Combine(Application.StartupPath, "BassLib");
  Win32Api.SetEnvironmentVariable("Path", BassPath);

  // check the correct BASS was loaded
  if (Win32Api.HiWord(Bass.BASS_GetVersion()) != Bass.BASSVERSION)
  {
    MessageBox.Show("BASS_Vis.DLL existiert nicht!", "", MessageBoxButtons.OK, MessageBoxIcon.Error);
    Application.Exit();
  }

  //Set Path to AddOns
  BassVisPath = Path.Combine(Application.StartupPath, "BassADDOn");

  Win32Api.SetEnvironmentVariable("Path", BassVisPath);

  //Check "bass_Vis.dll" exist

  string visDll = Path.Combine(Application.StartupPath, @"BassADDOn\bass_Vis.dll");

  if (!File.Exists(visDll))
  {
    MessageBox.Show("BASS_Vis.DLL failed to load!", "BASS_Vis.DLL", MessageBoxButtons.OK, MessageBoxIcon.Error);
    Application.Exit();
  }

  // setup recording and output devices (using default devices)
  if ((Bass.BASS_RecordInit(-1) == false) || (Bass.BASS_Init(-1, 44100, 0, Handle, Guid.Empty) == false))
  {
    MessageBox.Show("Can\'t initialize device", "BASS.DLL", MessageBoxButtons.OK, MessageBoxIcon.Error);
    Application.Exit();
  }
  else
  {
    input_ = 0;
    info = new BASS_DEVICEINFO();
    while (Bass.BASS_RecordGetDeviceInfo(input_, info))
    {
      Bass.BASS_RecordGetDeviceInfo(input_, info);
      cmbInputs.Items.Add(info.name);
      input_++;
    }
    cmbInputs.SelectedIndex = 0;
  }

  Text = "Bass_Vis Example for C# VS2012:  BassVis Version: " + BassVis.BASSVIS_GetVersion();
  Width = 498;
}

#endregion BassInit()

Ich setze die Umgebung nur für diese Anwendung nicht global von außen kann das also niemand sehen.
Die Anwendung startet ohne zu murren und die DLL's werden gefunden.

Und nein die DLL's werden nicht dynamisch geladen.
Ich glaube aber das Problem ist Delphi in dem Fall.

Zitat:

das tun wohl irgendwelche Delphi-Automatismen im Hintergrund.

gruss