advice needed for modularized development

[Steve]

Hi,

I am sitting down to design our next set of internal apps. I would like to
approach this in a way that would allow me to break logical parts of the
application that handle specific tasks into modules. For example, assuming
we have 4 main tasks to accomplish:
- Printing
- Editing
- Viewing
- Inventory Management

Each of those tasks would have an associated UI(User Control) with all
relevant UI controls, for example printing would have printing options,
printer names, etc.

My motivation for wanting to make these separate is that different
combinations of these modules need to be rolled together into applications.
For example, at my desk, I would want an application that would support all
4 tasks, while in the shop, they only need Printing, Inventory and Viewing.
Someone else might only need Viewing.

Rather than develop all modules under the same project and build separate
binaries with various modules enabled or disabled, I would rather have a
project for each module, then a project for each combination of modules and
include the modules that I need.

I suppose this is actually a sort of plug-in architecture that I'm looking
for. I haven't ever done anything like this and am interested in how most
of you would approach this? Anyone know of any good articles or books on
the subject?

Thanks for reading,
Steve

[C.C. \(aka Me\)]

Re: advice needed for modularized development

Well the first thing you should look into is the notion of Add-Ons in
general (maybe do a web search for it). This will help you understand what
AddOn's are and different ways of implementing them.

Next, take a look at Interfaces because that is a core part of Add-On
implmentations. You will need a common set of methods (aka an Interface)
that can be used to access the Add-On.

Here is an example of an Interface and a way that you could use it in your
application.

+++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
interface IAddOn
{
String Name(); //Returns a human readable name of this AddOn like
"Printing"
String Description(); //Returns a brief description like "Allows
Printing of internal documents"
bool Startup(); //Performs any init/startup code that is needed and
returns true/false as a success result.
bool Shutdown(); //Performs any shutdown code that is needed and returns
true/false as a result.
void Show(); //Informs the AddOn that it should display itself.
void Hide(); //Informs the AddOn that it should hide itself.
void Execute(String cmd); //Tells the AddOn to execute the given
command. cmd could be an xml string or anything?
}

Now if you are going to have a standard application that these AddOns will
be part of then maybe you could use a menu system to show the available
"options" that are intalled. The menu system could be an actual menu or
maybe just different buttons on a form that are clicked on.

The application could look at the files in a specific directory (maybe
\AddOns) and use Reflection to load and create an instance of each of the
files contained in it. Each file (assembly) would have a class that is
derived from the IAddOn interface so you could determine what class you
should instantiate. Or maybe you have a config file that contains a list of
assembly files and class names that should be loaded.

After loading each of the AddOns the application could call Startup() on
each one so that they could do any initializing they needed.

Using the Name() member of the IAddOn interface you could dynamically add a
menu item that the operator could select in order to activate the AddOn.

When the operator selected an AddOn from the menu you could call the Show()
method or maybe the Execute() method to have the AddOn peform it's task.

When the application is closed down you would want to call Shutdown() so
that the AddOn's could do any uninit type of stuff they needed like closing
files, etc.
+++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++

The nice thing about this type of setup is that you could have different
types of AddOn's. Maybe you have an interface used for user selectable
options, and another interface for background utilities.

Or, maybe you want to implement some sort of secutity mechanism. The
Interface could have a method that takes a username and returns true if it
is allowed to use the AddOn. This way you could have one application with
all the AddOns available but the user logs and only sees what they are
allowed to use.

Kind of a brief overview of this type of development but maybe it can give
you some insite?


