Resolves a two-version DLL problem in IIS cache directory temporary ASP. Nopcommerce (ii)

In the above resolution Nopcommerce in IIS cache directory temporary ASP. Two versions of DLL problem (a) already know in Nopcommerce, as long as the plug-in project references a third-party DLL, the "Copy Local" Set to False, the plug-in will not replicate third-party DLLs to the IIS cache directory, and there will be no two-version DLL issues. But later think, in their own plug-in refers to the file and the site does not reference the case, the plugin reference DLL "Copy Local" set to False, the site will still have no reference file found. So I went to see the Nopcommerce project specifically dealing with the plugin input directory class PlugInManager.

In the Nopcommerce 3.9.0 version of the PlugInManager class 140 line, there is the following code:

// load all other referenced assemblies                            now foreach (var in pluginfiles                                =! ) X.name.equals (Mainpluginfile.name, stringcomparison.invariantcultureignorecase))                                =! isalreadyloaded (x)))                                    Performfiledeploy (plugin);

This code is meant to load the third-party DLLs referenced by the plug-in. As mentioned in the previous article, the official document is the recommended plugin reference DLL all set "Copy Local" to False

Important: Going forward make sure "Copy local" properties of all Third-party assembly references (including core libraries such as N Op. Services.dll or Nop.Web.Framework.dll) is set to "False" (Does not copy)

The official document here does not say the whole, actually should be if the site has been referenced to the case, the plug-in reference DLL should be "Copy Local" set to False, the site is not referenced, or to output to the plug-in output directory as usual.

Then look back to the class PlugInManager load plug-in reference DLL code, since this method has already been, why there is a version inconsistency problem. Look at this code, the biggest suspicion is isalreadyloaded this method, if the isalreadyloaded is false, then will go to the plugin output directory to look for DLLs.

Look at the Isalreadyloaded method:

        Private Static BOOLisalreadyloaded (FileInfo FileInfo) {//Compare full assembly name//var fileassemblyname = Assemblyname.getassemblyname (fileinfo.fullname); //foreach (Var A in AppDomain.CurrentDomain.GetAssemblies ())//{            //if (a.fullname.equals (Fileassemblyname.fullname, stringcomparison.invariantcultureignorecase))//return true; //}            //return false; //Do not compare the full assembly name, just filename            Try            {                stringFilenamewithoutext =path.getfilenamewithoutextension (fileinfo.fullname); if(Filenamewithoutext = =NULL)                    Throw NewException (string. Format ("cannot get file extension for {0}", Fileinfo.name)); foreach(varAinchAppDomain.CurrentDomain.GetAssemblies ()) {                    stringAssemblyName = A.fullname.split (New[] {',' }).                    FirstOrDefault (); if(Filenamewithoutext.equals (AssemblyName, stringcomparison.invariantcultureignorecase))return true; }            }            Catch(Exception exc) {Debug.WriteLine ("cannot validate whether an assembly is already loaded."+exc); }            return false; }

Thus, the PlugInManager class determines whether the DLL has been loaded with

AppDomain.CurrentDomain.GetAssemblies ()

Debug discovery, empty the IIS cache directory the first time debug, enter the plug-in initialization, AppDomain.CurrentDomain.GetAssemblies () This method loads 89 assemblies.

The second debug, AppDomain.CurrentDomain.GetAssemblies () This method only loaded 22 assemblies, the second time debugging, although the plug-in directory appears in the IIS cache directory of other DLLs exist, but this method is not obtained, So the other DLLs in the plug-in directory will be loaded into the IIS cache directory.

But why did the two boot debug AppDomain.CurrentDomain.GetAssemblies () get a different assembly? Is it related to the mechanism of IIS? temporarily unknown.

Summary: Nopcommerce for plug-in development, referring to the third-party file if the site has already been referenced, you need to set the reference "Copy Local" to False, if the site does not have a reference, or to replicate the local, otherwise if it is not a full-volume update but the package update, It is very easy to get a different version of the plug-in directory DLL from the site Bin directory, causing the update to fail.

Resolves a two-version DLL problem in IIS cache directory temporary ASP. Nopcommerce (ii)