2016-04-20 34 views
0

In meinem aktuellen Projekt habe ich mehrere ATL-Projekte, die voneinander abhängen. Einer davon heißt "Common" und definiert eine Trace-Kategorie, die andere Projekte zum Ausdruck von Trace-Informationen verwenden können.Warum schlägt regsvr32 nach dem Upgrade eines ATL-Projekts auf VS2015.1 fehl?

ich die Kategorie aus der IDL-Datei wie so definiert:

cpp_quote("static ATL::CTraceCategory DATA_LAYER(_T(\"Data Layer\"), 1);") 

Im Grunde ist dies in der gemeinsamen Header-Datei, auch andere Projekte in die folgende Definition übersetzt über die Schnittstellen des „Common“ Projekt informiert zu .

static ATL::CTraceCategory DATA_LAYER(_T("Data Layer"), 1); 

Jetzt seit Visual Studio 2013 scheint es a change in how tracing funktioniert.

Dies ist Ursache-Quelle bricht Änderungen in einigen Verwendungen der ATL::CTraceCategory-Klasse, die Änderungen im Quellcode erforderlich, wenn zu Visual Studio 2013.

Und in der Tat migrieren, habe ich die Linie ändern oben durch den zweiten Parameter zu entfernen:

cpp_quote("static ATL::CTraceCategory DATA_LAYER(_T(\"Data Layer\"));") 

Jetzt baut alles wieder, aber das Problem löst, sobald ich versuche, jedes Projekt neu zu erstellen, die die Trace-Kategorie verwendet. Nachdem der Build erfolgreich abgeschlossen wurde, registriert der Compiler die Komponente automatisch. Und während regsvr32 /s "C:\...\Common.dll" ich immer eine Debug Geltendmachung wie folgt erhalten:

Microsoft Visual C++ Runtime Library

Debug Assertion Failed!

Programm: ... \ x64 \ Debug \ Common.dll

Datei: c: \ Programme (x86) \ Microsoft Visual Studio 14.0 \ vc \ atlmfc \ include \ atltrace.h

Line: 337

Expression: false && "Too many categories defined"

Dies geschieht auch, wenn ich versuche, t registrieren Die Komponente manuell. Nur Projekte, die nicht vom gemeinsamen Projekt abhängen und daher keine Trace-Kategorie verwenden, werden erfolgreich registriert.

Hat jemand eine Lösung dafür? Ich würde auch eine Lösung akzeptieren, die eine andere Art der Rückverfolgung in ATL zeigt, da es keinen Unterschied zur Verwendung von DebugOutputString stattdessen gibt (wenn ich den verlinkten Blog richtig verstanden habe).

+0

Es ist die Art von Missgeschick, die Sie erhalten, wenn Sie Code verknüpfen, der nicht neu kompiliert wurde. Eine Bibliothek, die normalerweise mit einer alten Version von ATL erstellt wurde. –

+0

@HansPassant Ich habe bereits die gesamte Lösung (einschließlich des gemeinsamen Projekts) neu erstellt, um sie mit der neuesten Version von ATL zu verknüpfen. Sie denken, das Problem ist, dass mindestens eine Lib mit einer älteren Version der ATL-Version verbunden ist? – Carsten

Antwort

0

Okay, ich habe es endlich herausgefunden. Das Problem bezog sich auf die Deklaration des Tracekategories static. Ich habe keine Ahnung, warum dies in früheren Versionen von Visual Studio eingebaut wurde.Wie auch immer, hier ist das Update:

cpp_quote("#ifdef DEFINE_EXPORTS") 
cpp_quote("__declspec(dllexport) extern ATL::CTraceCategory DATA_LAYER;") 
cpp_quote("#else // DEFINE_EXPORTS") 
cpp_quote("__declspec(dllimport) ATL::CTraceCategory DATA_LAYER;") 
cpp_quote("#endif // DEFINE_EXPORTS") 

Wie Sie sehen können, die Trace-Kategorie exportiert heute in der Bibliothek, wenn DEFINE_EXPORTS definiert ist, welche: Zunächst einmal habe ich die Definition der Trace-Kategorie in meinem Common.idl Datei geändert gilt für das gemeinsame Projekt. Alle Projekte, die auf diese Bibliothek verweisen, importieren die Definition (indem sie Common.h einschließen, die aus der idl-Datei erstellt werden). Wenn Sie die Trace-Kategorie als statisch definieren, definiert jede Bibliothek eine eigene Kategorie. Ich denke, das war der Grund für den Fehler, vor dem ich stand.

nun in der dllmain.cpp Datei des gemeinsamen Projektes definiere ich die Trace-Kategorien:

#if (_MSC_VER >= 1800) 
ATL::CTraceCategory DATA_LAYER(_T("Data Layer")); 
#else 
ATL::CTraceCategory DATA_LAYER(_T("Data Layer"), 1); 
#endif 

Beachten Sie, dass der Code-Schalter zwischen zwei auf dem VC basierten Konstrukteure ++ Version mit kompiliert wird. Es sollte möglich sein, dies mit der Vorlage CTraceCategoryEx loszuwerden, aber ich bleibe bei dieser Methode für jetzt.

Schließlich musste ich nur die Common.lib Referenz auf die Zusätzliche Abhängigkeiten der Projekte, die darauf verweisen, hinzufügen.