IMO your AppDomain does not avoid the leaks, at least if you mean the leaking of temporary assemblies and Type objects.
Please correct me if I am missing something:

1. While loading the Dyno.dll assembly (line 37: ‘domain.Load(…)’) into the temporary AppDomain, the assembly is also loaded into the “main” (current) AppDomain. I suppose that is because AppDomain.Load() returns the loaded assembly, which actually serializes/deserializes the assembly from the temporary to the main AppDomain.

2. When unwrapping the object handle (line 48: ‘instance = instanceHandle.Unwrap()’), the same occurs with the created EnumerableResultsCreator. I.e. it is copied by (de-)serialization from the temporary to the main AppDomain (for this to succeed, the downloaded code correctly has a [Serializable] attribute on EnumerableResultsCreator, which is missing in the code in your post).
All subsequent accesses to the instance then occur in the main AppDomain, thus the temporary AppDomain is actually useless.
For each call to DataLoader.ObtainFlattenedResults(), the invocation of EnumerableResultsCreator.ObtainFlattenedResults() (through reflection, see line 52: ‘results = instance.GetType()…’) finally uses CSharpCodeProvider.CompileAssemblyFromSource() to compile the dynamic code. The dynamic code actually contains two class types: ‘ResultsWriter’ and the anonymous type from the linq expression.
CompileAssemblyFromSource() creates a dynamic assembly for these types. And as the EnumerableResultsCreator ‘instance’ resides in the main domain, the assemblies are also loaded into that domain. So there is one dynamic assembly with two types for each DataLoader.ObtainFlattenedResults() call => leak.
You can nicely inspect the effect by setting a break point after ‘results = instance…’ (i.e. line 62 in your code snippet) and watch AppDomain.CurrentDomain.GetAssemblies() growing.

As I understand it there are two options for using an object accross AppDomains:
Either the object is serialized/deserialized from the source domain to the target domain (which needs the respective class to be [Serializable] as in your example), resulting in actually two instances, one per AppDomain. Here unloading the source AppDomain has no effect since the target AppDomain works on a copy of the object.
Or a proxy for the object is created in the target domain (which needs the respective class to derive from MarshalByRefObject). In this case, unloading the source AppDomain invalidates the proxy, so each subsequent call to the proxy will result in an exception.

To develop a dynamic data library for the company I work for (see http://www.quinlogic.com) I was also looking for a way to dynamically create types (classes) which only exist temporarily. For my understanding this can be achieved with a temporary AppDomain, if all accesses to the “dynamic” types are only made in that AppDomain.
This is not very convenient. My favourite approach would be if a dynamically created Type (and its associated code) is (optionally) subject to garbage collection. I.e. the type and its code is collected if the last instance of that type has gone. To my knowledge this is not possible with .NET/CLR.

These are some excellent comments.

And to be honest I was under the impression that you could unload and appDomain and it would also unload any items that were dynamically loaded into it.

I shall have to look into this a bit further. Ill try and do that soon and write my findings here.

Thanks for pointing this out.

IMO the AppDomain – as you use it – still leaks in dynamic assemblies and the type objects in these assemblies:

1. ‘domain.Load()’ loads the dyno.dll into the temporary AppDomain. But as a side effect of returning the loaded assembly, the AppDomain.Load() also serializes/deserializes dyno.dll into the current (”main”) AppDomain.

2. When calling ‘instanceHandle.Unwrap()’, the ‘EnumerableResultsCreator’ object is deserialized/serialized into the current (main) AppDomain (for this to succeed the download code correclty contains the necessary [Serializable] attribute which is omitted in the snipped of your post).
Thus the now unwrapped ‘EnumerableResultsCreator’ instance (along with its type object) lives in the main AppDomain and so do the classes dynamically compiled during ‘ObtainFlattenedResults’.
To see the effect you can set a breakpoint right after the ‘results = …’ in DataLoader.ObtainFlattenedResults (line 62 in your code snippet) and watch AppDomain.CurrentDomain.GetAssemblies() growing. For each call to DataLoader.ObtainFlattenedResults() a new assembly containing the dynamically compiled types is added to the domain.

As I understand it, you simply cannot unload an AppDomain and still use an object residing in that domain.
Either the object does not “really” reside in the AppDomain, but has been serialized/deserialized into the calling AppDomain (which needs the respective class to be [Serializable], as your EnumerableResultsCreator); or the object is accessed through a proxy (which needs the respective class to derive from MarshalByRefObject). In the latter case the proxy is “dead” after unloading the AppDomain.

A real nice feature to support dynamic applications would be that Type objects and the code associated with them would be (optionally?) subject to garbage collection. I.e. the Type and code is unloaded as soon as the last instance of that type is gone. But – AFAIK – this is not possible in .NET/CLR.