Is it possible to use Assembly.ReflectionOnlyLoad together with publisher policies / assembly versioning?

Question

My target:

We are allowing to integrate our product with third party components (libraries) which are not installed as part of our product because of licensing. At the moment we want to load features related to third party components only if these components are installed on the client's machine.

Current solution:

I'm using Assembly.ReflectionOnlyLoad with providing full names of third party assemblies to validate installation of third party components before the application loads related features. This works for following scenarios:

• Exact versions of libraries are installed to GAC
• Exact versions of libraries are copied to application directory / probing paths

Problem:

Now I need to modify the solution to support publisher policies (redirecting assembly binding to new version). I just tested my code and it looks like ReflectionOnlyLoad ignores publisher policy deployed to GAC so my mechanism will not load expected features even third party assemblies are correctly installed (new version with assembly redirection).

If I remove my validation (= features will be loaded every time) the application will correctly load new version of third party assemblies so publisher policy works correctly because features are still compiled with dependency to old version.

How to validate existence of the assembly in both GAC and probing paths when using versioning and assembly redirection?

Answer 1

It seems you can call AppDomain.ApplyPolicy to have the policies applied to the assembly name. You can then call ReflectionOnlyLoad() on the returned name.

Answer 2

You can't by using just ReflectionOnlyLoad.

The entire purpose of ReflectionOnlyLoad and friends is to be able to inspect the assembly metadata without regard to policy and versioning.

Junfeng Zhang explains this in his examination of the ReflectionOnlyLoad methods.

I suspect that if you want to apply policy to loading, you'll need to load the assemblies in a separate AppDomain and do reasoning about them there. The benefit of this approach will be that you will be able to unload the AppDomain you use for reflection and verification. The downside is it introduces significant complexity. I don't see much alternative, however.

Once you have a separate AppDomain, you will need to have some MarshalByRefObject class to allow you to do verification in the remote AppDomain from your main one. That class can be loaded into the remote AppDomain and also do any Assembly.Load calls, keeping track of the results. When it is done, you return some kind of report to the caller in the main AppDomain. Finally, you can unload the remote AppDomain. The types you loaded there will not have been loaded in the main AppDomain.