"Steve" <sss@sss.com> wrote in message
news:ev%23xFTQI GHA.312@TK2MSFT NGP09.phx.gbl.. .[color=blue]
> Hi,
>
> I am sitting down to design our next set of internal apps. I would like
> to approach this in a way that would allow me to break logical parts of
> the application that handle specific tasks into modules. For example,
> assuming we have 4 main tasks to accomplish:
> - Printing
> - Editing
> - Viewing
> - Inventory Management
>
> Each of those tasks would have an associated UI(User Control) with all
> relevant UI controls, for example printing would have printing options,
> printer names, etc.
>
> My motivation for wanting to make these separate is that different
> combinations of these modules need to be rolled together into
> applications. For example, at my desk, I would want an application that
> would support all 4 tasks, while in the shop, they only need Printing,
> Inventory and Viewing. Someone else might only need Viewing.
>
> Rather than develop all modules under the same project and build separate
> binaries with various modules enabled or disabled, I would rather have a
> project for each module, then a project for each combination of modules
> and include the modules that I need.
>
> I suppose this is actually a sort of plug-in architecture that I'm looking
> for. I haven't ever done anything like this and am interested in how most
> of you would approach this? Anyone know of any good articles or books on
> the subject?
>
> Thanks for reading,
> Steve
>[/color]

[Steve]

Re: advice needed for modularized development

Very nice, that is a great overview!
I too had thought of the single "host" application that would host the add
ons and make them availablew based on the current users role.

I printed your message, it's a nice overview, I'll read it a couple times,
thanks for the post.

Have a good one,
Steve


"C.C. (aka Me)" <me@home.com> wrote in message
news:tsednYPj-PVn_EvenZ2dnUVZ _v6dnZ2d@comcas t.com...[color=blue]
> Well the first thing you should look into is the notion of Add-Ons in
> general (maybe do a web search for it). This will help you understand what
> AddOn's are and different ways of implementing them.
>
> Next, take a look at Interfaces because that is a core part of Add-On
> implmentations. You will need a common set of methods (aka an Interface)
> that can be used to access the Add-On.
>
> Here is an example of an Interface and a way that you could use it in your
> application.
>
> +++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
> interface IAddOn
> {
> String Name(); //Returns a human readable name of this AddOn like
> "Printing"
> String Description(); //Returns a brief description like "Allows
> Printing of internal documents"
> bool Startup(); //Performs any init/startup code that is needed and
> returns true/false as a success result.
> bool Shutdown(); //Performs any shutdown code that is needed and
> returns true/false as a result.
> void Show(); //Informs the AddOn that it should display itself.
> void Hide(); //Informs the AddOn that it should hide itself.
> void Execute(String cmd); //Tells the AddOn to execute the given
> command. cmd could be an xml string or anything?
> }
>
> Now if you are going to have a standard application that these AddOns will
> be part of then maybe you could use a menu system to show the available
> "options" that are intalled. The menu system could be an actual menu or
> maybe just different buttons on a form that are clicked on.
>
> The application could look at the files in a specific directory (maybe
> \AddOns) and use Reflection to load and create an instance of each of the
> files contained in it. Each file (assembly) would have a class that is
> derived from the IAddOn interface so you could determine what class you
> should instantiate. Or maybe you have a config file that contains a list
> of assembly files and class names that should be loaded.
>
> After loading each of the AddOns the application could call Startup() on
> each one so that they could do any initializing they needed.
>
> Using the Name() member of the IAddOn interface you could dynamically add
> a menu item that the operator could select in order to activate the AddOn.
>
> When the operator selected an AddOn from the menu you could call the
> Show() method or maybe the Execute() method to have the AddOn peform it's
> task.
>
> When the application is closed down you would want to call Shutdown() so
> that the AddOn's could do any uninit type of stuff they needed like
> closing files, etc.
> +++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
>
> The nice thing about this type of setup is that you could have different
> types of AddOn's. Maybe you have an interface used for user selectable
> options, and another interface for background utilities.
>
> Or, maybe you want to implement some sort of secutity mechanism. The
> Interface could have a method that takes a username and returns true if it
> is allowed to use the AddOn. This way you could have one application with
> all the AddOns available but the user logs and only sees what they are
> allowed to use.
>
> Kind of a brief overview of this type of development but maybe it can give
> you some insite?
>
>
> "Steve" <sss@sss.com> wrote in message
> news:ev%23xFTQI GHA.312@TK2MSFT NGP09.phx.gbl.. .[color=green]
>> Hi,
>>
>> I am sitting down to design our next set of internal apps. I would like
>> to approach this in a way that would allow me to break logical parts of
>> the application that handle specific tasks into modules. For example,
>> assuming we have 4 main tasks to accomplish:
>> - Printing
>> - Editing
>> - Viewing
>> - Inventory Management
>>
>> Each of those tasks would have an associated UI(User Control) with all
>> relevant UI controls, for example printing would have printing options,
>> printer names, etc.
>>
>> My motivation for wanting to make these separate is that different
>> combinations of these modules need to be rolled together into
>> applications. For example, at my desk, I would want an application that
>> would support all 4 tasks, while in the shop, they only need Printing,
>> Inventory and Viewing. Someone else might only need Viewing.
>>
>> Rather than develop all modules under the same project and build separate
>> binaries with various modules enabled or disabled, I would rather have a
>> project for each module, then a project for each combination of modules
>> and include the modules that I need.
>>
>> I suppose this is actually a sort of plug-in architecture that I'm
>> looking for. I haven't ever done anything like this and am interested in
>> how most of you would approach this? Anyone know of any good articles or
>> books on the subject?
>>
>> Thanks for reading,
>> Steve
>>[/color]
>
>[/color]

