Hi Joshua,
Thanks for your comments. I was also thinking about implementing my own
graph
for the code to be generated. And agree that CodeDOM is very powerful,
that's a
good enough point to stick with it.

cheers!



On 05/02/2008, Joshua <abusement@...> wrote:
>
> In my opinion, CodeDOM, while very powerful is also very frustrating to
> work
> with. I also have created a code generator; however the code for the
> classes that I kick out is so complex that I found CodeDOM to be far too
> cumbersome and tedious. I mean, who wants to write 60 lines of CodeDOM
> code
> to generate 3 simple overloaded methods and add them to the graph.
> Additionally I wanted to structure the code that was kicked out in a way
> that CodeDOM just didn't seem flexible enough to accomplish.
>
> My approach has been to create my own code generation providers that
> inherit
> from the built in ones. Then, I create my own object graphs that represent
> the various elements that the code generator needs to create and pass them
> into the custom language specific custom code providers. In pseudo code:
>
> Public class PersonClassGraph{
> public string classname;
>
> Public string namespace;
>
> Public bool generateSomeMethod;
> }
>
> Public class CustomCSharpCodeProvider : CSharpCodeProvider{
> public void GenerateCodeForPerson(PersonClassGraph graph, TextWriter
> writer){
> // do whatever logic here to generate your code, probably using
> the text writer to just write out code manually.
> }
> }
>
> The object graphs that I make are FAR simpler than anything represented in
> CodeDOM, simply because the data that the graph will contain are going to
> be
> represented by the basic data types in .net. The drawback however is that
> now you have to create your own rendering code that normally would be
> handled by CodeDOM and the language specific code providers. Personally
> though I've found this to be far more manageable since you're basically
> just
> writing out language specific code to a text writer, and again you have
> full
> control over the code that's being generated.
>
> The CodeDOM folks will argue the benefits of that framework, and they are
> definitely valid, though if you have code that you want generated that
> code
> dom just doesn't support you will have to resort to writing your own
> provider system. I wanted my code to use the null coalescing operator.
> Unfortunately this operator is only supported by C#; vb.net requires a
> different programming structure to get the same functionality. Because of
> this, CodeDOM doesn't expose a method to generate this operator and the
> only
> way to get my code to generate the way that I wanted it to be was to roll
> my
> own system.
>
> I don't know that this answers your question, but it might give you
> another
> avenue to explore.
>
> Josh
>
> http://hurtsmybrains.wordpress.com <http://hurtsmybrains.wordpress.com/>
>
> _____
>
> From: vsnetaddin@yahoogroups.com <vsnetaddin%40yahoogroups.com> [mailto:
> vsnetaddin@yahoogroups.com <vsnetaddin%40yahoogroups.com>] On
> Behalf Of rishiparkhe
> Sent: Monday, February 04, 2008 11:09 PM
> To: vsnetaddin@yahoogroups.com <vsnetaddin%40yahoogroups.com>
> Subject: [vsnetaddin] Code generation and reverse engineering
>
> Hello all,
>
> I am writing a visual tool that would create custom classes, currently
> it uses CodeDOM.
> I am stuck a point where I need to parse the code for getting the type
> of the custom classes (if they are to be used in another custom class)
>
> For eg:
> class A {
> public int foo;
> }
>
> class B {
>
> public A instance_A;
> }
>
> For this I would have to build the solution and get the Type of A from
> the assembly ?
>
> or
>
> Should I use codeModel, but then I would have to generate code using
> FileCodeModel as well.
>
> Any thoughts ?
>
> Thanks.
>
> [Non-text portions of this message have been removed]
>
>
>



--
keep rendering your thoughts
http://freewebs.com/rishiparkhe


[Non-text portions of this message have been removed]