Manifest+MFC80.dll = neue DLL-Hölle?

[Holger Gothan]

Hi,

da ich mir ganz fest vorgenommen habe, dieses Jahr noch auf
VS2005 umzusteigen (genaugenommen nehme ich mir jedes Jahr
vor, von VS6 umzusteigen) hätte ich gleich mal eine Frage zur
Verteilung der MFC-DLLs.

In einem der letzten Threads war auch ein guter Link zum Thema
angegeben:

http://www.codeproject.com/cpp/vcredists_x86.asp

Da ich auch noch einen alten Installer verwende (und weiterverwenden muß),
habe ich sicherlich keine andere Wahl, als die neuen MFC-DLLs
im Applikationsordner unterzubringen. Was mit Hilfe obigen Links auch
möglich ist.
Nun habe ich gelesen, dass diese lokalen DLLs ignoriert werden, wenn
an der "offiziellen" Stelle die MFC-Dlls existieren. Ich dachte immer, dass
das Laden von DLLs die Aufgabe des OS ist und seit W98(?) zuerst im
App-Ordner nachgesehen wird - Wieso ist es jetzt für die MFC-DLLs anders?

Ich vermute mal, dass man die Manifest-Geschichte eingeführt hat, damit
zueinander kompatible DLL-Versionen generell von einem definierten Ort
geladen werden, so dass Bugfixe etc. zentral erfolgen können. (Siehe
Problematik mit der GDI+-DLL und WMF-Fehler).

Ein kleines Problem sehe ich dabei:
Wer garantiert eigentlich, dass die Versionen tatsächlich zueinander
kompatibel
sind? Kann es nicht wieder passieren, dass inkompatible MFC-DLLs
geladen werden, da ich ja keine echte Kontrolle mehr darüber habe, dass
meine
"getesteten" und im App-Ordner vorhandene MFC-DLL verwendet wird?

Tschüß, Holger.

[Jochen Kalmbach [MVP]]

Hallo Holger!

> Nun habe ich gelesen, dass diese lokalen DLLs ignoriert werden, wenn
> an der "offiziellen" Stelle die MFC-Dlls existieren. Ich dachte immer, dass
> das Laden von DLLs die Aufgabe des OS ist und seit W98(?) zuerst im
> App-Ordner nachgesehen wird - Wieso ist es jetzt für die MFC-DLLs anders?

Das hat primär nichts mit MFC DLLs zu tun, sondern betrifft alle DLLs,
die sich im SxS-Ordner befinden.

> Ich vermute mal, dass man die Manifest-Geschichte eingeführt hat, damit
> zueinander kompatible DLL-Versionen generell von einem definierten Ort
> geladen werden, so dass Bugfixe etc. zentral erfolgen können. (Siehe
> Problematik mit der GDI+-DLL und WMF-Fehler).

Unter anderem...

> Ein kleines Problem sehe ich dabei:
> Wer garantiert eigentlich, dass die Versionen tatsächlich zueinander
> kompatibel
> sind?

MS ;-))))) ROFL

> Kann es nicht wieder passieren, dass inkompatible MFC-DLLs
> geladen werden, da ich ja keine echte Kontrolle mehr darüber habe, dass
> meine
> "getesteten" und im App-Ordner vorhandene MFC-DLL verwendet wird?

Such doch mal nach Problemen von einzelnen Benutzern, nachdem Hotfixes
eingespielt wurden...

Greetings
Jochen

PS: Meine Empfehlung: statisch linken
Wenn Du allerdings /clr verwendest geht dies nicht und Du bistr auf die
DLLs angewiesen.

[Andre Stille [MVP]]

Hallo!
"Holger Gothan" <hol...@friedrich-datentechnik.de> schrieb im Newsbeitrag
news:4c8bkpF...@individual.net...

> Nun habe ich gelesen, dass diese lokalen DLLs ignoriert werden, wenn
> an der "offiziellen" Stelle die MFC-Dlls existieren. Ich dachte immer,
> dass
> das Laden von DLLs die Aufgabe des OS ist und seit W98(?) zuerst im
> App-Ordner nachgesehen wird - Wieso ist es jetzt für die MFC-DLLs anders?

Man kann das "alte" Laden von DLLs erzwingen, in dem man eine .local-
Datei anlegt (MyApp.exe.local). Der Inhalt der Datei ist völlig egal.

>
> Ich vermute mal, dass man die Manifest-Geschichte eingeführt hat, damit
> zueinander kompatible DLL-Versionen generell von einem definierten Ort
> geladen werden, so dass Bugfixe etc. zentral erfolgen können. (Siehe
> Problematik mit der GDI+-DLL und WMF-Fehler).
>

Ja, siehe das Kapitel über Isolated Applications and Side-by-Side Assemblies
in der MSDN.

> Ein kleines Problem sehe ich dabei:
> Wer garantiert eigentlich, dass die Versionen tatsächlich zueinander
> kompatibel
> sind? Kann es nicht wieder passieren, dass inkompatible MFC-DLLs
> geladen werden, da ich ja keine echte Kontrolle mehr darüber habe, dass
> meine
> "getesteten" und im App-Ordner vorhandene MFC-DLL verwendet wird?
>

Kurz gesagt: Über das Manifest deiner Applikation hast Du volle Kontrolle
darüber, welche DLLs verwendet werden.

Such mal in der MSDN nach "Fixing an Existing Application Using a Private
Assembly", dort ist anhand eines Beispiels beschrieben, wie man eine
Applikation zwingen kann, bestimmte DLLs aus dem Applikationsverzeichnis
zu laden.

MfG
Andre Stille

[Holger Gothan]

Hi,

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> schrieb im
Newsbeitrag news:%238xci6n...@TK2MSFTNGP05.phx.gbl...

