Debuggen von benutzerdefinierten Resolvern von SDL Tridion 2011 und der Methode GetListPublishItems()

Question

In einem meiner C# Template Building Blocks habe ich die folgende Codezeile

publication.GetListPublishItems(uriTarget, false, false,
         TDSDefinesInterop.ListColumnFilter.XMLListDefault, listRowFilter);

Vor der Implementierung eines benutzerdefinierten Resolvers wurde dieser Code sehr schnell ausgeführt. Jetzt, da mein Resolver für den Publication ItemType implementiert ist, wird der Code sehr langsam ausgeführt. Daraus schließe ich, dass der neue Resolver hinter den Kulissen von der GetListPublishItems() Methode (was sinnvoll ist). Ich nehme an, ich muss den Resolver irgendwie ändern. Allerdings kann ich nicht scheinen, um einen Haltepunkt in meinem Resolver zu treffen, wenn die Methode aufgerufen wird.

Normalerweise verbinde ich mich mit dem "TcmTemplateDebugHost", wenn ich eine Vorlage debugge, oder direkt mit dem Publisher-Prozess, wenn ich den Resolver debugge. Mein Resolver scheint nur getroffen zu werden, wenn ich zum ersten Mal auf Veröffentlichen drücke und nicht, wenn die Methode GetListPublishItems() aufgerufen wird.

Diese Frage hat also zwei Aspekte:

1. Werden Resolver aufgerufen, wenn die Methode GetListPublishItems() verwendet wird?
2. Angenommen, sie werden aufgerufen, an welchen Prozess sollte ich anhängen, wenn ich ihn in diesem Szenario debuggen muss?

Answer 1

Ich weiß es nicht mit Sicherheit, aber ich kann mir kein vernünftiges Szenario vorstellen, in dem ein benutzerdefinierter Resolver nicht an GetListPublishItems() beteiligt wäre. Ihre Beweise scheinen dies zu untermauern, aber wenn wir den zweiten Teil Ihrer Frage beantworten können, wissen wir es natürlich mit Sicherheit.

Ich nehme an, dass alle normalen Annahmen, die Sie über den Hosting-Prozess gemacht haben, wahrscheinlich richtig sind. Wenn Sie also beispielsweise Ihre Vorlage während einer Veröffentlichung aufrufen, dann ist der TcmPublisher der Prozess. Wenn Sie alternativ den Veröffentlichungsdialog für die Veröffentlichung in der grafischen Benutzeroberfläche öffnen und auf "Zu veröffentlichende Elemente anzeigen" klicken, dann ist es wahrscheinlich der COM-Surrogatprozess (dllhost.exe) usw. Eine Möglichkeit, dies mit Sicherheit herauszufinden, ist die Verwendung des Sysinternals Process Explorer, der eine sehr praktische Funktion hat, mit der Sie nach Prozessen suchen können, die eine bestimmte DLL geladen haben. (Suchen Sie im Menü Suchen)

Ein wahrscheinlicher Grund dafür, dass ein Haltepunkt nicht greift, ist, dass Visual Studio die Symbole nicht richtig laden kann. Wenn Sie einen Vorlagenbaustein debuggen, lädt Tridion die Symbole explizit von einem bekannten Speicherort, den Sie konfigurieren können (tridion.templating/debugging/@pdbdirectory in der CM-Konfiguration), wo der Vorlagen-Uploader die PDBs ablegt. Wenn der Publisher-Prozess den benutzerdefinierten Resolver lädt, bezweifle ich, dass es einen solchen speziellen Mechanismus gibt, um die Symbole zu lokalisieren, also müssen Sie auf Standard-.NET-Methoden zurückgreifen. Als Erstes würde ich versuchen, sicherzustellen, dass sich die Symbole für die benutzerdefinierte Resolver-Klasse am selben Ort wie die Assembly befinden (d. h. in Ihrem bin-Verzeichnis). Wenn das nicht möglich ist, könnten Sie vielleicht einen Symbolpfad in Visual Studio konfigurieren.

Als erstes sollten Sie sich die Debug-Ausgabe in Visual Studio ansehen. Wenn Sie den Prozess starten und dann an ihn anhängen, sehen Sie, wie die verschiedenen Baugruppen geladen werden. Wenn Visual Studio die Symbole finden kann, sehen Sie, dass die Ausgabe "Symbols Loaded" lautet.