How to make a Type known in one AppDomain, but unknown in another?

Question

Dear ladies and sirs.

My question is simple. For unit test purposes, I need a statically compiled type deriving from the Exception type, which is known in one AppDomain, but unknown in another.

A straightforward solution would be:

1. To create a subfolder under the directory of the application executable.
2. Place there an assembly with some Exception derived type.
3. Update the app.config file, adding this folder to the probing path.
4. Create a new AppDomain, but with a slightly different app.config - without the element.

Now, the main AppDomain can load the type easily, because its location is in the probing path, but the second AppDomain cannot - mission accomplished.

But this method requires:

• An additional folder
• A dummy assembly
• A dummy app config file

I am wondering if I can achieve my goal simpler, but without Reflection.Emit.

Thanks.

EDIT:

Any Exception derived type will do.

Motivation:

We have a distributed application, consisting of clients, the server and agents. There are assemblies found exclusively on agents and there are some found exclusively on the server. Both the server and agents can be extended after being deployed with new features. The thing is that it is possible that some action will fail with an exception, which type is unknown on the receiving end. I am developing a facility to cope with this situation and wish to unit test it now. For that I need to simulate a situation where an exception raised on a remote site is of a type unknown on the receiving end.

Answer 1

First of all I am not aware of any way to prevent loading a type from a loaded assembly. Which mean that we need to talk assemblies - not types. Even though a certain type is not initialized until it is accessed the first time, if it will be accessed if the assembly with your type is loaded you cannot make the CLR unlearn it.

In other words you have to have a separate dll with the protected type. The rest of it can be addressed in a number of ways, i.e. instead of playing with appconfig you can load the assembly with Assembly.LoadFrom in the appdomain where you need it.

How much better this is, is for you to decide depending on what exactly you are trying to do here.

Answer 2

AppDomain.CreateDomain has overloads that accepts a AppDomainSetup. Many of the properties of this class match a corresponding entry in a .config file. Including PrivateBinPath. ApplicationBase set the "home" directory where the CLR starts searching.