> Hallo Holger!
> > Nun habe ich gelesen, dass diese lokalen DLLs ignoriert werden, wenn
> > an der "offiziellen" Stelle die MFC-Dlls existieren. Ich dachte immer,
dass
> > das Laden von DLLs die Aufgabe des OS ist und seit W98(?) zuerst im
> > App-Ordner nachgesehen wird - Wieso ist es jetzt für die MFC-DLLs
anders?
>
> Das hat primär nichts mit MFC DLLs zu tun, sondern betrifft alle DLLs,
> die sich im SxS-Ordner befinden.

Wer verursacht aber dieses neue Verhalten? XP???
d.h. Je nach OS doch ein anderes Verhalten?
W95: immer zuerst System-ordner (ok, hat sich erledigt, da keine
Unterstützung mehr)
>W98: zuerst im App-Ordner
XP: zuerst im SxS-Ordner???

> > Ich vermute mal, dass man die Manifest-Geschichte eingeführt hat, damit
> > zueinander kompatible DLL-Versionen generell von einem definierten Ort
> > geladen werden, so dass Bugfixe etc. zentral erfolgen können. (Siehe
> > Problematik mit der GDI+-DLL und WMF-Fehler).
>
> Unter anderem...
>
>
> > Ein kleines Problem sehe ich dabei:
> > Wer garantiert eigentlich, dass die Versionen tatsächlich zueinander
> > kompatibel
> > sind?
>
> MS ;-))))) ROFL
> > Kann es nicht wieder passieren, dass inkompatible MFC-DLLs
> > geladen werden, da ich ja keine echte Kontrolle mehr darüber habe, dass
> > meine
> > "getesteten" und im App-Ordner vorhandene MFC-DLL verwendet wird?
>
> Such doch mal nach Problemen von einzelnen Benutzern, nachdem Hotfixes
> eingespielt wurden...
>

ist das jetzt ein klares JA - also wieder DLL-Hölle?
Dann wird sich das Verhalten mit einer nächsten Version sicherlich wieder
ändern???

Tschüß, Holger.

[Jochen Kalmbach [MVP]]

Hallo Holger!

>> Das hat primär nichts mit MFC DLLs zu tun, sondern betrifft alle DLLs,
>> die sich im SxS-Ordner befinden.
>
> Wer verursacht aber dieses neue Verhalten? XP???

Ja. Erst ab OSen die das SxS kennen (also XP und w2k3).

> d.h. Je nach OS doch ein anderes Verhalten?

Ja; wobei bei W2k es kein SxS gibt...

> ist das jetzt ein klares JA - also wieder DLL-Hölle?

IMHO: Ja.

> Dann wird sich das Verhalten mit einer nächsten Version sicherlich wieder
> ändern???

Ich glaube die bleiben bei *dieser* Hölle...

Greetings
Jochen

[Jochen Kalmbach [MVP]]

Hallo Andre!

>> Nun habe ich gelesen, dass diese lokalen DLLs ignoriert werden, wenn
>> an der "offiziellen" Stelle die MFC-Dlls existieren. Ich dachte immer,
>> dass
>> das Laden von DLLs die Aufgabe des OS ist und seit W98(?) zuerst im
>> App-Ordner nachgesehen wird - Wieso ist es jetzt für die MFC-DLLs anders?
>
> Man kann das "alte" Laden von DLLs erzwingen, in dem man eine .local-
> Datei anlegt (MyApp.exe.local). Der Inhalt der Datei ist völlig egal.

Hast Du es probiert?
Das geht mit SxS nicht mehr... nur bei OS vor SxS-Support (also vor XP).

>> Ich vermute mal, dass man die Manifest-Geschichte eingeführt hat, damit
>> zueinander kompatible DLL-Versionen generell von einem definierten Ort
>> geladen werden, so dass Bugfixe etc. zentral erfolgen können. (Siehe
>> Problematik mit der GDI+-DLL und WMF-Fehler).
>>
>
> Ja, siehe das Kapitel über Isolated Applications and Side-by-Side Assemblies
> in der MSDN.
>
>> Ein kleines Problem sehe ich dabei:
>> Wer garantiert eigentlich, dass die Versionen tatsächlich zueinander
>> kompatibel
>> sind? Kann es nicht wieder passieren, dass inkompatible MFC-DLLs
>> geladen werden, da ich ja keine echte Kontrolle mehr darüber habe, dass
>> meine
>> "getesteten" und im App-Ordner vorhandene MFC-DLL verwendet wird?
>>
>
> Kurz gesagt: Über das Manifest deiner Applikation hast Du volle Kontrolle
> darüber, welche DLLs verwendet werden.

Kannst Du mir mal ein Beispiel schicken, wie man diese Manifest-Datei
macht, damit es garantiert ist, dass es aus dem AppLocal-Verzeichnis
genommen wird?
Ich habe es nicht hinbekommen.

Greetings
Jochen

[Andre Stille [MVP]]

Hallo!

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> schrieb im

Newsbeitrag news:erJr33oc...@TK2MSFTNGP04.phx.gbl...

>>
>> Man kann das "alte" Laden von DLLs erzwingen, in dem man eine .local-
>> Datei anlegt (MyApp.exe.local). Der Inhalt der Datei ist völlig egal.
>
> Hast Du es probiert?
> Das geht mit SxS nicht mehr... nur bei OS vor SxS-Support (also vor XP).
>

.local geht auch noch bei XP, anscheinend aber nur, wenn zum geladenen
Modul kein Manifest existiert. Dummerweise steht das aber in dem
MSDN-Artikel nicht drin.

>>
>> Kurz gesagt: Über das Manifest deiner Applikation hast Du volle Kontrolle
>> darüber, welche DLLs verwendet werden.
>
> Kannst Du mir mal ein Beispiel schicken, wie man diese Manifest-Datei
> macht, damit es garantiert ist, dass es aus dem AppLocal-Verzeichnis
> genommen wird?
> Ich habe es nicht hinbekommen.
>

