A tale of eclipse bundle classpath, jre6 and managed Assemblies

Recently I ported an eclipse RCP application from jre 5 to jre6.
The application worked fine with jre 5 but failed when run with jre6.
Problem was in the native dll that tried to access code in manged assembly.

My Eclipse application invoked a native method which in turn attempted to access code in managed code in a .net assembly. .NET CLR runtime loads an assembly when it is referenced first time. CLR runtime looks for that assembly in the APPDOMAIN base directory. With eclipse 3.4.2 and jre5, APPDOMAIN base directory happens to be eclipse bundle class path (".metadata/.plugins/org.eclipse.pde.core/yourlaunchConfigName/org.eclipse.osgi/bundles/someIntegerbundleID/1/.cp").

So RCP application copied all required managed assemblies in this eclipse bundle class path before invoking native method. And CLR runtime happily loaded them.

However when RCP application was run with JRE6 under eclispe 342, the APPDOMAIN base directory was JRE_HOME/bin. AND CLR runtime didn't find required assemblies here. So that was the reason for failure.

Fix for this is to use something called AssemblyResolver in .net terminolory. If CLR runtime can not find an assembly in APPDOMAIN base directory, it looks for any regirstered AssemblyResolvers. If one found, it notifies this resolver to load the required assembly. All this resolver did is to check the name of assembly to be loaded if it is the one used by RCP application, it loaded this assembly from its installed location.

I had to write Assembly Resolver in another mixed mode dll and register this resolver from native dll before accessing managed code.