It would seem that the framework is opening the assemblies in the specified plugin folder exclusively and not allowing these files to be changed.
My Application_Start code is as follows:
...
var pluginsPath = Server.MapPath(@"~/PlugIns/");
if (Directory.Exists(pluginsPath))
AbpBootstrapper.PlugInSources.AddFolder(pluginsPath);
...
When I try to replace an assembly in the Plugins folder, I get "The action can't be completed because the folder or a file in it is open in another program". I then have to stop the IIS process, replace the file and start the IIS process again. Am I missing something here?
1 Answer(s)
-
0
Hi,
Yes, ABP loads these dlls on the startup and they are locked by the nature of .NET. They are locked until the application shuts down. This behaviour is almost similar in most of the systems (for example, you should re-start VS to update an extension).
I'm widely experienced on plugin architectures and loading dlls dynamically (see my article, for example: <a class="postlink" href="http://www.codeproject.com/Articles/182970/A-Simple-Plug-In-Library-For-NET">http://www.codeproject.com/Articles/182 ... ry-For-NET</a>). From this article:
Another concept that is considered while developing plug-in based applications is Application Domains. Application domains provide an isolation boundary for security, reliability, versioning and for unloading assemblies [3]. A .NET process has single application domain by default. You can create other application domains in runtime.
An assembly cannot be unloaded until the application domain (that hosts it) unloaded. So, if you loaded a plug-in assembly in your default application domain, it cannot be unloaded (thus, assembly file cannot be changed in file system) until your application is closed. If you create a separated application domain and load plug-ins into this domain, then you can safely unload/reload/change the assembly without restarting your main application. But, unfortunately, you cannot directly use objects in other application domains and must use .NET remoting, marshalling and serializing techniques. If you don't really need to unload/update your plugins on runtime, you don't have to use application domains (In most scenarios, it is not needed).
ABP's plugin architecture does not use separated application domains per plugin. I we would use it, it could be quite complex to build and use plugins because app domains require .net remoting ans serialization to communicate to plugins.
In brief, this is by design.