Im Applikations-Manifest ändert man den Namen des MFC-Assemblies auf
irgendwas eigenes (z.B. PrivateMFC) und da es sich um ein privates
und kein shared-Assembly handelt, muss das publicKeyToken gelöscht
werden.

Das Manifest für die lokalen MFC-DLLs (PrivateMFC.Manifest) sieht
dann so aus:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity type="win32" name="PrivateMFC" version="8.0.50608.0"
processorArchitecture="x86"/>
<file name="mfc80.dll" />
<file name="mfc80u.dll" />
<file name="mfcm80.dll" />
<file name="mfcm80u.dll" />
</assembly>

Hier wurde das publicKeyToken und die Hash-Werte für die DLLs weggelassen
sowie die Versionsnummer geändert, welches sonst ja die Policy-Datei
macht. Man kann sicherlich auch die Versionsnummer aus dem ursprünglichen
Assembly übernehmen und dann per .Config-Datei das Ummappen der Versions-
nummer erledigen.

MfG
Andre Stille

[Jochen Kalmbach [MVP]]

Hallo Andre!
> ..local geht auch noch bei XP, anscheinend aber nur, wenn zum geladenen
> Modul kein Manifest existiert.

Ja.

>> Ich habe es nicht hinbekommen.
>
> Im Applikations-Manifest ändert man den Namen des MFC-Assemblies auf
> irgendwas eigenes (z.B. PrivateMFC) und da es sich um ein privates
> und kein shared-Assembly handelt, muss das publicKeyToken gelöscht
> werden.
>
> Das Manifest für die lokalen MFC-DLLs (PrivateMFC.Manifest) sieht
> dann so aus:
>
> <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
> <assemblyIdentity type="win32" name="PrivateMFC" version="8.0.50608.0"
> processorArchitecture="x86"/>
> <file name="mfc80.dll" />
> <file name="mfc80u.dll" />
> <file name="mfcm80.dll" />
> <file name="mfcm80u.dll" />
> </assembly>
>
> Hier wurde das publicKeyToken und die Hash-Werte für die DLLs weggelassen
> sowie die Versionsnummer geändert, welches sonst ja die Policy-Datei
> macht. Man kann sicherlich auch die Versionsnummer aus dem ursprünglichen
> Assembly übernehmen und dann per .Config-Datei das Ummappen der Versions-
> nummer erledigen.

Hmm... das muss ich mal probieren...
Ist aber nicht das Problem, dass die MFC-DLLs auf die existenz des
"korrekten" MFC-Manifests achten und wenn dies nicht mit genau dem
passenden Namen da ist, das laden verweigern?

Hast Du mal ein vollständiges Beispiel?
Wäre echt interessant! Die Frage ob man die MFC/CRT DLLs nämlich ohne
SxS beeinflussung verwenden kann ist nämlich IMHO immer noch nicht gelöst...

Greetings
Jochen

[Martin Richter [MVP]]

Hallo Jochen!

> Hmm... das muss ich mal probieren...
> Ist aber nicht das Problem, dass die MFC-DLLs auf die existenz des
> "korrekten" MFC-Manifests achten und wenn dies nicht mit genau dem
> passenden Namen da ist, das laden verweigern?
>
> Hast Du mal ein vollständiges Beispiel?
> Wäre echt interessant! Die Frage ob man die MFC/CRT DLLs nämlich ohne
> SxS beeinflussung verwenden kann ist nämlich IMHO immer noch nicht
> gelöst...

Vor allem könnte man dann _rein_ lokal instalieren.

--
Martin Richter [MVP] WWJD
"In C we had to code our own bugs. In C++ we can inherit them."
FAQ : http://www.mpdvc.de
Samples: http://www.codeguru.com http://www.codeproject.com

[Andre Stille [MVP]]

Hallo!

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> schrieb im

Newsbeitrag news:ufGaex0c...@TK2MSFTNGP03.phx.gbl...

>
> Hmm... das muss ich mal probieren...
> Ist aber nicht das Problem, dass die MFC-DLLs auf die existenz des
> "korrekten" MFC-Manifests achten und wenn dies nicht mit genau dem
> passenden Namen da ist, das laden verweigern?
>

Nein, die MFC-DLLs machen das nicht. Der Knackpunkt ist die CRT-DLL,
die einen solchen Check hat. Allerdings ist es so, daß die CRT-DLL
zulässt, sie als privates Assembly zu laden, einzige Bedingung ist,
daß sich der Name nicht ändert.

SxS stört sich nicht daran, wenn ein shared und ein privates
Assembly mit gleichem Namen existiert. Wenn im Manifest kein
publicKeyToken da ist, wird das private Assembly genommen.

> Hast Du mal ein vollständiges Beispiel?

Das ist ein bisschen lang, um es als Text zu posten. Ich werde
die Tage mal ein Zip draus machen und es irgendwo hochladen.

> Wäre echt interessant! Die Frage ob man die MFC/CRT DLLs nämlich ohne SxS
> beeinflussung verwenden kann ist nämlich IMHO immer noch nicht gelöst...
>

Ein Punkt gibt es noch und der ist zunächst mal nicht zu verhindern:
Die MFC hat in ihren Resourcen ein Manifest zum Laden der MFC-Sprach-DLL,
da kann man auch nichts dran rütteln. Existiert das Assembly, so wird
die entsprechende DLL aus dem WinSxS-Ordner geladen. Natürlich kann man
in der InitInstance dann die DLL wieder entladen und die eigene laden.
Existiert das Assembly nicht, so wird vom System die "alte" LoadLibrary-
Suchstrategie genommen.

MfG
Andre Stille

[Martin Richter [MVP]]

Hallo Andre Stille [MVP]!

> Nein, die MFC-DLLs machen das nicht. Der Knackpunkt ist die CRT-DLL,
> die einen solchen Check hat. Allerdings ist es so, daß die CRT-DLL
> zulässt, sie als privates Assembly zu laden, einzige Bedingung ist,
> daß sich der Name nicht ändert.

