Mitigation: Deserialization of Objects Across App Domains
In some cases, when an app uses two or more app domains with different application bases, the attempt to deserialize objects in the logical call context across app domains throws an exception.
Diagnosing the issue
The issue arises under the following sequence of conditions:
An app uses two or more app domains with different application bases.
Some types are explicitly added to the LogicalCallContext by calling a method such as LogicalCallContext.SetData or CallContext.LogicalSetData. These types are not marked as serializable and are not stored in the global assembly cache.
Later, code running in the non-default app domain tries to read a value from a configuration file or use XML to deserialize an object.
In order to read from a configuration file or deserialize the object, an XmlReader object tries to access the configuration system.
If the configuration system has not already been initialized, it must complete its initialization. This means, among other things, that the runtime has to create a stable path for a configuration system, which it does as follows:
It looks for evidence for the non-default app domain.
It tries to calculate the evidence for the non-default app domain based on the default app domain.
The call to get evidence for the default app domain triggers a cross-app domain call from the non-default app domain to the default app domain.
As part of the cross-app domain contract in the .NET Framework, the contents of the logical call context also have to be marshaled across app domain boundaries.
Because the types that are in the logical call context cannot be resolved in the default app domain, an exception is thrown.
To work around this issue, do the following
Identify the place in the app where no objects are added to the logical call context and add the following code: