Digital Dave

Musings on projects, business and life.

Icon

Plug-In Based Architecture for Application Tool Development

So for the past week or so, I’ve been really crunching down on two different plug-in architecture with C#: Reflection and System.AddIn.

Why?

Well, I want to create a much more robust 2D RPG editor than I’ve done in the past.  I want to give people the foundation to build off of while allowing me to learn how to make a dynamic tool that can continue to grow beyond what I do to it. And Jeff motivated me to do it.

I decided not to use Reflection because I really didn’t want to sit here and spend time creating all kinds of security links between my application and the plug-in.  While System.AddIn is incredibly tedious, I feel that it will be worth it in the long term.

So to get my hands dirty with the AddIn framework, I developed a plug-in based calculator prototype.

Prototype Plug-in Editor

There are 3 different development pieces that construct the ‘pipeline’ between the application and the plug-in. The project structure is pretty strict. You can see that, here.

The Contract 

  • Contract – Isolates the Plug-in for better sandboxing and robustness of the host application. Think of this as the formality that the HOST and the PLUG-IN must adhere to.

The Host:

  • View – Defines how the HOST application sees the ADD-IN
  • Adapter – Converts the CONTRACT to the HOST view
  • Application – Your application

The Plug-In

  • View – Defines the base class for the ADD-IN.  This is what you distribute to people, to build their plug-in from.
  • Adapter – Converts the VIEW to the CONTRACT
  • Implementation – Your plug-in

As far as plug-in development goes.  The only concern is with the AddIn view, which will be provided.  In it, we have our abstract class.

using System.AddIn.Pipeline;

namespace AddIn.View
{
[AddInBase]
public abstract class AddInView
{
public abstract int ComputeNums(int x, int y);
public abstract string GetSign();
}
}

Which can be used to actually define our method declarations.

using System.AddIn;
using AddIn.View;

namespace Addin.Addition
{
[AddIn("Addition Plug-In",
Version = "1.0",
Description = "Add 2 Numbers",
Publisher = "David McGraw")]
public class Addition : AddInView
{
public override int ComputeNums(int x, int y)
{
return (x + y);
}

public override string GetSign()
{
return “+”;
}
}
}

The application is build to search the plug-in directory for *.dll files, and will load them if they match the contract. As a plug-in developer, this is little of to no concern as long as you followed the view.

Play with the prototype here, if you want. I hold no promises that it won’t blow up your computer.  Feel free to implement divide, I provided the source for plug-in development.

Category: Coding

Tagged: , ,

  • http://www.jeffongames.com Jeff

    Wow, I had no idea the plugin architecture was so tedious! Hopefully it’s not posing too much of a problem. It looks, though, that once you have it up and running the development model is pretty straightforward?

    Or am I mistaken?

  • http://www.jeffongames.com Jeff

    Wow, I had no idea the plugin architecture was so tedious! Hopefully it’s not posing too much of a problem. It looks, though, that once you have it up and running the development model is pretty straightforward?

    Or am I mistaken?

  • http://www.david-mcgraw.com david.mcgraw

    I think you’re right. Once things get rolling this shouldn’t be a problem. It’s just the initial setup of everything that is tedious. And when you go to add something to the plug-in architecture, you have to put it in 3 different places. Tedious, but once it’s done, it’s good to go.

    Right now I’m on the XNA side of the house figuring that problem out (XNA WinForms). They were going to make the XNA on Windows Forms much easier in XNA 2.0, but it was scrapped. You basically have to recreate the graphics device, and override a bunch of functions that I’m still trying to get my head around.

  • http://www.david-mcgraw.com david.mcgraw

    I think you’re right. Once things get rolling this shouldn’t be a problem. It’s just the initial setup of everything that is tedious. And when you go to add something to the plug-in architecture, you have to put it in 3 different places. Tedious, but once it’s done, it’s good to go.

    Right now I’m on the XNA side of the house figuring that problem out (XNA WinForms). They were going to make the XNA on Windows Forms much easier in XNA 2.0, but it was scrapped. You basically have to recreate the graphics device, and override a bunch of functions that I’m still trying to get my head around.

David McGraw

Founder of iGotIt Games. Trader. Runner. Warrior. Motivator.