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

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 (5)

  1. dimkaz says:

    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.

  2. Matt Davis says:

    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…

  3. I speak here as a developer on Dyanmic Proxy, Rhino Mocks and NHibernate. (the latter two uses the first)

    In general, DP uses a single module for all its generation, which may have several hundreds types in it.

    Using RunAndSave is generally done so I could inspect the generated assembly in Reflector.

  4. Dze says:

    Several hundreds simple types and AssemblyBuilderAccess.Run.

    RunAndSave only in verifying generated code.

  5. 10s of types are generated from metadata into interfaces and persistent objects (NHibernate) to use for 2 scenarios –

     1. Design time, for reflection / intellisense

     2. Persisted assemblies are loaded on web server for execution.