Wir haben eine C# T4-Datei namens GenerateProxies.tt, die mehrere Command-Line-Codegen-Dienstprogramme aufruft. Mit der System.Diagnostics-Prozessklasse leiten wir die Standardausgabe an die T4-Ausgabetextdatei (GenerateProxies.txt) um, sodass wir die Befehlszeilenausgabe auf Fehler überprüfen können.Visual Studio-Serialisierungsfehler, wenn T4 DTE verwendet, um generierte Datei zu öffnen
Ich habe den folgenden einfachen Code am Ende des T4 hinzugefügt, so dass Visual Studio die generierte Textdatei als letzten Schritt im Prozess öffnet (die workingDirectory
Variable wird deklariert und früher in der Vorlage ausgefüllt). Das funktioniert, aber es wirft einen Serialisierungsfehler auf. Kann dieser Fehler vermieden werden?
<#@ assembly name="EnvDTE" #>
<#@ import namespace="EnvDTE" #>
<#
IServiceProvider vssp = (IServiceProvider)this.Host;
DTE dte = vssp.GetService(typeof(DTE)) as DTE;
dte.ItemOperations.OpenFile(
string.Format(@"{0}\GenerateProxies.txt", workingDirectory),
Constants.vsViewKindTextView
);
#>
Auch dies funktioniert, es die Textdatei öffnet, aber es erzeugt diesen Fehler:
Running transformation: System.Runtime.Serialization.SerializationException:
Type 'Microsoft.VisualStudio.Platform.WindowManagement.DTE.WindowBase' in
Assembly 'Microsoft.VisualStudio.Platform.WindowManagement'
is not marked as serializable.
Der Call-Stack könnte schreiben auszuführen helfen . – Will
Ja, aber leider ist es von einer Entwicklungs-VM, die überhaupt keinen externen Zugriff hat (deshalb habe ich mir nicht die Mühe gemacht, alle Assembly-Informationen, die Schlüssel-GUID usw. erneut einzugeben). Der Aufruf-Stack ist riesig, aber es sieht aus wie eine Art von PInvoke-Marshalling-Problem. Anscheinend DTE ist COM. Ich vermute irgendwie, dass es ein Threading-Problem ist. – McGuireV10
Es riecht nach etwas, das versehentlich über einen AppDomain-Rahmen gezogen wird. Der Aufrufstapel kann die Quelle identifizieren, und Sie können unten im Code im Stapel ermitteln, wer einen Verweis auf eine Instanz dieses Typs hat. – Will