[C.C. \(aka Me\)]

Re: advice needed for modularized development

One place to look at for a "big" example of this type of thing is the
Eclipse project.

http://www.eclipse.org/

It is an "everything but nothing at all" type of framework. It provides the
"general application" and you provide the "components that do something". I
have not used it but have dealt with others that have and it seems to work
for them.

Might be to big of a thing for your project but at least it can give you
some ideas maybe?


"Steve" <sss@sss.com> wrote in message
news:%23qAY$5QI GHA.376@TK2MSFT NGP12.phx.gbl.. .[color=blue]
> Very nice, that is a great overview!
> I too had thought of the single "host" application that would host the add
> ons and make them availablew based on the current users role.
>
> I printed your message, it's a nice overview, I'll read it a couple times,
> thanks for the post.
>
> Have a good one,
> Steve
>
>
> "C.C. (aka Me)" <me@home.com> wrote in message
> news:tsednYPj-PVn_EvenZ2dnUVZ _v6dnZ2d@comcas t.com...[color=green]
>> Well the first thing you should look into is the notion of Add-Ons in
>> general (maybe do a web search for it). This will help you understand
>> what AddOn's are and different ways of implementing them.
>>
>> Next, take a look at Interfaces because that is a core part of Add-On
>> implmentations. You will need a common set of methods (aka an Interface)
>> that can be used to access the Add-On.
>>
>> Here is an example of an Interface and a way that you could use it in
>> your application.
>>
>> +++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
>> interface IAddOn
>> {
>> String Name(); //Returns a human readable name of this AddOn like
>> "Printing"
>> String Description(); //Returns a brief description like "Allows
>> Printing of internal documents"
>> bool Startup(); //Performs any init/startup code that is needed and
>> returns true/false as a success result.
>> bool Shutdown(); //Performs any shutdown code that is needed and
>> returns true/false as a result.
>> void Show(); //Informs the AddOn that it should display itself.
>> void Hide(); //Informs the AddOn that it should hide itself.
>> void Execute(String cmd); //Tells the AddOn to execute the given
>> command. cmd could be an xml string or anything?
>> }
>>
>> Now if you are going to have a standard application that these AddOns
>> will be part of then maybe you could use a menu system to show the
>> available "options" that are intalled. The menu system could be an actual
>> menu or maybe just different buttons on a form that are clicked on.
>>
>> The application could look at the files in a specific directory (maybe
>> \AddOns) and use Reflection to load and create an instance of each of the
>> files contained in it. Each file (assembly) would have a class that is
>> derived from the IAddOn interface so you could determine what class you
>> should instantiate. Or maybe you have a config file that contains a list
>> of assembly files and class names that should be loaded.
>>
>> After loading each of the AddOns the application could call Startup() on
>> each one so that they could do any initializing they needed.
>>
>> Using the Name() member of the IAddOn interface you could dynamically add
>> a menu item that the operator could select in order to activate the
>> AddOn.
>>
>> When the operator selected an AddOn from the menu you could call the
>> Show() method or maybe the Execute() method to have the AddOn peform it's
>> task.
>>
>> When the application is closed down you would want to call Shutdown() so
>> that the AddOn's could do any uninit type of stuff they needed like
>> closing files, etc.
>> +++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
>>
>> The nice thing about this type of setup is that you could have different
>> types of AddOn's. Maybe you have an interface used for user selectable
>> options, and another interface for background utilities.
>>
>> Or, maybe you want to implement some sort of secutity mechanism. The
>> Interface could have a method that takes a username and returns true if
>> it is allowed to use the AddOn. This way you could have one application
>> with all the AddOns available but the user logs and only sees what they
>> are allowed to use.
>>
>> Kind of a brief overview of this type of development but maybe it can
>> give you some insite?
>>
>>
>> "Steve" <sss@sss.com> wrote in message
>> news:ev%23xFTQI GHA.312@TK2MSFT NGP09.phx.gbl.. .[color=darkred]
>>> Hi,
>>>
>>> I am sitting down to design our next set of internal apps. I would like
>>> to approach this in a way that would allow me to break logical parts of
>>> the application that handle specific tasks into modules. For example,
>>> assuming we have 4 main tasks to accomplish:
>>> - Printing
>>> - Editing
>>> - Viewing
>>> - Inventory Management
>>>
>>> Each of those tasks would have an associated UI(User Control) with all
>>> relevant UI controls, for example printing would have printing options,
>>> printer names, etc.
>>>
>>> My motivation for wanting to make these separate is that different
>>> combinations of these modules need to be rolled together into
>>> applications. For example, at my desk, I would want an application that
>>> would support all 4 tasks, while in the shop, they only need Printing,
>>> Inventory and Viewing. Someone else might only need Viewing.
>>>
>>> Rather than develop all modules under the same project and build
>>> separate binaries with various modules enabled or disabled, I would
>>> rather have a project for each module, then a project for each
>>> combination of modules and include the modules that I need.
>>>
>>> I suppose this is actually a sort of plug-in architecture that I'm
>>> looking for. I haven't ever done anything like this and am interested
>>> in how most of you would approach this? Anyone know of any good
>>> articles or books on the subject?
>>>
>>> Thanks for reading,
>>> Steve
>>>[/color]
>>
>>[/color]
>
>[/color]

