statisch und dynamisch Verknüpfung DLLs erzeugte mit verschiedenen Versionen von Visual Studio

Question

hier ist die Situation, die ich mich für Feedback suche auf:

1. Bei der Arbeit, eine meiner Aufgaben ist ein paar Legacy-Anwendungen beibehalten, von denen Wir nennen "LegacyApp". Es wurde immer mit VS 6.0 kompiliert. (Und ist nicht viel in diesen Tagen berührt.)
2. Es verwendet eine API, die Zugriff auf einige spezialisierte Hardware bietet. Diese API wird von einer anderen Gruppe in meiner Firma produziert. Wir nennen diese API "ControllerAPI". Es wurde immer mit VS 6.0 kompiliert.
3. Die Entwickler von LegacyApp schrieben auch eine Wrapper-DLL um ControllerAPI, die LegacyApp verwenden würde. Wir werden dies "WrapperAPI" nennen. Ich bin verantwortlich für die Aufrechterhaltung dieses. Es wurde immer mit VS 6.0 kompiliert.
4. WrapperAPI verbindet statisch mit ControllerAPI.
5. LegacyApp Tinten dynamisch gegen WrapperAPI.
6. Mit der nächsten Version hat die Gruppe, die ControllerAPI erstellt, begonnen, sie mit VS 2008 zu kompilieren, anstatt mit VS 6.0, wie es bisher der Fall war.

Also, hier meine Fragen ist:

1. Da WrapperAPI verknüpft ist statisch gegen ControllerAPI, ich muss WrapperApi mit VS 2008 kompilieren? Ist das korrekt? (Ich habe es bereits getan, war in diesem Fall ein einfacher Schritt.)
2. Da LegacyApp dynamisch gegen WrapperAPI verknüpft ist, kann ich LegacyApp in VS 6.0 weiter kompilieren? Wenn ja, muss ich etwas in meiner WrapperAPI-Kompilierung tun, um sicherzustellen, dass dies immer noch der Fall ist. Oder muss ich Legacy-App in VS 2008 kompilieren, die ich jetzt lieber nicht machen müsste.

So kocht meine Frage miteinander zu laufenden Apps und DLLs nach unten, die mit unterschiedlichen Versionen von Visual Studio erstellt wurden, und ob oder nicht macht es einen Unterschied, wenn die verschiedenen Schichten statisch oder dynamisch verknüpft sind.

Dank für jedes Feedback

Answer 1

Wenn die Signaturen der von ControllerAPI und WrapperAPI exportierten Funktionen haben sich nicht geändert, sollten Sie Ihre Bindungen in Ordnung sein, statisch oder dynamisch.

Wenn jedoch die von den Funktionen verwendeten Typen und Objekte (Eingabe-, Ausgabe- und Rückgabeparameter) von einer externen Bibliothek abhängig sind; Dann haben Sie möglicherweise Probleme.

Zum Beispiel sagen, wenn ControllerAPI Speicher mit einer Version der C-Laufzeit zuteilt, und WrapperAPI erwartet der Lage sein, es zu befreien, auf das Eigen- ist dann in diesem Fall müssen sie sowohl gegen die gleiche Version des C verknüpft werden Laufzeit. Wenn Sie das Projekt in VS2008 neu erstellt haben, anstatt es zu importieren und zu aktualisieren, haben sich möglicherweise Ihre Standardkompilierziele und importierten Bibliotheken geändert. Ähnliche Probleme können in Bibliotheken beobachtet werden, die mit bekannten Typen wie MFC, ATL usw. erstellt wurden.

Leider müssen Sie diese Szenarios von Hand überprüfen, aber wenn Sie die folgenden Punkte abhaken können, sollte es Ihnen gut gehen. Ich sollte auch beachten, dass diese Dinge auch zwischen zwei gegebenen Versionen von Visual Studio und sogar zwei Builds gegen verschiedene Kompilierungsziele oder Versionen des Platform SDK überprüft würden.

1. Es gibt keine Fälle, in denen beide DLLs auf die Referenzen achten müssen, die von der anderen DLL (Speicher/Handle/Ressourcenzuweisung) verknüpft wurden. Es ist jedoch in Ordnung, wenn WrapperAPI Elemente von ControllerAPI abrechnet und diese entsprechend behandelt (z. B. ControllerAPI weist etwas zu, WrapperAPI verwendet es und gibt es dann zur Freigabe/Zerstörung an ControllerAPI zurück).
2. Keine Speicherausrichtung Unterschiede in Strukturen von beiden DLLs verwendet.
3. Keine Änderungen an Parametertypen, die definiert sind. Achten Sie auf Fälle, in denen eine Version eine Variable mit einem 32-Bit-Typ deklariert, aber bei einem erneuten Kompilieren in VS2008 unter bestimmten Kompilierungszielen (LONG) 64 Bit lang sein kann.
4. Keine Änderung der Aufrufkonvention (cdecl/pascal/etc.) für exportierte/importierte DLL-Funktionen und Funktionsparametertypen.