views:

421

answers:

2

We use the DesignSurface and all that good IDesignerHost goodness in our own designer. The designed forms are then persisted in our own bespoke format and all that works great. WE also want to export the forms to a text-based format (which we've done as it isn't that difficult).

However, we also want to import that text back into a document for the designer which involves getting the designer code back into a CodeCompileUnit. Unfortunately, the Parse method is not implemented (for, no doubt, good reasons). Is there an alternative? We don't want to use anything that wouldn't exist on a standard .NET installation (like .NET libraries installed with Visual Studio).

My current idea is to compile the imported text and then instantiate the form and copy its properties and controls over to the design surface object, and just capture the new CodeCompileUnit, but I was hoping there was a better way. Thanks.


UPDATE: I though some might be interested in our progress. So far, not so good. A brief overview of what I've discovered is that the Parse method was not implemented because it was deemed too difficult, open source parsers exist that do the work but they're not complete and therefore aren't guaranteed to work in all cases (NRefactory is one of those from the SharpDevelop project, I believe), and the copying of controls across from an instance to the designer isn't working as yet. I believe this is because although the controls are getting added to the form instance that the designer surface wraps, the designer surface is not aware of their inclusion. Our next attempt is to mimic cut/paste to see if that solves it. Obviously, this is a huge nasty workaround, but we need it working so we'll take the hit and keep an eye out for alternatives.

+2  A: 

It's not exactly what you asked for, but you could try to use the CodeDomComponentSerializationService class to generate the CodeDom graph based on the current state of the design surface.

We use that class to handle copy/paste functionality in our built-in designer.

Jason Diller
Yes, we already do this to get the source out of the surface, but we want to put the source back into the surface, which is causing the issue.
Jeff Yates
+2  A: 

You could always right your own C# parser. That way you can be sure of it's completeness.

In your case, because you don't need anything like intellisence, you could probably get away with just using a parser generator.

Even if you wrote one by hand, however, it probably wouldn't take you more than about a month.

Scott Wisniewski
I was hoping to avoid needing to make this effort. The problem is time - this feature, though required, isn't important enough to warrant the time investment for writing a language parser. I'm still considering it though.
Jeff Yates
In general, the VS CodeDom is pretty incomplete. It hasn't kept up with languages changes in since V7. I think, for the sake of your product, you probably should write your own parser. It's the only way you'll be sure that you can respond to future language changes.
Scott Wisniewski