[Steve]

Re: advice needed for modularized development

Yeah, Eclipse is overkill for what I want.

I wonder how I can debug my Add-Ons outside of the host? To launch them in
the debugger, they would need to be WinForms application, but I can't
imagine it would be proper for a "Host" winforms app to host another
winforms app. Does that make sense?

I google for AddOn led me to this article:
http://msdn.microsoft.com/msdnmag/is...10/plug%2Dins/

I haven't read it yet, just browsed but it sounds like a good place to start
for me.


"C.C. (aka Me)" <me@home.com> wrote in messag e
news:cdCdncJore d_90venZ2dnUVZ_ t-dnZ2d@comcast.c om...[color=blue]
> One place to look at for a "big" example of this type of thing is the
> Eclipse project.
>
> http://www.eclipse.org/
>
> It is an "everything but nothing at all" type of framework. It provides
> the "general application" and you provide the "components that do
> something". I have not used it but have dealt with others that have and it
> seems to work for them.
>
> Might be to big of a thing for your project but at least it can give you
> some ideas maybe?
>
>
> "Steve" <sss@sss.com> wrote in message
> news:%23qAY$5QI GHA.376@TK2MSFT NGP12.phx.gbl.. .[color=green]
>> Very nice, that is a great overview!
>> I too had thought of the single "host" application that would host the
>> add ons and make them availablew based on the current users role.
>>
>> I printed your message, it's a nice overview, I'll read it a couple
>> times, thanks for the post.
>>
>> Have a good one,
>> Steve
>>
>>
>> "C.C. (aka Me)" <me@home.com> wrote in message
>> news:tsednYPj-PVn_EvenZ2dnUVZ _v6dnZ2d@comcas t.com...[color=darkred]
>>> Well the first thing you should look into is the notion of Add-Ons in
>>> general (maybe do a web search for it). This will help you understand
>>> what AddOn's are and different ways of implementing them.
>>>
>>> Next, take a look at Interfaces because that is a core part of Add-On
>>> implmentations. You will need a common set of methods (aka an Interface)
>>> that can be used to access the Add-On.
>>>
>>> Here is an example of an Interface and a way that you could use it in
>>> your application.
>>>
>>> +++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
>>> interface IAddOn
>>> {
>>> String Name(); //Returns a human readable name of this AddOn like
>>> "Printing"
>>> String Description(); //Returns a brief description like "Allows
>>> Printing of internal documents"
>>> bool Startup(); //Performs any init/startup code that is needed and
>>> returns true/false as a success result.
>>> bool Shutdown(); //Performs any shutdown code that is needed and
>>> returns true/false as a result.
>>> void Show(); //Informs the AddOn that it should display itself.
>>> void Hide(); //Informs the AddOn that it should hide itself.
>>> void Execute(String cmd); //Tells the AddOn to execute the given
>>> command. cmd could be an xml string or anything?
>>> }
>>>
>>> Now if you are going to have a standard application that these AddOns
>>> will be part of then maybe you could use a menu system to show the
>>> available "options" that are intalled. The menu system could be an
>>> actual menu or maybe just different buttons on a form that are clicked
>>> on.
>>>
>>> The application could look at the files in a specific directory (maybe
>>> \AddOns) and use Reflection to load and create an instance of each of
>>> the files contained in it. Each file (assembly) would have a class that
>>> is derived from the IAddOn interface so you could determine what class
>>> you should instantiate. Or maybe you have a config file that contains a
>>> list of assembly files and class names that should be loaded.
>>>
>>> After loading each of the AddOns the application could call Startup() on
>>> each one so that they could do any initializing they needed.
>>>
>>> Using the Name() member of the IAddOn interface you could dynamically
>>> add a menu item that the operator could select in order to activate the
>>> AddOn.
>>>
>>> When the operator selected an AddOn from the menu you could call the
>>> Show() method or maybe the Execute() method to have the AddOn peform
>>> it's task.
>>>
>>> When the application is closed down you would want to call Shutdown() so
>>> that the AddOn's could do any uninit type of stuff they needed like
>>> closing files, etc.
>>> +++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
>>>
>>> The nice thing about this type of setup is that you could have different
>>> types of AddOn's. Maybe you have an interface used for user selectable
>>> options, and another interface for background utilities.
>>>
>>> Or, maybe you want to implement some sort of secutity mechanism. The
>>> Interface could have a method that takes a username and returns true if
>>> it is allowed to use the AddOn. This way you could have one application
>>> with all the AddOns available but the user logs and only sees what they
>>> are allowed to use.
>>>
>>> Kind of a brief overview of this type of development but maybe it can
>>> give you some insite?
>>>
>>>
>>> "Steve" <sss@sss.com> wrote in message
>>> news:ev%23xFTQI GHA.312@TK2MSFT NGP09.phx.gbl.. .
>>>> Hi,
>>>>
>>>> I am sitting down to design our next set of internal apps. I would
>>>> like to approach this in a way that would allow me to break logical
>>>> parts of the application that handle specific tasks into modules. For
>>>> example, assuming we have 4 main tasks to accomplish:
>>>> - Printing
>>>> - Editing
>>>> - Viewing
>>>> - Inventory Management
>>>>
>>>> Each of those tasks would have an associated UI(User Control) with all
>>>> relevant UI controls, for example printing would have printing options,
>>>> printer names, etc.
>>>>
>>>> My motivation for wanting to make these separate is that different
>>>> combinations of these modules need to be rolled together into
>>>> applications. For example, at my desk, I would want an application that
>>>> would support all 4 tasks, while in the shop, they only need Printing,
>>>> Inventory and Viewing. Someone else might only need Viewing.
>>>>
>>>> Rather than develop all modules under the same project and build
>>>> separate binaries with various modules enabled or disabled, I would
>>>> rather have a project for each module, then a project for each
>>>> combination of modules and include the modules that I need.
>>>>
>>>> I suppose this is actually a sort of plug-in architecture that I'm
>>>> looking for. I haven't ever done anything like this and am interested
>>>> in how most of you would approach this? Anyone know of any good
>>>> articles or books on the subject?
>>>>
>>>> Thanks for reading,
>>>> Steve
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[C.C. \(aka Me\)]

