4. VC++ 2005

VC++ 2005

  • 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
  • ?

    Jochen Kalmbach schrieb:

    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...

    Früher ging das Updaten doch auch schmerzfrei von statten.

    So, wie es jetzt ist, behalte ich sogar noch die alten unsicheren Versionen. Welchen Vorteil habe ich denn nun davon?

    Gästchen schrieb:

    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.

    Gut, da hast Du natürlich recht, die Version 5 hatte ich übersehen. Die wird natürlich auch noch verwendet, wie man schön am Durcheinander des originalen XP-Bunt-GUI erkennen kann. Von den Versionen, die als Shared Assembly erstellt wurden, wird aber nur eine benutzt. Jedenfalls habe ich für alle alten Versionen eine Publisher Policy mit Umlenkung.

    Ich habe übrigens gerade nachgesehen: Die Common-Controls in der Version >= 6.0 habe ich insgesamt 4x installiert, bleiben also 3 Leichen. Und das ist nicht alles, ich habe auch vieles Andere überflüssigerweise mehrfach installiert.

    Gästchen schrieb:

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

    ... und sorgt zudem noch für schier unendlich viele Leichen auf dem System.

    Das soll dann wohl doch nicht sein, mit der viel zitierten 'XCOPY-Installation'. Wirklich innovativ, wie ich feststellen darf.

    0
  • J

    Gästchen schrieb:

    Jochen Kalmbach schrieb:

    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...

    Früher ging das Updaten doch auch schmerzfrei von statten.

    So, wie es jetzt ist, behalte ich sogar noch die alten unsicheren Versionen. Welchen Vorteil habe ich denn nun davon?

    Verstehe ich nicht ganz... jetzt (also ohne SxS) ist ein Update einer DLL ja gar nicht möglich, da sich ja dann die Schnittstelle nicht ändern darf!
    Mit dem SxS kann ich mehrere Versionen haben (mit unterschiedlicher Schnittstelle) die ich alle separat updaten (und somit Probleme beheben) kann.

    Das geht mit dem bisherigen Verfahren (also ohne SxS) nicht (ohne dass jede Anwendung selber ein Update durchführt).

    Gästchen schrieb:

    Ich habe übrigens gerade nachgesehen: Die Common-Controls in der Version >= 6.0 habe ich insgesamt 4x installiert, bleiben also 3 Leichen. Und das ist nicht alles, ich habe auch vieles Andere überflüssigerweise mehrfach installiert.

    Ja, da hast Du recht... das Update scheint kompatibel zu sein, denn in den Policies steht:

    <bindingRedirect oldVersion="6.0.0.0-6.0.2600.2180" newVersion="6.0.2600.2180"/>

    Gästchen schrieb:

    Das soll dann wohl doch nicht sein, mit der viel zitierten 'XCOPY-Installation'.

    Jetzts gibts ja auch noch "ClickOnce"...

    Gästchen schrieb:

    Wirklich innovativ, wie ich feststellen darf.

    Das MS nicht innovativ ist, bestreitet nicht mal bei MS jemand... MS ist meistens einige Jahre hinter den "führenden" her... aber sie holen dann meist sehr schnell auf und bringen es auf den "enterprise level"... meistens relative einfach...
    Bei SxS haben sie aber nicht den elegantesten Weg gewählt...

    0
  • ?

    Jochen Kalmbach schrieb:

    Verstehe ich nicht ganz... jetzt (also ohne SxS) ist ein Update einer DLL ja gar nicht möglich, da sich ja dann die Schnittstelle nicht ändern darf!

    Das widerum verstehe ich nicht. Wenn ich einen Bug beseitige, ändere ich nicht die Schnittstelle. Breche ich mit der Kompatibilität (die neue DLL leistst nicht das, was die alte leistet), ändere ich logischerweise auch den Namen (Prominentes Beispiel, nicht von mir: msvcr70, msvcr71, msvcr80). Da diese DLLs tatsächlich alle gebraucht werden, ist das, wie ich meine, richtig so. Trotzdem kann bei einem Bug jede DLL für sich upgedatet werden.

    So mache ich das schon allein mir zuliebe. Wie soll denn sonst die Wartung vernünftig funktionieren?

    0
  • J

    Wir reden galube ich aneinander vorbei...
    Bei einem BugFix ist das update ja auch kein Problem!
    Wenn aber neue Funktion oder etwas andere semantik von Funktion dazukommen kannst Du eben dies nicht mehr updaten... und dazu ist dann (systemweit) ein SxS sinnvoll. Das hatte ja MS (bzw. die Kunden) leidvoll erfahren müssen bei dem update von msvcrt.dll... da es damals noch kein Sxs gab, haben sie dann die nächste den dll-Namen nach msvcr71.dll geändert.
    Hätte es damals schon SxS gegeben, hätten sie vermutlich das selbe gemacht wie mit dem ComControls... (nur dann eben wirklich zwei bzw. jetzt drei neue separate Versionen).

    0
Anmelden zum Antworten