All,

I am a little delayed in sending the 2008 branch as here is a nasty defect I came across:

1) When working on large projects or working over longer periods of time, it appears assemblies are generated as 'temps' for code gen. These are always loaded into the main AppDomain for the run-time of the IDE user.

2) As you cannot unload these, if you say make 10 changes to a diagram, you would be loading 10 new asssemblies which never go away into the memory space (until you restart)

3) I am not sure of 2008 has made this more pronounced, but this causes pretty bad memory 'leakage' and can make the experience of doing really serious work with   this tool almost impossible. For smaller items it's fine which may be why this has not been considered a showstopper.

4) I am almost done with a solution, however it is touching the most interesting (and complex) part of the app. Here is how this is being done (based on industry standard practices):

a) A new AppDomain is created which is the storage location for any 'temporary' CodeDom generated assemblies (these also are on my disk and even visiable in my DSL project which I cannot remember before, so the solution also deletes those). I believe a directory path is being changed from TEMP to the project. This only happens for /RANU /Exp debug testing as far as I can tell

b) After all codegen work is complete this appdomain is UNLOADED freeing in some cases a lot of memory, and in my humble opinion must be done if this tool (unless I missed something) will be production quality on enterprise apps.

3) Obviously I have to be careful as you cannot refer to 'Assembly' in AppDomain B from the main AppDomain or it loads, defeating the purpose.

Also, in order to really fix this once and for all, I have done some refactorings which make this a lot more maintainable (these are both core domain concepts of THIS Dsl - The Temp 'CodeGen' AppDomain and the Main AppDomain - where I couldn't see this before

4) This is also critical for working with the outstanding NHQG integration which is where this was causing by far the most grief due to the 'call external proc' integration. Ayende, any chance for a real API for NHQG we can use?

5) It is also a showstopper when (a fairy common thing) the versions are not in Sync with ActiveWriter and NHQG so I had to write some code to at least fail gracefully, and make a best effort to fixup that non-trivial issue).

For example, NH2.0 was in the NHQG bin dir and crashes this unless your on the NH2.0 trunk.

LOTS more but trust me, I want to move this to the owner, but right now, if you agree, these are some fairly critical items I am just about done with, If you prefer I can send as is, but due to the 'deep-end' nature of where it is right now, it might waste time that I know is precious.

Thanks,

Damon Carr