VC++ 2005

DarkFitzi

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

DarkFitzi

ok es hat die manifest gefehlt...

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

DarkFitzi

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

Jochen Kalmbach

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>

DarkFitzi

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

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!

Jochen Kalmbach

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

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.

Jochen Kalmbach

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

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?

Jochen Kalmbach

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

Ah, jetzt verstehe ich, was Du mir sagen willst. Es ist mir wohl bekannt, daß es mal falsch lief. Aber die Probleme sind längst beseitigt. Microsoft hat erkannt, daß unterschiedliche DLLs eben auch unterschiedliche Namen haben müssen (bei COM ist es schließlich auch so, nach einer Änderung gibt es eben neue GUIDs). Jetzt so viel Theater darum zu machen, nur um Jugendsünden auszubügeln, ich weiß ja nicht...

Mir kommt in diesem Zusammenhang das Verhalten von Windows ME in Erinnerung. ME liefert durch die API-Funktion GetVersionEx 'Windows 98' zurück, sofern die Anwendung 'setup.exe' heißt. Und alles nur, um Schlampereien bei der Setup-Erstellung im eigenen Hause zu verschleiern.

Jetzt ist es allerdings so, daß Microsoft den Entwicklern empfiehlt, gleich zu ziehen. Du sollst Deine Komponenten ebenfalls side-by-side erstellen. Und nach wie vor bin ich der Meinung, daß über kurz oder lang ein weitaus größerer Müllhaufen entsteht, als es die Registrierung jemals war.

Die .NET-Entwickler sehen darin sogar noch Vorteile. In einer NG zum Thema C# habe ich vor einiger Zeit lesen dürfen, wie sich ein MVP gar fürchterlich über den GAC freute und hervorhob, wie elegant damit Probleme gelöst werden (leider nicht welche Probleme). Aber wie ich nun weiß, löst das nur die Probleme, die es spätestens seit Windows 2000 gar nicht mehr gibt (seit diesem System gibt es keinen praktischen Grund mehr, DLLs außerhalb des Anwendungs-Verzeichnises zu halten).

Ich werde mich jedenfalls erstmal zurückhalten, was das 'Stark-Machen' betrifft, entgegen aller Empfehlungen. Nur wegen einiger weniger Schlampen, Verzeihung, muß ich nicht auch noch für Müll sorgen.

Ach ja, am Besten macht man es sowieso wie der hier:
http://www.cs.pdx.edu/~harry/Relay/index.html

Der macht sich wegen soetwas garantiert keine Sorgen.

Jochen Kalmbach

Ich muss ja auch zugeben, dass ich die jetzige Lösung nicht gerade die beste finde... hab ich ja aber schon mal gesagt...

DarkFitzi

so noch eine letzte Frage bleibt mir offen...
Ich weis jez welche Dlls man Bei CRT, ATL und MFC mitliefern muss, aber gibt es auch bestimmte für WindowsForms???

Jochen Kalmbach

DarkFitzi schrieb:

gibt es auch bestimmte für WindowsForms???

Da kannst Du nur das .NET-Framework 2.0 mitliefern...
http://www.microsoft.com/downloads/details.aspx?FamilyID=0856EACB-4362-4B0D-8EDD-AAB15C5E04F5

DarkFitzi

Ok das heist, dass ich MFC und ATL (natürlich auch CRT) auch ohne das NET 2.0 Framework laufen lassen kann, aber nich Windows Forms... is doch shitty...

Jochen Kalmbach

DarkFitzi schrieb:

Ok das heist, dass ich MFC und ATL (natürlich auch CRT) auch ohne das NET 2.0 Framework laufen lassen kann, aber nich Windows Forms...

Du hast es auf den Punkt getroffen.

DarkFitzi

naja trotzdem Danke für die Hilfe