Das habe ich gestern versucht. Ich habe ein eigenes Assembly Manifest
gemacht und auch die 8.0 CRT DLL's lokal gepackt.

Mein Problem war, das automatisch durch das linken immer das normale
Manifest für die CRT mit eingebunden wurde. Und das konnte ich nicht
verhindern. Resultat: Zwei DLLs mit selben Namen in einer Applikation
verweigert der Lader wenn für beide ein Manifest vorliegt.

[Jochen Kalmbach [MVP]]

Hallo Martin!

>> Nein, die MFC-DLLs machen das nicht. Der Knackpunkt ist die CRT-DLL,
>> die einen solchen Check hat. Allerdings ist es so, daß die CRT-DLL
>> zulässt, sie als privates Assembly zu laden, einzige Bedingung ist,
>> daß sich der Name nicht ändert.
>
> Das habe ich gestern versucht. Ich habe ein eigenes Assembly Manifest
> gemacht und auch die 8.0 CRT DLL's lokal gepackt.
>
> Mein Problem war, das automatisch durch das linken immer das normale
> Manifest für die CRT mit eingebunden wurde. Und das konnte ich nicht
> verhindern.

Das einbinden kannst Du aber ganz einfach verhindern, indem Du es sagt,
dass Du es nicht eingebunden haben willst (Projekt-Settings|Manifest).
Dann wird eine externe manifest-Datei erzeugt, und diese kannst Du dann
beliebig verändern!
Das ist natürlich die Voraussetzung für das ganze ;-)

Greetings
Jochen

[Martin Richter [MVP]]

Hallo Jochen!

> Das ist natürlich die Voraussetzung für das ganze ;-)

Jo. OK! Werde ich heute Abend noch mal probieren.

D.h. irgendwo in der LIB für die CRT wird ein
#pragma comment(linker, "\"/manifestdependency:type='Win32'
name='irgendwas' ...")
eingebaut.

Echt lästig... :-)

[Andre Stille [MVP]]

Hallo!

"Martin Richter [MVP]" <martin....@mvps.org> schrieb im Newsbeitrag
news:e3s632...@news.grutzeck.de...

>
> Mein Problem war, das automatisch durch das linken immer das normale
> Manifest für die CRT mit eingebunden wurde. Und das konnte ich nicht
> verhindern. Resultat: Zwei DLLs mit selben Namen in einer Applikation
> verweigert der Lader wenn für beide ein Manifest vorliegt.
>

Was der Linker macht, ist irrelevant. Wenn das Manifest der Applikation
in Form einer externen Datei vorliegt, so wird dieses genommen und das
Resourcen-Manifest ignoriert.

Wenn der Lader rummeckert, dann stimmt irgendwas nicht an deinen
Manifest-Dateien. Ich kenne leider keinen Weg, wie man den Lader
dazu überreden kann, einem mitzuteilen, was er nicht mag.

Achte auf die Versionsnummern in den Applikations- und in den CRT/
MFC-Manifests sowie das alle Assemblies, die im Resourcen-Manifest
auftauchen auch in dem externen Applikations-Manifest vorhanden sind.

MfG
Andre Stille

[Martin Richter [MVP]]

Hallo Andre!

> Was der Linker macht, ist irrelevant. Wenn das Manifest der Applikation
> in Form einer externen Datei vorliegt, so wird dieses genommen und das
> Resourcen-Manifest ignoriert.

Ich habe meinem Projekt eine eigene manifest Datei hinzugefügt und
verwende keine Ressourcen. Meine Manifestdatei hat der Linker mit den
Dependencies aus dem Projekt zusammengemauschelt.

> Wenn der Lader rummeckert, dann stimmt irgendwas nicht an deinen
> Manifest-Dateien. Ich kenne leider keinen Weg, wie man den Lader
> dazu überreden kann, einem mitzuteilen, was er nicht mag.

Das Ereignisprotokoll gibt mehr schlecht als recht etwas Auskunft.

[Andreas Heyer]

Hallo NG,

in vergangenen Tagen wurde immer gerne auf VC-FAQ unter
http://www.mpdvc.de/html.htm verwiesen. Deren Stand ist aber Dez. 2004.
Heute kommt der Hinweis auf Codeproject oder Codeguru.
Könnte sich aber trotzdem jemand veranlaßt fühlen, die unterschiedlichen
Manifest-Lösungen in der FAQ zusammenzutragen, oder einen
Codeproject-Artikel zu schreiben?
Ich habe noch kein VC 2005, deshalb kann ich es nicht selbst machen.
*frech grins*
Ich denke aber, auch für die Express-Version wären diese Infos ganz
hilfreich, und vielleicht kommt ja auch was Nützliches für VS 2003 dabei
raus.

MfG
Andreas

[Alwin Belschner]

Hallo Martin,

(auch auf die Gefahr hin dass das ein alter Hut für euch ist...)
du kannst dir direkt in der exe anschauen, welche manifests er eingebunden
hat und
wie die aussehen. lade deine exe mit dem Studio 2005 mit file open, dann
siehst du
alle infos in einem Tree view. Wenn dich diverse manifests stören kannst du
diese auch
entfernen die exe speichern und dann testen was passiert. auf diese weise
habe ich zumindest
herausgefunden, wie meine manifests auszusehen haben, vorallem welche der
compiler von sich
aus bereits einbindet ohne dass man selbst hand anlegt.

Gruss Alwin

[Martin Richter [MVP]]

Hallo Alwin!

> (auch auf die Gefahr hin dass das ein alter Hut für euch ist...)

Ist es... SCNR

> du kannst dir direkt in der exe anschauen, welche manifests er eingebunden

> hat und...
[snip]

