That is an interesting thought. I experimented with it a little and the results are encouraging but I am not sure that it will work as expected in all cases.
In my test I create a temporary AppDomain, invoke LoadFrom on the filepath, get the assembly's fullname, destroy the temp appdomain, add the relative path to the private bin path, and then invoke Load using the fullname of the assembly. The idea is that I want to ensure that I get a loaded assembly that matches the full 4-part name of the assembly at the specified location. (My Christmas wish: A .NET method that would get the full 4-part name of an assembly from a file without loading the assembly into the appdomain.) What is unclear to me is if the clr loader will actually resolve this the way I want it to. According to Box's Essential .NET, after all versioning policies have been applied (which may completely change what it is looking for - in my case this should not occur), and it looks next at CODEBASE hints. He states that if found via a Codebase hint it is loaded as if LoadFrom was used...does this mean it is loaded and cached as per a path- based reference? If so then this will create the same problem I am trying to avoid. If the CODEBASE hint fails it then begins probing. The assembly resolver constructs a CODEBASE URL based on the simple name of the assembly, the relative search path, and the culture. If a file is found probing stops and it verifies that the file matches all properties of the assembly name. If it does not then the Load fails, which in the case of multiple versions of the same assembly could occur. Presumably if it matches successfully the assembly is cached in the non-path based cache, otherwise the same problem will occur. Box does not mention when the AssemblyResolve event occurs. Assuming that it occurs after this point I then do my own probing. If I find an assembly to use and call LoadFrom on it to satisfy the probe I assume it will store the assembly in the path-based cache and I will again likely run into the same problem I am trying to avoid. It still isn't clear to me how MS determines which files get added to the path-based cache and which are added to the statically referenced cache. Oh well, have a happy holiday! cheers On Thu, 19 Dec 2002 15:56:47 -0500, Zaslavskiy, Dmitriy <[EMAIL PROTECTED]> wrote: >What about trying to avoid LoadFrom() all together. >i.e. update private bin path and do Load()? > >-----Original Message----- >From: Dave [mailto:[EMAIL PROTECTED]] >Sent: Thursday, December 19, 2002 8:23 AM >To: [EMAIL PROTECTED] >Subject: [ADVANCED-DOTNET] Assembly isolation > > >http://www.gotdotnet.com/team/clr/LoadFromIsolation.aspx > >My development team has stumbled into a problem that's described by this >article. Our app uses plug-in assemblies for specialized functionality; >each one is located in a separate subdirectory below the main app >directory. One of these has a static dependency to another plugin, so >that the resultant directory and file layout looks like... > You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
