That fact that the assembly type definition in the configuration file is unreferenced is a furfy.
As previously mentioned Unity uses the default CLR loading mechanism to load assemblies and types. The CLR engine needs to be able to locate the assembly and it has a defined set of lookup locations ( ie Same path and owning process, bin folder, GAC,
And just because you register the mapping in code doesn't mean that it won't fail at runtime. Delete the referenced assembly from the folder after you compile/deploy and you will get the same problem, Managed .NET does not link or embed the referenced
assembly into the resultant DLL or EXE.
"...automatically cause the assemblies in which these types are defined to be loaded."
Yes in VS or by the compiler, if the referenced assembly is not available at runtime, you will get the same failure when the appdomain loads all referenced assemblies.
You have a couple of choices to resolve this issue
1. Sign all unreferenced assemblies ( and their dependencies ) and place them in the GAC. The CLR will always look in here.
2. Make sure all runtime dependencies are deployed along with your application ( ie in BIN folder for ASP.NET, same folder for others ) using your deployment system/scripts
3. Add additional folders to the AppDomain's assemblies resolution paths to correspond where these runtime dependencies are deployed to
If you still have problems, turn on the Fusion logs so that you can see where the CLR has looked for your assemblies