Nein! Das Problem ist ein anderes. Bau ein simple "Hello world" C
Programm, dass die CRT aei der 8.0 verwendet. In diesem Fall bekommt der
Linker automatisch eine Instruktion einen entsprechende Assembly
Dependancy zu erzeugen. Und das ist schon ein Problem... Man kann dann
das Manifest nicht mehr automatisch erzeugen lassen, weil immer die
Infos aus der CRT eine Dependancy zur Original-CRT erzeugen...

[Martin Richter [MVP]]

Hallo Alwin!

> (auch auf die Gefahr hin dass das ein alter Hut für euch ist...)

Ist es... SCNR

> du kannst dir direkt in der exe anschauen, welche manifests er eingebunden

> hat und...
[snip]

Nein! Das Problem ist ein anderes. Bau ein simple "Hello world" C
Programm, dass die CRT aei der 8.0 verwendet. In diesem Fall bekommt der
Linker automatisch eine Instruktion einen entsprechende Assembly
Dependancy zu erzeugen. Und das ist schon ein Problem... Man kann dann
das Manifest nicht mehr automatisch erzeugen lassen, weil immer die
Infos aus der CRT eine Dependancy zur Original-CRT erzeugen...

[Alwin Belschner]

Hallo Martin,
jetzt habt ihr mich verwirrt. Korrigiert mich bitte wenn ich da völlig
falsch liege.
Meiner Meinung nach beseitigt gerade das Manifest das DLL (-Hell) Problem.
In dem man die Version in den dependency's angibt (assembly identity
version=xxx) läuft man nicht Gefahr,
dass die falsche DLL verwendet wird. Ist die DLL nicht in dieser Version
vorhanden, dann startet die App nicht.
Probiers einfach mal aus, setze im deinem Manifest einer andere Version ein
und die App startet nicht.
Leider gibt das ne unverständliche Meldung dem Anwender aus, dass er die App
neu installieren soll.
Werden zusätzlich neuere DLL's (z.B. CRT) installiert, so stört das nicht,
da die alten wegen SxS erhalten bleiben.
Deine App sollte dadruch viel sicherer laufen. hoffe ich doch. Das gilt
natuerlich auch für die eigenen DLL's.

Gruss Alwin

"Martin Richter [MVP]" <martin....@mvps.org> schrieb im Newsbeitrag

news:e3spap...@news.grutzeck.de...

[Holger Gothan]

Hi,

"Alwin Belschner" <Alwin.B...@boschrexroth.de> schrieb im Newsbeitrag
news:e3st5g$9vj$1...@ns2.fe.internet.bosch.com...

> Hallo Martin,
> jetzt habt ihr mich verwirrt. Korrigiert mich bitte wenn ich da völlig
> falsch liege.
> Meiner Meinung nach beseitigt gerade das Manifest das DLL (-Hell) Problem.

...

das Problem dass ich sehe liegt im Versionsnummernmapping
für "kompatible" Versionen. Wenn das analog zur mfc42.dll geschieht,
dann gute Nacht.

Sofern sich auch nur die geringste Inkompatibilität einschleicht, dann ist
man in
der Hölle angekommen und kommt wie zu seeligen W95-Zeiten auch nicht mehr
raus.
Und ich denke nicht, dass das Versionsmapping immer "richtig" gemacht werden
wird.

Tschüß, Holger.

[Alwin Belschner]

> das Problem dass ich sehe liegt im Versionsnummernmapping
> für "kompatible" Versionen. Wenn das analog zur mfc42.dll geschieht, dann
gute Nacht.

was für ein Mapping meinst du denn?
Die Version ist eindeutig, z.B. 8.0.50727.42
wenn du die im Manifest festlegst wird nur die und keine andere geladen.

> Sofern sich auch nur die geringste Inkompatibilität einschleicht, dann ist
man in
> der Hölle angekommen und kommt wie zu seeligen W95-Zeiten auch nicht mehr
> raus. Und ich denke nicht, dass das Versionsmapping immer "richtig"
gemacht werden
> wird.

damit kann sich auch keine Incompatibilität einschleichen. Ausser irgend ein
Spassvogel
erstellt ne geänderte MFC DLL mit der selben Version, und überschreibt die
vorhandene.
aber das ist doch mutwillig. oder?

[Jochen Kalmbach [MVP]]

Hallo Alwin!

>> das Problem dass ich sehe liegt im Versionsnummernmapping
>> für "kompatible" Versionen. Wenn das analog zur mfc42.dll geschieht, dann
> gute Nacht.
> was für ein Mapping meinst du denn?
> Die Version ist eindeutig, z.B. 8.0.50727.42
> wenn du die im Manifest festlegst wird nur die und keine andere geladen.

Da täuschst Du Dich... ist Dir schon mal aufgefallen, dass die Version
der CRT-DLL von VC8, welche in Deiner Manifest-Datei definiert ist
*nicht* mit der CRT-DLL-Version übereinstimmt???

Das ganze wird durch eine "manifest-policy" gesteuert...
Und da steht z.B. drin:

<assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
<bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
newVersion="8.0.50727.42"/>

Beachte den Eintrag "bindingRedirect" mit "oldVersion" und "newVersion".

> damit kann sich auch keine Incompatibilität einschleichen. Ausser irgend ein
> Spassvogel erstellt ne geänderte MFC DLL mit der selben Version, und überschreibt die
> vorhandene. aber das ist doch mutwillig. oder?

Naja, Du gehst halt davon aus, das MS bei einem Security-Update (für das
ist das mit dem policy-redirect hauptsächlich gedacht) keine Fehler macht.
Aber das vorletzte Security-Update von MS (bzgl. OS) zeigt leider ein
anderes Bild... MS macht Fehler und nach dem Update laufen einige
Programme nicht mehr korrekt.

Aus diesem Grunde wäre es sehr hilfreich, wenn man *wirkliche* Private
Assemblies verwenden könnte.
Aber ich habe es bis heute noch nicht geschafft...