Re: advice needed for modularized development

You should still be able to debug them.

Say you have the following projects:

MainApp (WinForm application project)
Comp1 (Class Library)
Comp2 (Class Library)

Now you can debug the Control Libraries if you add them to your MainApp
project. You can dynamically load them still from a config file or whatever,
but VS should see that you have the source code and allow you to debug them.

So you could debug them from within the normal application that your users
interact with.

--
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

"Steve" <sss@sss.com> wrote in message
news:epMGICRIGH A.3448@TK2MSFTN GP10.phx.gbl...[color=blue]
> Yeah, Eclipse is overkill for what I want.
>
> I wonder how I can debug my Add-Ons outside of the host? To launch them
> in the debugger, they would need to be WinForms application, but I can't
> imagine it would be proper for a "Host" winforms app to host another
> winforms app. Does that make sense?
>
> I google for AddOn led me to this article:
> http://msdn.microsoft.com/msdnmag/is...10/plug%2Dins/
>
> I haven't read it yet, just browsed but it sounds like a good place to
> start for me.
>
>
> "C.C. (aka Me)" <me@home.com> wrote in messag e
> news:cdCdncJore d_90venZ2dnUVZ_ t-dnZ2d@comcast.c om...[color=green]
>> One place to look at for a "big" example of this type of thing is the
>> Eclipse project.
>>
>> http://www.eclipse.org/
>>
>> It is an "everything but nothing at all" type of framework. It provides
>> the "general application" and you provide the "components that do
>> something". I have not used it but have dealt with others that have and
>> it seems to work for them.
>>
>> Might be to big of a thing for your project but at least it can give you
>> some ideas maybe?
>>
>>
>> "Steve" <sss@sss.com> wrote in message
>> news:%23qAY$5QI GHA.376@TK2MSFT NGP12.phx.gbl.. .[color=darkred]
>>> Very nice, that is a great overview!
>>> I too had thought of the single "host" application that would host the
>>> add ons and make them availablew based on the current users role.
>>>
>>> I printed your message, it's a nice overview, I'll read it a couple
>>> times, thanks for the post.
>>>
>>> Have a good one,
>>> Steve
>>>
>>>
>>> "C.C. (aka Me)" <me@home.com> wrote in message
>>> news:tsednYPj-PVn_EvenZ2dnUVZ _v6dnZ2d@comcas t.com...
>>>> Well the first thing you should look into is the notion of Add-Ons in
>>>> general (maybe do a web search for it). This will help you understand
>>>> what AddOn's are and different ways of implementing them.
>>>>
>>>> Next, take a look at Interfaces because that is a core part of Add-On
>>>> implmentations. You will need a common set of methods (aka an
>>>> Interface) that can be used to access the Add-On.
>>>>
>>>> Here is an example of an Interface and a way that you could use it in
>>>> your application.
>>>>
>>>> +++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
>>>> interface IAddOn
>>>> {
>>>> String Name(); //Returns a human readable name of this AddOn like
>>>> "Printing"
>>>> String Description(); //Returns a brief description like "Allows
>>>> Printing of internal documents"
>>>> bool Startup(); //Performs any init/startup code that is needed and
>>>> returns true/false as a success result.
>>>> bool Shutdown(); //Performs any shutdown code that is needed and
>>>> returns true/false as a result.
>>>> void Show(); //Informs the AddOn that it should display itself.
>>>> void Hide(); //Informs the AddOn that it should hide itself.
>>>> void Execute(String cmd); //Tells the AddOn to execute the given
>>>> command. cmd could be an xml string or anything?
>>>> }
>>>>
>>>> Now if you are going to have a standard application that these AddOns
>>>> will be part of then maybe you could use a menu system to show the
>>>> available "options" that are intalled. The menu system could be an
>>>> actual menu or maybe just different buttons on a form that are clicked
>>>> on.
>>>>
>>>> The application could look at the files in a specific directory (maybe
>>>> \AddOns) and use Reflection to load and create an instance of each of
>>>> the files contained in it. Each file (assembly) would have a class that
>>>> is derived from the IAddOn interface so you could determine what class
>>>> you should instantiate. Or maybe you have a config file that contains
>>>> a list of assembly files and class names that should be loaded.
>>>>
>>>> After loading each of the AddOns the application could call Startup()
>>>> on each one so that they could do any initializing they needed.
>>>>
>>>> Using the Name() member of the IAddOn interface you could dynamically
>>>> add a menu item that the operator could select in order to activate the
>>>> AddOn.
>>>>
>>>> When the operator selected an AddOn from the menu you could call the
>>>> Show() method or maybe the Execute() method to have the AddOn peform
>>>> it's task.
>>>>
>>>> When the application is closed down you would want to call Shutdown()
>>>> so that the AddOn's could do any uninit type of stuff they needed like
>>>> closing files, etc.
>>>> +++++++++++++++ +++++++++++++++ +++++++++++++++ +++++++++++++++ ++++++
>>>>
>>>> The nice thing about this type of setup is that you could have
>>>> different types of AddOn's. Maybe you have an interface used for user
>>>> selectable options, and another interface for background utilities.
>>>>
>>>> Or, maybe you want to implement some sort of secutity mechanism. The
>>>> Interface could have a method that takes a username and returns true if
>>>> it is allowed to use the AddOn. This way you could have one application
>>>> with all the AddOns available but the user logs and only sees what they
>>>> are allowed to use.
>>>>
>>>> Kind of a brief overview of this type of development but maybe it can
>>>> give you some insite?
>>>>
>>>>
>>>> "Steve" <sss@sss.com> wrote in message
>>>> news:ev%23xFTQI GHA.312@TK2MSFT NGP09.phx.gbl.. .
>>>>> Hi,
>>>>>
>>>>> I am sitting down to design our next set of internal apps. I would
>>>>> like to approach this in a way that would allow me to break logical
>>>>> parts of the application that handle specific tasks into modules. For
>>>>> example, assuming we have 4 main tasks to accomplish:
>>>>> - Printing
>>>>> - Editing
>>>>> - Viewing
>>>>> - Inventory Management
>>>>>
>>>>> Each of those tasks would have an associated UI(User Control) with all
>>>>> relevant UI controls, for example printing would have printing
>>>>> options, printer names, etc.
>>>>>
>>>>> My motivation for wanting to make these separate is that different
>>>>> combinations of these modules need to be rolled together into
>>>>> applications. For example, at my desk, I would want an application
>>>>> that would support all 4 tasks, while in the shop, they only need
>>>>> Printing, Inventory and Viewing. Someone else might only need Viewing.
>>>>>
>>>>> Rather than develop all modules under the same project and build
>>>>> separate binaries with various modules enabled or disabled, I would
>>>>> rather have a project for each module, then a project for each
>>>>> combination of modules and include the modules that I need.
>>>>>
>>>>> I suppose this is actually a sort of plug-in architecture that I'm
>>>>> looking for. I haven't ever done anything like this and am interested
>>>>> in how most of you would approach this? Anyone know of any good
>>>>> articles or books on the subject?
>>>>>
>>>>> Thanks for reading,
>>>>> Steve
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]