I'm getting to a point in my project where functionality can be based on the needs of individual users.

As part of my application I would like to have the ability to add and remove functionality based on the user. I figure plug-ins might be the way to go for something like this.

Here is my current dilemma:
I have a rather sweet deal going with my employer. I get paid to write a software solution and the final source code and solution remains my property.

I am designing my application from a very generic point of view, as in, I want to be able to market the final product to other companies and not have features that only apply to my current employer.

I want to put the features that my employer wants that are specific to them into a .dll (for example) and when that file is added to a "plugin" folder in the application directory it will add those features. If the .dll is not there, the features aren't there and the application will still function normally.

Before I spend more hours researching the different ways of doing this (I've already spent a few), I was wondering if I could get a simple discussion going on if this is a good idea, bad idea, problems, pros, cons, etc...

I'd really like to hear from people who have done something like this before.

The first thing you need to do is clearly define the interface for you plug-in.

What functions will the plug-in have access to?
What functions must the plug-in provide?

This is then best 'set in stone' in an interface dll allowing your main app and the plug-in projects to reference it when required.

Otherwise you could end up having to re-build all the plug-ins when ever you make changes to the main app.

I would actually like the plug-in to house all of it's own functions, but only be "set into motion" by the main application.

The data that the plug-in would use is located on an SQL server. The data needed from the main application (such as connection strings, the current user and the current user's permission level etc..) would be sent to the plug-in functions when called as variables.

The plugin would alter the data, update the data or whatever all based on the information sent to it by the host application.

Am I thinking about this to simply? I tend to do that sometimes.

I suppose that the menu bar on the host application would have to be modified to show plugin "commands" that the user can select from. But that can be set by the host right? The host could request information from the plug-in and display it, the plugin shouldn't need to alter the menu on it's own.

The plugin that I am thinking of at the moment would be built using the QuickBooks SDK. Basically it would collect data from a table in a SQL database, parse it correctly and send it to QuickBooks to generate invoices automatically.

I do see your point about changes requiring plugins to change...that's a point I never thought of.

You asked about creating a plug-in framework. The dll containing the function interfaces define your framework. Without this the plug-in and application have no knowledge about how to talk to each other.

Also, some information about the plug-in is probably best written to the registry by the plug-in installer. Otherwise the app does not know what to load. (Remember your plug-in might require more than one dll for its own purposes.)

Having identified the plug-in dll the app must then dynamically load the file for use. You cannot directly reference the plug-in otherwise your app will always need it to run.

I think for the sake of my sanity and to not rush into anything. I am going to complete my application to a generic level.

At that time I'll just make a copy of the directory and work on a second copy and add the functionality that my employer needs.

I think plug-ins are a little too advanced for my taste at the moment. I'm sure it's much simpler than I am making it out to be, but I'd rather stick to what I know for now.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.