Freigeben über

Your feedback: How many types do you ref.emit into a module?

  • Artikel

I'm looking for feedback about Ref.Emit usage patterns.

  1. When using Ref.Emit, how many types do you generally emit into a single module?
  2. Do your scenarios generally use AssemblyBuilderAccess.RunAndSave/.Run? In other words, are you emitting code so that you can immediately execute it in the same process, or are you emitting it for some compiler scenario?

And while you're at it, swing by and give me feedback about LCG + Debuggability.

Comments

  • Anonymous
    December 08, 2006
    It would be nice to have LCG for types. In my scenario I had to generate few hundred types, it would have been nice to generate them on the fly, but the cost of creating for each one and assembly was large, so "pre-created" those classes on the startup, which is not optimal. The scenario is LOB application with AOP style. Where a base class can be abstract and derived class is generated on the fly filling in/overriding methods of the abstract base class.

  • Anonymous
    December 08, 2006
    I've built a little wrapper generator that I use on some internal projects that usually emits between 1-20 types into a module. I only emit with .Run right now, but I've considered enhancing it to cache the assemblies with .RunAndSave to save on startup costs. I can't use LCG for my wrapper generator, since I'm generating whole types, so my experiences there are pretty limited. Adding support for MarkSequencePoint and associated ICD hooks sounds a lot simpler to implement than making Ref.Emit types GC-able, and would give you the same experience you have when using Ref.Emit, right? Making Ref.Emit assemblies GC-able sounds like a nightmare waiting to happen (look at all the fun Java has with unloadable classloaders), what with all the under-the-covers type caching that goes on in reflection and other places...

  • Anonymous
    December 08, 2006
    The comment has been removed

  • Anonymous
    December 09, 2006
    Several hundreds simple types and AssemblyBuilderAccess.Run. RunAndSave only in verifying generated code.

  • Anonymous
    December 11, 2006
    The comment has been removed