Dealing with Assembly-Sharing Issues

for RuBoard

Both the previously described techniques have an impact on the use of shared assemblies. Shared assemblies are those that are loaded into multiple appdomains and, although they are logically distinct from one another, share the same compiled code. This is an optimization that reduces the amount of memory needed to hold the compiled versions of the assembly's methods and also the time needed to compile (JIT) them.

There are three styles of assembly sharing that can be enabled (these can all be configured through XML application configuration files, which are beyond the scope of this book):

• Share nothing except mscorlib (this library is always shared).

• Share only strongly named assemblies.

• Share all assemblies.

The problem we face here is that the compilation of managed code from IL to native instructions (commonly called jitting ) is sensitive to the permissions granted to the code. Declarative actions, such as LinkDemand or InheritanceDemand , might cause some methods to be unavailable in certain trust scenarios. Therefore, it would be a potential security hole to allow two appdomains to share the code of an assembly that has been loaded with different security contexts.

Normally, this isn't a problem; loading an assembly multiple times in different appdomains will yield the same grant set each time because policy is deterministic (and reads from the policy database only once per process). After we start altering the policy system dynamically at runtime, either through additional evidence or by adding appdomain specific policy levels, we lose that determinism and conflicts can result.

Unfortunately, due to the design of assembly sharing with V1 of the .NET Framework, such a conflict cannot be resolved transparently (there is no mechanism to allow more than one version of a shared assembly to be loaded in the same process). Consequently, any attempt to load an assembly that would result in a grant set different from that of a previously loaded version of that assembly will result in an error (a FileLoadException will be thrown).

As a result, it's important to carefully plan how you're going to handle the loading of assemblies. A good start is to determine which standard library assemblies will be needed. These should be loaded without modified evidence or before appdomain policy is set. The remaining assemblies must then be a disjoint set; they will only be loaded as hosted assemblies and will never form part of the implementation of the host (in particular, the host's default appdomain will never load them).

for RuBoard