I am creating a seperate appdomain to host assemblies having less than
full trust.  The second appdomain has a different ApplicationBase path
then the host.  I created a "DomainBroker" instance that implements
MarshalByRefObject to instruct load and execute the less then full
trust assemblies in the seperate domain so that the extra assembly will
not be loaded into the hosting domain.  This broker class is defined in
the hosting assembly so the host assembly will be loaded into the
second domain as well.  I used
AppDomain.CreateInstanceFromAndUnwrap(brokerType.Assembly.Location,
brokerType.FullName) to create the broker and this works fine.  However
when I send a serializable object also defined in the host assembly to
the broker it fails to deserialize with FileNotFoundExcetion because it
cannot find the hosting assembly, which is already loaded into the
remote domain.

I discovered it seems that when LoadFrom(path) is used, future
resolutions for that same assembly using Assembly.Load(fullname) will
still fail.  Here is a simple test that demonstrates the issue:
Create anotherAssembly.dll just a basic new class library solution with
a strong name.
Then create a console app with the following code:

using System.Reflection;
class Class1
{
[STAThread]
static void Main(string[] args)
{
    try
    {
        Test();
        Console.WriteLine("TEST PASSED");
    }
    catch(System.Exception ex)
    {
        Console.WriteLine("TEST FAILED");
        Console.WriteLine(ex.ToString());
    }
    Console.ReadLine();
}

static void Test()
{
    string anotherAssemblyLocation =
        "../../../AnotherAssembly/bin/debug/AnotherAssembly.dll";

    Assembly anotherAssembly = Assembly.LoadFrom(anotherAssemblyLocation);

    if(!IsLoaded(anotherAssembly.FullName))
        throw new ApplicationException("Assembly is not loaded");
    if(anotherAssembly.GetName().GetPublicKey().Length == 0)
        throw new ApplicationException("Assembly does not have strong name");

    Assembly.Load(anotherAssembly.FullName);
}

static bool IsLoaded(string assemblyName)
{
    foreach(Assembly a in AppDomain.CurrentDomain.GetAssemblies())
    {
        if(a.FullName == assemblyName)
            return true;
    }
    return false;
}
}

The LoadFrom works fine I verify that it has been loaded into the
domain (however pointless this seems) and that it has a strong name.
When assembly Assembly.Load() (as I'm assuming the serilizer is doing
when I pass my across my host object) fails even when the assembly is
already loaded.  I've also created another test where
anotherAssembly.dll is placed in the application directory or GAC and
the result is that the assembly is loaded into the application domain
twice.

Is this a bug? or is there a good reason why the framework behaves this
way?

There are a couple of solutions I've found:
Place the host assembly in the GAC and use Load instead of LoadFrom (to
prevent loading same assembly twice).
Disadvantage: Additional deployment steps and requires admin rights to
update GAC (so much for using a post-build script when running VS as
least privalaged user! well I guess I can write a post build utility to
impersonate admin before running gacutil.. there's always something to
making LPU dev more difficult then it needs be..., anyway)

Copy the host assembly to the ApplicationBase directory of the
secondary domain.
Disadvantage: versioning nightmare if not kept in sync, and
deserialization will fail;  Restricting CAS permissions with Url
security policy doens't seem to work correctly. (I found that if I
create a level final code group with url policy file://scriptdir/* with
only execution permission and a child code group with
file://scriptdir/hostassembly.dll with fulltrust then hostassembly.dll
still only recieves execute permission not the union of fulltrust and
execution... even though evaluate assembly policy shows the
hostassembly code group being applied.. perhaps I missed something,
anyways the first reason is bad enough).

Create an AssemblyResolve event handler with this pointless looking
code:
foreach(Assembly a in AppDomain.CurrentDomain.GetAssemblies())
{
 if(args.Name == a.FullName && a.GetName().GetPublicKey().Length > 0)
   return a;
}
return null;

Disadvantage: Only runs after resolution fails thus slightly degrading
performance; and ? (is there some valid reason the Assembly.Load does
not check the currently loaded assemblies, a security issue perhaps?
and would doing this expose that vunerability? without strong name I
might see this being an issue where a fulltrust assembly loads an
assembly from a different path into the app domain and then a
non-fulltrust assembly attempts to use a differenet assembly with same
name from its applicationbase but instead gets the preloaded one, so I
guess that could be bad.  However, with a strong named assembly I don't
see this being an issue?)

Thanks,

- Kurt