Greetings
Jochen

[Alwin Belschner]

Hallo Jochen ,

vielen dank für die Infos.

> Da täuschst Du Dich... ist Dir schon mal aufgefallen, dass die Version
> der CRT-DLL von VC8, welche in Deiner Manifest-Datei definiert ist
> *nicht* mit der CRT-DLL-Version übereinstimmt???

das ist schon richtig. meiner Meinung nach sollte dich aber nicht stören,
denn es gibt unter dem manifest nur diese eine und die bleibt gleich.

> Das ganze wird durch eine "manifest-policy" gesteuert...
> Und da steht z.B. drin:
>
> <assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
> processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
> <bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
> newVersion="8.0.50727.42"/>
>
> Beachte den Eintrag "bindingRedirect" mit "oldVersion" und "newVersion".

Das habe ich nicht gewusst. das ist natuerlich schlecht. ich habe eben bei
mir gesucht,
bei gibt es leider bisher kein solches policy, deswegen ist mir das auch
noch nicht aufgefallen.
Gut das ich das jetzt weiss, ich bin wohl zu naiv ran gegangen.

> Aus diesem Grunde wäre es sehr hilfreich, wenn man *wirkliche* Private
> Assemblies verwenden könnte.

Das habe ich schon mal gemacht. Ich habe es aber nur hinbekommen, wenn keine
gültige Version im SxS verfügbar war. dann hat er die lokale geladen.
dann habe ich allerdings aufgehört, weil ich mir sicher war, dass über die
Version
sichergestellt ist, dass es hinhaut. ich schau noch mal nach, ob ich es auch
hinbekomme
auch wenn die passende im System verfügbar ist.

Vielen Dank
Gruss Alwin

[Jochen Kalmbach [MVP]]

Hallo Alwin!

>> Das ganze wird durch eine "manifest-policy" gesteuert...
>> Und da steht z.B. drin:
>>
>> <assemblyIdentity type="win32" name="Microsoft.VC80.CRT"
>> processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>
>> <bindingRedirect oldVersion="8.0.41204.256-8.0.50608.0"
>> newVersion="8.0.50727.42"/>
>>
>> Beachte den Eintrag "bindingRedirect" mit "oldVersion" und "newVersion".
> Das habe ich nicht gewusst. das ist natuerlich schlecht. ich habe eben bei
> mir gesucht,
> bei gibt es leider bisher kein solches policy, deswegen ist mir das auch
> noch nicht aufgefallen.
> Gut das ich das jetzt weiss, ich bin wohl zu naiv ran gegangen.

Hmm... schau mal unter:
C:\WINDOWS\WinSxS\Policies\x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773

>> Aus diesem Grunde wäre es sehr hilfreich, wenn man *wirkliche* Private
>> Assemblies verwenden könnte.
> Das habe ich schon mal gemacht. Ich habe es aber nur hinbekommen, wenn keine
> gültige Version im SxS verfügbar war. dann hat er die lokale geladen.

Ja... das ist ja normal... das Problem ist ja, dass wenn eine SxS
vorhanden ist, immer diese genommen wird!

Greetings
Jochen

[Andre Stille [MVP]]

Hallo!

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> schrieb im

Newsbeitrag news:%23AO2k3L...@TK2MSFTNGP04.phx.gbl...

>
> Aus diesem Grunde wäre es sehr hilfreich, wenn man *wirkliche* Private
> Assemblies verwenden könnte.
> Aber ich habe es bis heute noch nicht geschafft...
>

"lm f"-Ausgabe von WinDbg bei einer Standard-MFC-Dialog-Anwendung:
start end module name
00400000 0040d000 LoadTest LoadTest.exe
5b0f0000 5b128000 uxtheme C:\WINDOWS\system32\uxtheme.dll
5d360000 5d370000 MFC80DEU
C:\WINDOWS\WinSxS\x86_Microsoft.VC80.MFCLOC_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_3415f6d0\MFC80DEU.DLL
746a0000 746eb000 MSCTF C:\WINDOWS\system32\MSCTF.dll
773a0000 774a2000 COMCTL32
C:\LoadTest\release\Microsoft.Windows.Common-Controls\COMCTL32.dll
77be0000 77c38000 msvcrt C:\WINDOWS\system32\msvcrt.dll
77d10000 77da0000 USER32 C:\WINDOWS\system32\USER32.dll
77da0000 77e4a000 ADVAPI32 C:\WINDOWS\system32\ADVAPI32.dll
77e50000 77ee1000 RPCRT4 C:\WINDOWS\system32\RPCRT4.dll
77ef0000 77f37000 GDI32 C:\WINDOWS\system32\GDI32.dll
77f40000 77fb6000 SHLWAPI C:\WINDOWS\system32\SHLWAPI.dll
78130000 781cb000 MSVCR80
C:\LoadTest\release\Microsoft.VC80.CRT\MSVCR80.dll
782e0000 783ec000 MFC80U
C:\LoadTest\release\Microsoft.VC80.MFC\MFC80U.DLL
7c800000 7c906000 kernel32 C:\WINDOWS\system32\kernel32.dll
7c910000 7c9c7000 ntdll ntdll.dll

Wie man sieht, werden nur noch die lokalisierten MFC-Resourcen aus dem
WinSxS-
Verzeichnis genommen. Dies ist aber nicht weiter tragisch, da der
MFC-Standard-
Such-Algorithmus für Resourcen zuerst immer im Applikations-Modul sucht und
man somit sämtliche Resourcen der MFC80DEU in die Applikation verlagern
könnte.

Applikations-Manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<dependency>
<dependentAssembly>

<assemblyIdentity type="win32" name="Microsoft.VC80.CRT"

version="8.0.50727.42" processorArchitecture="x86" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.MFC"
version="8.0.50727.42" processorArchitecture="x86" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32"
name="Microsoft.Windows.Common-Controls" version="6.0.2600.2180"
processorArchitecture="x86" language="*" />
</dependentAssembly>
</dependency>
</assembly>

