MFC und manifest-Einträge

mist70

Nachdem ich letzte Woche auf VS2005 umgestiegen bin (ja ja, schon spät, aber wenn man huckepack auf anderer Software programmiert, ist man auf die unterstützten Versionen angewiesen), habe ich mittlerweile im Selbstversuch raus bekommen, wie ich die Sachen mit MFC und CRT auf anderen Rechnern zum Laufen bekomme.

Eines stört mich allerdings, in meiner manifest-Datei sind jetzt sowohl die Version 762 als auch die Version 4053 gelistet. Heißt das jetzt er benötigt beide Versionen ? Alternativ kann es kaum sein, da meine Applikation erst nach Installation der 4053 lief (762 war schon auf der Zielmaschine). Reste sind es auch nicht, da ich zur Sicherheit das gesamte Ausgabeverzeichnis zunächst gesäubert habe (kompletter Rebuild).

Irgendwie war mir die alte MFC sympathischer, nicht mal das Kopieren der Dateien (mfc/crt) in den Applikationsordner funktioniert, obwohl laut Suchreihenfolge eigentlich ausreichend.

Bin für alle Hinweise dankbar, vllt. erklärt ja mal einer, wie die manifest Dateien zu lesen sind.

Michael

Martin Richter

Wenn Du mehrere Manifest Einträge hast mitunterschiedlichen Versionen, dann hast Du evtl. Libraries die mit unterschiedlichen VS Versionen kompiliert wurden.

Diese Manifest Einträge stehen in den Objekt Dateienund werden einfach vom Linker gesammelt.
Sowohl in meinem Blog (blog.m-ri.de) als auch Jochens Blog (blog.kalmbach-software.de) findest du grundsätzlich Infos wie man auch eine lokale Installation unterstützt.

Ansonsten siehe auch:
http://blog.m-ri.de/index.php/2007/06/12/mein-erster-codeproject-artikel/
http://blog.m-ri.de/index.php/2008/05/06/hotfix-fuer-usemsprivateassembliesh-und-vc-2008/

http://www.codeproject.com/KB/cpp/PrivateAssemblyProjects.aspx

mist70

Danke Martin,
bin noch nicht ganz durch, durch den Artikel, aber ich habe währenddessen weiter gesucht und recherchiert, mir mal eine VM mit der Installation der Basissoftware erstellt, und nun ist mir auch klar, woher die Abhängigkeit zur 762 kommt (und das diese mit der Basissoftware auch wirklich installiert wird). Leider (oder zum Glück) habe ich den aktuellen Sicherheitspatch vom Studio drauf, und damit werde ich wohl die Merge Module von meiner Maschine in unser Setup verankern müssen (das logischerweise auf einer andern erstellt wird )

Danke jedenfalls für die schnelle Antwort, schön das sich hier ein Forum gebildet hat, in dem Probleme mal in deutsch gelöst werden (CodeProject war schon Standard, aber das Passende zu finden ist nicht immer so einfach)

Michael

Martin Richter

mist70 schrieb:

Danke jedenfalls für die schnelle Antwort, schön das sich hier ein Forum gebildet hat, in dem Probleme mal in deutsch gelöst werden (CodeProject war schon Standard, aber das Passende zu finden ist nicht immer so einfach)

nntp://microsoft.public.vc.de gibt es noch länger als dieses Forum und war mit fähigen Regulars schon immer gut bestückt.

Man verzeihe mir die Fremdwerbung. :xmas1:

Jochen Kalmbach

:xmas2:

mist70

Was mir jetzt noch durch den Kopf schwirrt, und ein wenig auf Verständnis wartet sind die Varianten mit _CRT_NOFORCE_MANIFEST und _USE_RTM_VERSION.

Von Haus aus wäre mir ja egal, mit welcher CRT meine Applikation (oder besser dll) läuft, da ich mich darauf verlassen kann, das die darunterliegende Software eine CRT/MFC lädt.

Mein Verständnis sagt mir jetzt, das diese Ihre Software mit _CRT_NOFORCE_MANIFEST hätten übersetzen müssen, damit mir Ihre eingebundenen LIB's die 762er Einträge nicht erzeugen. Richtig ?!

_USE_RTM_VERSION könnte aber mein Problem lösen, da dadurch nur verhindet wird, das eine spezifische Version geladen wird. Richtig ?!

Sorry, für die weiteren Fragen, aber die Fundstellen im Netz beziehen sich immer alle auf eigenständige Programme, dort wäre das alles ja so schön einfach (und im C# über die Verweiseinträge ohne Versionsprüfung scheinbar auch)

Gruß Michael

mist70

Das hatte leider auch nicht den gewünschten Erfolg, statt eines (RTM)Eintrages wurden jetzt aus meinen 2 Einträgen 3

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.4053" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
    </dependentAssembly>
  </dependency>

Ich würde ja einfach die redist (resp. msm) der Version 4053 verteilen, aber was, wenn eines Tages die Basissoftware die 762 nicht mehr mit installiert ?

Martin Richter

Roll doch die neueste Version aus und gut ists.

Ansonsten schau Dir die Objekt-Dateien und LIBS direkt an. Link /DUMP (DUMPBIN).
Dann kannst Du die falschen Einträge finden.

Und lass die Finger weg von _USE_RTM_VERSION. Das ist der größte Mist... (just my 2 cents)

mist70

Ist im Endeffekt auch meine Schlussfolgerung gestern Abend gewesen. Da ich ohnehin nicht verhindern kann, das die Dependencies der Fremdbibliotheken mit eingebunden werden, kann ich auf _USE_RTM_VERSION auch ganz verzichten.

War schon ein wenig in Versuchung, die Generierung des Manifests abzuschalten, und die Einträge für die 762 (SP1) per Hand (bzw .h file)generieren zu lassen. Aber da auch kein Verlass darauf ist, das nicht mit der nächsten Version der Basissoftware neue Dependencies auftauchen, lasse ich lieber die Automatik weitersuchen, und stelle meine Rollouts entsprechend um.

Danke, und (vermutlich bald) bis zum nächsten Problem.
Michael