We have a strong-named and obfuscated .Net v1.1 Forms exe that can run as a
stand-alone app or have its main panel control hosted by IE using an
<object> tag and AllowPartiallyTrustedCallers.  While recently testing it on
a PC with CLR v2.0 installed, it works fine in stand-alone mode running
under both v1.1 and v2.0 (specified by the app config), however, it fails
with the following exception when hosted by IE:

Zone: 1

System.Reflection.TargetInvocationException: Exception has been thrown by
the target of an invocation. ---> System.TypeLoadException: Could not load
type 'System.Int32' from assembly '**********, Version=*.*.*.*,
Culture=neutral, PublicKeyToken=****************' due to value type
mismatch.
  at *********Panel..ctor()
  --- End of inner exception stack trace ---
  at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean
publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandle&
ctor, Boolean& bNeedSecurityCheck)
  at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean
fillCache)
  at System.RuntimeType.CreateInstanceImpl(Boolean publicOnly, Boolean
skipVisibilityChecks, Boolean fillCache)
  at System.Activator.CreateInstance(Type type, Boolean nonPublic)
  at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder
binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
  at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr,
Binder binder, Object[] args, CultureInfo culture, Object[]
activationAttributes)
  at System.Activator.CreateComInstanceFrom(String assemblyName, String
typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
  at System.AppDomain.CreateComInstanceFrom(String assemblyFile, String
typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
  at System.AppDomain.CreateComInstanceFrom(String assemblyFile, String
typeName, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm)
  at Microsoft.IE.SecureFactory.CreateInstanceWithSecurity(Int32 dwFlag,
Int32 dwZone, String pURL, String uniqueIdString, String link, String
licenses)

First, we cannot figure out why the CLR would try to load type System.Int32
from our assembly and second, we do not know how the unmanaged IExplore.exe
decides which CLR version to use when hosting a control loaded via the
<object> tag.  Placing an IExplore.exe.config file (with requiredRuntime
specified) into the folder with IExplore.exe on the client PC does the trick
but is not a viable option unless the customer agrees to this restriction
for all IE-hosted .Net controls.  Placing an IExplore.exe.config on the
server does not work because the file is not examined by the client until
after the CLR version decision is made (and even if it did work it would
make the CLR version server-global instead of client-global).  We realize
that unification generally precludes the hosted control from dictating the
CLR version to the host process but it seems that that option is needed on a
per-control basis for a generic host such as IE.  At this point, if the CLR
can't figure out that System.Int32 is in Mscorlib and we can't dictate which
CLR version IE should use when hosting our control (without dictating which
CLR version IE should use when hosting every other .Net control the customer
uses) then we will be forced to rebuild the app for v2.0 and hope that it
still works on PCs that only have v1.1 installed.

Suggestions, anyone?