Microsoft.VC80.CRT.Manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity type="win32" name="Microsoft.VC80.CRT"

version="8.0.50727.42" processorArchitecture="x86"></assemblyIdentity>
<file name="msvcr80.dll"></file>
<file name="msvcp80.dll"></file>
<file name="msvcm80.dll"></file>
</assembly>

Microsoft.VC80.MFC.Manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity type="win32" name="Microsoft.VC80.MFC"
version="8.0.50727.42" processorArchitecture="x86"></assemblyIdentity>
<file name="mfc80.dll"></file>
<file name="mfc80u.dll"></file>
<file name="mfcm80.dll"></file>
<file name="mfcm80u.dll"></file>
</assembly>

Microsoft.Windows.Common-Controls.Manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
version="6.0.2600.2180" processorArchitecture="x86"/>
<file name="comctl32.dll">
<windowClass>ToolbarWindow32</windowClass>
<windowClass>ComboBoxEx32</windowClass>
<windowClass>msctls_trackbar32</windowClass>
<windowClass>msctls_updown32</windowClass>
<windowClass>msctls_progress32</windowClass>
<windowClass>msctls_hotkey32</windowClass>
<windowClass>msctls_statusbar32</windowClass>
<windowClass>SysHeader32</windowClass>
<windowClass>SysListView32</windowClass>
<windowClass>SysTreeView32</windowClass>
<windowClass>SysTabControl32</windowClass>
<windowClass>SysIPAddress32</windowClass>
<windowClass>SysPager</windowClass>
<windowClass>NativeFontCtl</windowClass>
<windowClass>Button</windowClass>
<windowClass>Static</windowClass>
<windowClass>Listbox</windowClass>
<windowClass>ScrollBar</windowClass>
<windowClass>SysLink</windowClass>
<windowClass>tooltips_class32</windowClass>
<windowClass>ButtonListBox</windowClass>
<windowClass>SysAnimate32</windowClass>
<windowClass>SysMonthCal32</windowClass>
<windowClass>SysDateTimePick32</windowClass>
<windowClass>ReBarWindow32</windowClass>
<windowClass>Edit</windowClass>
<windowClass>Combobox</windowClass>
<windowClass>ComboLBox</windowClass>
<windowClass>ReaderModeCtl</windowClass>
</file>
</assembly>

Das Applikationsmanifest kommt in dasselbe Verzeichnis wie die Applikation
selber, die DLL-Manifeste liegen entweder im selben Verzeichnis oder in
den entsprechenden Unterverzeichnissen, die DLLs selber im selben Ver-
zeichnis wie die dazugehörigen Manifeste.

MfG
Andre Stille

[Jochen Kalmbach [MVP]]

Hallo Andre!

>> Aus diesem Grunde wäre es sehr hilfreich, wenn man *wirkliche* Private
>> Assemblies verwenden könnte.
>> Aber ich habe es bis heute noch nicht geschafft...
>>
>
> "lm f"-Ausgabe von WinDbg bei einer Standard-MFC-Dialog-Anwendung:

> 78130000 781cb000 MSVCR80
> C:\LoadTest\release\Microsoft.VC80.CRT\MSVCR80.dll
> 782e0000 783ec000 MFC80U
> C:\LoadTest\release\Microsoft.VC80.MFC\MFC80U.DLL

Ich bin begeistert!!!!

Und was war jetzt eigentlich der "Trick" dabei??? Das weglassen des
"publicKeyToken" !?

Kannst Du das irgendwo mal veröffentlichen? Damit ich auf Dich verweisen
kann, wenn ich es irgendwo posten will?

Greetings
Jochen

[Martin Richter [MVP]]

Hallo Jochen!

> Kannst Du das irgendwo mal veröffentlichen? Damit ich auf Dich verweisen
> kann, wenn ich es irgendwo posten will?

<winkewinke>... auch haben will... :-)

[Andre Stille [MVP]]

Hallo!

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> schrieb im

Newsbeitrag news:u27NNoNd...@TK2MSFTNGP05.phx.gbl...

> Hallo Andre!
>>> Aus diesem Grunde wäre es sehr hilfreich, wenn man *wirkliche* Private
>>> Assemblies verwenden könnte.
>>> Aber ich habe es bis heute noch nicht geschafft...
>>>
>>
>> "lm f"-Ausgabe von WinDbg bei einer Standard-MFC-Dialog-Anwendung:
>> 78130000 781cb000 MSVCR80
>> C:\LoadTest\release\Microsoft.VC80.CRT\MSVCR80.dll
>> 782e0000 783ec000 MFC80U
>> C:\LoadTest\release\Microsoft.VC80.MFC\MFC80U.DLL
>
> Ich bin begeistert!!!!
>
> Und was war jetzt eigentlich der "Trick" dabei??? Das weglassen des
> "publicKeyToken" !?
>

Ja. Kein publicKeyToken => private Assembly => keine Suche im WinSxS-
Ordner.

>
> Kannst Du das irgendwo mal veröffentlichen? Damit ich auf Dich verweisen
> kann, wenn ich es irgendwo posten will?
>

Werd ich am Wochenende machen.

MfG
Andre Stille

[Alwin Belschner]

Hallo Jochen
ich habe das ganze Zeugs durchsucht, und natuerlich das policy gefunden.
Danke schön, für deine Bemühungen. Hat mir zum gesamtverständnis
weitergeholfen.

ich habe mal was gelesen wie man -files private to application-
als einbinden kann. da bin ich mal in der MSDN auf folgende Möglichkeit
gestossen.
(Vielleicht hilft dir das ja ein weiter.)

Das Attribut <file> ist wohl dafür zuständig...
(Text kopiert aus MSDN)
__________________________________________________________________________
<file>
Specifies files that are private to the application. Optional.
The <file> element has the attributes shown in the following table.

