4. VC++ 2005

VC++ 2005

  • J

    Eine unmanaged C++ Anwendung hat überhaupt nichts mit dem .NET Framework zu tun, und deshalb muss man dieses auch nicht installieren!

    Das Problem ist ganz trivial; und dazu gibt es drei Lösungen:
    1. Linke Deine EXE statisch mit der CRT/MFC/ATL
    2. Installiere die CRT/MFC/ATL DLLs auf dem Zielrechner
    3. Liefere die CRT/MFC/ATL DLLs mit Deiner Anwendung mit und liefere das passende Manifest für diese DLLs mit!

    Für die Punkte 2 und 3 braucht natürlich auch noch Deine EXE ein passendes Manifest.

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

    0
  • V

    Tc++H schrieb:

    Kann ich mal deine Email Addy bekommen?

    schau dir mein Profil an 😉

    0
  • V

    Der Artikel "Bootstrapper for the VC++ 2005 Redists (with MSI 3.1)" scheint deine Problem zu lösen - schade das es kein Click Once für C++ Projekte gibt 😉

    0
  • D

    @Jochen K.
    wenn das angeblich nichts damit zu tun hat, dann sag mir bitte warum genau DAS zur Lösung des Problems führt... 😮 😮 😮

    0
  • J

    DarkFitzi schrieb:

    @Jochen K.
    wenn das angeblich nichts damit zu tun hat, dann sag mir bitte warum genau DAS zur Lösung des Problems führt... 😮 😮 😮

    Weil das .NET Framework zufällig auch die VC8 CRT installiert 😉
    Vermutlich gibt es noch andere Programme die dies auch machen, und somit auch "das Problem lösen"... das ist ja aber keine "Lösung"...

    0
  • J

    Vertexwahn schrieb:

    schade das es kein Click Once für C++ Projekte gibt 😉

    Also... eigentlich sollte ClickOnce doch auch für C++ Projekte gehen... du musst nur das passende Manifest haben... warum sollte es nicht gehen?

    0
  • D

    aha das heist afaik, dass wenn ich kein ATL und MFC neutze nur das CRT mitliefern muss?

    0
  • J

    Ja, auf gut deutsch... Ganz genau: Du must alles mitliefern was Deine Anwendung brauchst... das kannst Du entweder "wissen" oder hiermit nachschauen:
    http://www.dependencywalker.com/

    0
  • T

    ich werde es nochmal probieren

    0
  • V

    siehe MSDN: "Understanding Dependencies of a Visual C++ Application"
    installier auf dem Rechner auf dem es nicht funktioniert Dependency Walker - der zeigt dir an welche DLLs Fehlen oder in der falschen Version vorliegen:
    http://www.dependencywalker.com/

    mehr in der MSDN unter: Visual C++ Deployment (C++)

    0
  • V

    @Jochen Kalmbach

    ClickOnce deployment for Visual C++ native applications is not supported in Visual Studio 2005; however, it is possible to deploy Visual C++ applications via ClickOnce on the command line.

    muss ich gleich mal ausprobieren

    0
  • D

    @Jochen Kalmbach und Veretxwahn
    Thx, jez muss ich nicht immer wieder das .NET 2.0 Framework installen... 😃

    0
  • D

    hmm... könnte mir jemand sagen welche Datein ich genau mitliefern muss... 😕 😕 😕
    also ich verwende weder MFC noch ATL. Ich bin nach einiger Zeit auf den Ordner gestoßen: C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd
    aber wenn ich die darin vorhandenen Dlls mitliefere klappt es immernoch nicht 😞

    0
  • D

    ok es hat die manifest gefehlt... 🙄

    0
  • ?

    hab das gleiche problem ...
    kann mir mal bitte einer erklären was die manifest is??
    bzw. wo finde ich das / wie erstelle ich das??

    0
  • D

    \Program Files\Microsoft Visual Studio 8\VC\Redist\x86\Microsoft.VC80.CRT
    da findeste die 3 dlls und eine .manifest Datei, die brauchste

    0
  • J

    DarkFitzi schrieb:

    \Program Files\Microsoft Visual Studio 8\VC\Redist\x86\Microsoft.VC80.CRT
    da findeste die 3 dlls und eine .manifest Datei, die brauchste

    Und wenn DU die nicht findest (fehlt z.B: bei der Express Version), dann kannst Du enwteder statisch linken oder nimmst diese hier:

    Dateiname:

    Microsoft.VC80.CRT.manifest

    Inhalt:

    <?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.50608.0" 
        processorArchitecture="x86" 
        publicKeyToken="1fc8b3b9a1e18e3b"
    />
    <file name="msvcr80.dll"/>
    <file name="msvcp80.dll"/>
    <file name="msvcm80.dll"/>
