It’s relatively easy to find a set of instructions for using caspol or Admin UI to provide a CAS elevation for some managed code that’s hitting security exceptions. However, using the directions correctly gets complicated when multiple runtimes are on the machine. The reason is that each CLR has its own set of policy levels, and none of the runtimes look at the previous policy levels when making trust decisions.

This can bite you in the obvious way, for instance using the v1.1 caspol to trust an application, but the application runs against the v2.0 CLR. And it can bite in non-obvious ways; such as making a trust decision in the 32 bit v2.0 CLR, but having the application run against the 64 bit v2.0 CLR.

Most applications are going to float forward to the newest runtime on the machine, such as any managed application without a configuration file locking it to a specific runtime, or any application being invoked via COM interop. This means that installing a new runtime on the machine may have the effect of losing the trust decisions you’ve made for previous versions.

(Incidentally, if you’re writing a runtime host, this confusion is reason #5 to choose the simple sandboxing model vs the legacy AppDomain policy model)

If you need to know which CLR a process is using so that you can make the trust decision on the correct runtime, one way is to use a tool like Process Explorer or windbg to examine the modules loaded in the application. Check the path that mscorwks.dll or mscorsvr.dll is being loaded from – and that will point you at the CLR which is executing the application:

Of course, if you control the code, you can always insert a call to System.Environment.Version to get the currently loaded runtime.