CODEWITHSUNDEEP
c#asp.netasp.net-mvcplugins
yeomandev
yeomandev

Reputation: 11796

Is it ok to store plugin DLLs in a /Plugin folder instead of /Bin?

I have a pretty straightforward question.

Is it ok to store plugin DLLs in a /Plugin folder instead of /Bin? I'm experimenting with plugin design in the context of ASP.NET WebForms (and MVC) and I am wondering if there could be an issue with storing plugin DLLs in a /Plugin folder instead of the /Bin folder.

Thanks for any help.

Update

I'm coming at this from the perspective of this article: http://www.c-sharpcorner.com/UploadFile/40e97e/7192/.

I am going to load plugins using Reflection.

Sample Code:

public class PluginLoader
{
    public static IList<IPlugin> Load(string folder)
    {
        IList<IPlugin> plugins = new List<IPlugin>();

        // Get files in folder
        string[] files = Directory.GetFiles(folder, "*.plug.dll");
        foreach(string file in files)
        {
            Assembly assembly = Assembly.LoadFile(file);
            var types = assembly.GetExportedTypes();
            foreach (Type type in types)
            {
                if (type.GetInterfaces().Contains(typeof(IPlugin)))
                {
                    object instance = Activator.CreateInstance(type);
                    plugins.Add(instance as IPlugin);
                }
            }
        }
        return plugins;
    }
}

Upvotes: 1

Views: 453

Answers (1)

Matthew Abbott
Matthew Abbott

Reputation: 61589

The only thing you generally need to watch for is when you are trying to use types from those plugin assemblies in your views (or pages), they'll likely fail to resolve at runtime. This is due to the nature of the dynamic compilation model ASP.NET uses for non-precompiled applications.

Essentially, your views (and pages) will be dynamically compiled by the ASP.NET runtime, not a compile time, so when the assembly binder attempts to resolve those types, because they are not in the default bin location, it won't find them. A simple easy fix would be to use AppDomain.CurrentDomain.AppendPrivatePath, passing in the path of your plugins folder, e.g. Server.MapPath("~/plugins")

The method itself is marked as obselete and might be removed in future versions of the framework, (as generally you would configure the probing path through AppDomainSetup), but it does work.

If at all you are unhappy about this approach, you could always deploy your plugin assemblies within your bin directory instead.

Upvotes: 4

Related Questions