Attribute Description
name Name of the file. For example, Comctl32.dll.
hashalg Algorithm used to create a hash of the file. This value should be
SHA1.
hash A hash of the file referred to by name. A hexadecimal string of length
depending on the hash algorithm.
____________________________________________________________________________
_____________________________________________

so soll wohl das dazugehörige manifest aussehen (laut MSDN)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<!-- Copyright ?? 1981-2001 Microsoft Corporation -->

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

<noInheritable/>

<assemblyIdentity type="win32" name="Microsoft.VC80.CRT"

version="8.0.50215.4631" processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"/>
<file name="msvcr80.dll" hash="3ca5156e8212449db6c622c3d10f37d9adb12c66"
hashalg="SHA1"/>
<file name="msvcp80.dll" hash="92cf8a9bb066aea821d324ca4695c69e55b27cff"
hashalg="SHA1"/>
<file name="msvcm80.dll" hash="7daa93e1195940502491c987ff372190bf199395"
hashalg="SHA1"/>
</assembly>

____________________________________________________________________________
_________________________________________

evtl musst man noch das default manifest ausschalten. (bin mir aber nicht
sicher)
Dann werden die dinger wohl als privat behandelt und auch so geladen. ich
selbst habe es nicht getestet,
weil ich es ehrlich gesagt immer noch nicht für richtig halte, mfc Dlls als
private hinzuzufügen.
aber ich widerspreche lieber keinem MVP.

zu meinem Schutz habe ich deswegen den folgenden Text aus der MSDN kopiert
...
DLL versioning conflict
Compatibility problem. Assembly sharing problems occur when an application
installs a version of a shared assembly that is not backward compatible
with the previously installed version. A solution to DLL versioning
conflicts is to use side-by-side assembly sharing and isolated applications.
With side-by-side assembly sharing, multiple versions of the same Windows
assembly can run simultaneously. Developers can choose which
side-by-side assembly to use.

Grüsse Alwin

[Dieter Smode]

Hallo Andreas,

> in vergangenen Tagen wurde immer gerne auf VC-FAQ unter
> http://www.mpdvc.de/html.htm verwiesen. Deren Stand ist aber Dez. 2004.
> Heute kommt der Hinweis auf Codeproject oder Codeguru.
> Könnte sich aber trotzdem jemand veranlaßt fühlen, die unterschiedlichen
> Manifest-Lösungen in der FAQ zusammenzutragen, oder einen
> Codeproject-Artikel zu schreiben?

nach wie vor bin ich gerne bereit, neue Dinge in die FAQ aufzunehmen (am
besten einfach an die dort angegebene E-Mail-Adresse schicken [nicht über
die hier angegebene Adresse, da ich da so gut wie nie reinschaue]). Wenn
nichts kommt, ändert sich auch am Stand nichts ;-) Also wenn euch etwas
fehlt ...

Ich lese zwar noch einigermaßen regelmäßig mit, habe aber im Moment eher
nicht mit C++ zu tun, sondern eher mit C#/.NET 2.0 und
SQL2005/BizTalk2006. Von daher ist mein C++-Engagement im Moment ziemlich
gering.

Beste Grüße

Dieter

[Stefan Kuhr]

Hallo Andre,

Andre Stille [MVP] wrote:
> Hallo!
>
> <snip>

> Das Applikationsmanifest kommt in dasselbe Verzeichnis wie die Applikation
> selber, die DLL-Manifeste liegen entweder im selben Verzeichnis oder in
> den entsprechenden Unterverzeichnissen, die DLLs selber im selben Ver-
> zeichnis wie die dazugehörigen Manifeste.
>

Ich bin begeistert!

--
Stefan Kuhr

"Lesen schadet der Dummheit"

[Stefan Kuhr]

Hallo beisammen.

"Andre Stille [MVP]" wrote:
>
>
> Werd ich am Wochenende machen.
>

Entweder ich habe 'was verpasst, oder Andre hat's vergessen. Egal, ich
habe hier mal die nötigen Schritte zusammengefasst, fuer den Fall, dass
das Ganze noch von Interesse fuer den einen oder anderen ist:

http://mcblogs.craalse.de/sku?title=visual_studio_2005_runtimes_part_2_sich&more=1&c=1&tb=1&pb=1

--
S

[Martin Richter [MVP]]

Hallo Stefan!

> Entweder ich habe 'was verpasst, oder Andre hat's vergessen. Egal, ich
> habe hier mal die nötigen Schritte zusammengefasst, fuer den Fall, dass
> das Ganze noch von Interesse fuer den einen oder anderen ist:
>
> http://mcblogs.craalse.de/sku?title=visual_studio_2005_runtimes_part_2_sich&more=1&c=1&tb=1&pb=1

Jochen hatte auch schon:
http://blog.kalmbachnet.de/?postid=80

[Stefan Kuhr]

Hi Martin,

"Martin Richter [MVP]" wrote:
>
> Hallo Stefan!
>
> > Entweder ich habe 'was verpasst, oder Andre hat's vergessen. Egal, ich
> > habe hier mal die nötigen Schritte zusammengefasst, fuer den Fall, dass
> > das Ganze noch von Interesse fuer den einen oder anderen ist:
> >
> > http://mcblogs.craalse.de/sku?title=visual_studio_2005_runtimes_part_2_sich&more=1&c=1&tb=1&pb=1
>
> Jochen hatte auch schon:
> http://blog.kalmbachnet.de/?postid=80
>

Hach, wird doch mal Zeit, dass ich den Blog von Jochen auch noch
syndiziere. Aber so wie ich das sehe, ergaenzt sich mein Pamphleth ganz
gut mit Jochens, meins ist halt fuer die ganz Doofen :-) und Jochens
fuer die, denen die Minimalinformationen ausreichen.

--
S