I am experiencing the same issue in Azure. The problem is that even though I have
set to true, the plugins/bin folder continues to hold a copy of the .dlls. The exception I different each time depending on which .dll it has the issue with, but here is an example:
An error occurred while starting the application.
FileLoadException: Could not load file or assembly 'D:\home\site\wwwroot\Plugins\bin\Nop.Plugin.Payments.AuthorizeNet.dll'. Access is denied.
So I decided to dig further into the code to find out exactly where this is happening, which is a bit tough because I can't reproduce the issue regularly. It happens about 25% of the time the application restarts. The best I can figure is that the sequence in the code is:
ApplicationPartManagerExtensions.InitializePlugins - this is where it all starts.
At line 419, it checks the ClearPluginShadowDirectoryOnStartup value and, if it is true, attempts to delete each file in the directory. If it fails, it just gobbles up the exception.
A little further down, it runs PerformFileDeploy for each of the plugin assemblies. Once there, it checks to see if it should be using the shadow copies or not. I have that set to false, so it steps into
at line 193.
Here is what I don't understand. Its failing at this on line 160 within the AddApplicationParts method:
assembly = Assembly.UnsafeLoadFrom(assemblyFile);
And the exception I get shows that it is trying to load the DLL from the Plugins/bin folder --- which is the very folder it was supposed to have deleted the files from earlier in the code. So if I have use shadow copies set to false, why is it trying to load a file from that folder?