2008-09-30 7 views
5

Wir verwenden die DesignSurface und all das gute IDesignerHost Güte in unserem eigenen Designer. Die entworfenen Formen werden dann in unserem eigenen maßgeschneiderten Format beibehalten und alles, was gut funktioniert. Wir möchten auch die Formulare in ein textbasiertes Format exportieren (was wir gemacht haben, da es nicht so schwierig ist).Gibt es eine Möglichkeit, Quellcode wieder in eine CodeCompileUnit umzuwandeln?

Wir möchten diesen Text aber auch wieder in ein Dokument für den Designer importieren, bei dem der Designercode wieder in eine CodeCompileUnit eingefügt wird. Leider ist die Parse-Methode nicht implementiert (aus gutem Grund). Gibt es eine Alternative? Wir möchten nichts verwenden, was auf einer Standard-.NET-Installation nicht vorhanden wäre (wie .NET-Bibliotheken, die mit Visual Studio installiert wurden).

Meine aktuelle Idee ist, den importierten Text zu kompilieren und dann das Formular zu instanziieren und seine Eigenschaften und Steuerelemente auf das Design-Oberflächenobjekt zu kopieren und nur die neue CodeCompileUnit einzufangen, aber ich hoffte, dass es einen besseren Weg gab. Vielen Dank.


UPDATE: Ich denke, dass einige an unserem Fortschritt interessiert sein könnten. So weit, nicht so gut. Ein kurzer Überblick über das, was ich entdeckt habe, ist, dass die Parse-Methode nicht implementiert wurde, weil sie als zu schwierig erachtet wurde. Open-Source-Parser existieren zwar, sind aber nicht vollständig und funktionieren daher nicht in allen Fällen (NRefactory ist einer von denen aus dem SharpDevelop-Projekt, glaube ich), und das Kopieren von Steuerelementen von einer Instanz auf den Designer funktioniert noch nicht. Ich glaube, das liegt daran, dass, obwohl die Steuerelemente der Formularinstanz hinzugefügt werden, die die Designeroberfläche umschließt, die Designeroberfläche ihre Einbeziehung nicht bemerkt. Unser nächster Versuch ist es, cut/paste zu imitieren, um zu sehen, ob das das Problem löst. Offensichtlich ist dies eine große, fiese Lösung, aber wir brauchen es, damit wir den Hit nehmen und nach Alternativen Ausschau halten.

+0

Ich würde gerne die Antwort auch wissen, aber meine Angst ist, dass es keine gibt. – ZeroBugBounce

+0

Ich suche auch wirklich nach einer Lösung dafür. Ich würde gerne neue Funktionen einfach mit vorhandenem Code zusammenführen, vorzugsweise durch Parsen einer Codedatei, und dann Hinzufügen neuer Member, nach denen ich das Skript aus der zusammengeführten CodeCompileUnit erstellen würde. – Statement

Antwort

2

Sie könnten immer Ihren eigenen C# Parser schreiben. So können Sie sicher sein, dass es vollständig ist.

In Ihrem Fall, weil Sie nichts wie Intellisense benötigen, könnten Sie wahrscheinlich mit nur einem Parser-Generator durchkommen.

Auch wenn Sie einen von Hand geschrieben haben, würde es wahrscheinlich nicht mehr als einen Monat dauern.

+0

Ich hatte gehofft zu vermeiden, diese Anstrengung zu machen. Das Problem ist die Zeit - diese Funktion ist, obwohl sie erforderlich ist, nicht wichtig genug, um den Zeitaufwand für das Schreiben eines Sprachparsers zu rechtfertigen. Ich denke immer noch darüber nach. –

+0

Im Allgemeinen ist das VS-CodeDom ziemlich unvollständig. Seit V7 hat es nicht mit den Änderungen der Sprachen Schritt gehalten. Ich denke, um Ihres Produkts willen sollten Sie wahrscheinlich Ihren eigenen Parser schreiben. Nur so können Sie sicher sein, dass Sie auf zukünftige Sprachänderungen reagieren können. –

2

Es ist nicht genau das, wonach Sie gefragt haben, aber Sie könnten versuchen, die CodeDomComponentSerializationService-Klasse zu verwenden, um das CodeDom-Diagramm basierend auf dem aktuellen Status der Entwurfsoberfläche zu generieren.

Wir verwenden diese Klasse, um die Copy/Paste-Funktionalität in unserem integrierten Designer zu handhaben.

+0

Ja, wir tun dies bereits, um die Quelle aus der Oberfläche zu bekommen, aber wir wollen die Quelle wieder in die Oberfläche bringen, was das Problem verursacht. –

Verwandte Themen