</assembly>
    0
  • D

    Thx, auch für den Link wo alles drin stand 😃 😃 😃 😃 😃 😃

    0
  • ?

    Kann mir bei dieser Gelgenheit einer von Euch den Sinn der side-by-side Aktion erklären? Dlls werden heutzutage doch ohnehin nicht mehr in die System-Verzeichnisse verteilt, sondern im Anwendungs-Verzeichnis bewahrt. Und da inzwischen selbst COM-Komponenten ohne Registrierung auskommen, sehe ich nicht, wo Probleme mit Inkompatibilitäten herkommen sollen.

    Auf der einen Seite will man weg von der Registry, da die angeblich sowieso nur vollgemüllt wird. Auf der anderen Seite will man jetzt aber jeden Mist im GAC installieren und feiert das als Innovation. Und weil das alles so schön side-by-side ist, bekommt jede Vorgänger-Version eine Publisher-Policy mit Umlenkung auf die neue Version verpasst, sodass ja nicht die alte Version verwendet wird. Schließlich soll der Kunde vom Update profitieren. Ich weiß gar nicht, wieviele unterschiedliche Versionen ich beispielsweise von den Common-Controls auf dem Rechner habe. Verwendet wird doch aber nur eine!?

    Klar, man kann die Application so konfigurieren, daß doch eine ältere Version genutzt wird. Aber wer soll das bitte machen? Der Entwickler wird seine Software so gestalten, daß es keine Schwierigkeiten mit den vorhandenen Assemblies gibt, hat das also nicht nötig (dafür stehen ihm die Haare hoch, wenn es ums Verteilen der Anwendung geht). Bleibt der Anwender, aber woher soll der wissen, welche Assembly die Schwierigkeiten verursacht? Der deinstalliert die Anwendung und gibt entnevt auf.

    Also was soll das? Es kopiert doch sowieso, wie gesagt, keiner außer Microsoft Dlls in die System-Verzeichnisse. Und selbst wenn die Microsofties das machen, benennen sie ihre Dlls um, wenn sie die Kompatibilität brechen (z.B. msvcr80.dll).

    Bitte um Erleuchtung!

    0
  • J

    Gästchen schrieb:

    Kann mir bei dieser Gelgenheit einer von Euch den Sinn der side-by-side Aktion erklären? Dlls werden heutzutage doch ohnehin nicht mehr in die System-Verzeichnisse verteilt, sondern im Anwendungs-Verzeichnis bewahrt. Und da inzwischen selbst COM-Komponenten ohne Registrierung auskommen, sehe ich nicht, wo Probleme mit Inkompatibilitäten herkommen sollen.

    MS empfiehlt es nicht die CRT/MFC/ATL DLLs als private DLLs in das App-Verzeichnis zu legen, sondern im SxS-Verzeichnis zu installieren. Der Grund ist ganz simpel: Falls Sicherheitslücken in den DLLs entdeckt werden, können sie via Security-Updates durch das OS installiert werden...

    Gästchen schrieb:

    Ich weiß gar nicht, wieviele unterschiedliche Versionen ich beispielsweise von den Common-Controls auf dem Rechner habe. Verwendet wird doch aber nur eine!?

    Nein. Verwendet werden vermutlich mehrere, da ja jede Applikation explizit via Manifest angeben muss welche Version sie verwenden will. Ist nichts angegeben so wird 5.x verwendet.

    Aber ich kann Dir zumindest soweit zustimmen, dass es das leben nicht unbedingt einfacher macht...

    0
Anmelden zum Antworten