VC++ 2005
-
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?
-
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.htmlDer macht sich wegen soetwas garantiert keine Sorgen.
-
Ich muss ja auch zugeben, dass ich die jetzige Lösung nicht gerade die beste finde... hab ich ja aber schon mal gesagt...
-
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???
-
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
-
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... 
-
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.
-
naja trotzdem Danke für die Hilfe
