Constructting and executing code at run time

  • Thread starter Thread starter nano_electronix
  • Start date Start date
N

nano_electronix

Hello all

I am currently architecting an application that will
centralize launching of a set of internal applications
from a single point of entry.

One of the aspect that needs to be considered is that we
want to be able to add additional internal applications to
this central access point application without change the
code for this central access point application. This is
some what like adding plugins to internet explorer (how is
this done btw?).

I am in the early stage of designing this. But one of the
early solutions to this is to have a configurable XML file
that is read by this app each time it starts. This XML
file will contain information about all DLLs that are
plugged into the application. So adding a plugin would
simply mean adding entries to this XML file. To achieve
this, the internal applications plugged into this central
app will be instantiated by constructing calling codes
from the XML data.

So my questions are
1. Is there a way to execute code that are constructed
programmatically at run time?

2. Any suggestions of how i may build the application
described above? Tell me if you need more information in
order to give comments on this.

Cheers
James
 
Hi,
1. Is there a way to execute code that are constructed
programmatically at run time?
Click to expand...

Assembly.CreateInstanceAndUnwrap(...)
Assembly.CreateInstanceFromAndUnwrap(...)

and then casting the returned reference to an a priori known interface or
class.
2. Any suggestions of how i may build the application
described above? Tell me if you need more information in
order to give comments on this.
Click to expand...

I think any of the plug-in applications should expose a well-known interface
used by the host program to talk to the plug-ins. It is actually up to you
what to include into that interface - Initialize() and Terminate() could be
obvious choices, for example.
 
Hi

Most plug-in architecture work because all the plug-ins implement a
pre-defined interface. Because all plug-ins follow this interface the
hosting application can be sure that specific methods can be called on the
plug-ins. These method might define: Initializing, Run, Pause, Stop,
Dispose, setting and retrieving data for/to the plug-in.

If you are responsible for creating both the plug-ins and the hosting
application you would define an "Interface" that all plug-ins have to
implement and there's one public class in the DLLs that contain the
plug-ins.

In the XML you would define the DLLs name and may be some default data that
should be sent to the plug-in through the setter-methods as defined in the
interface at start-up of the plug-in.

If you have to include existing applications in this system and still have a
simple central application it might be easier to write wrappers for these
external applications. These wrappers would hide the specifics of the
external program, but the central program still gets a standardize interface
that it can depend on.

Andreas
 
* "nano_electronix said:
I am currently architecting an application that will
centralize launching of a set of internal applications
from a single point of entry.

One of the aspect that needs to be considered is that we
want to be able to add additional internal applications to
this central access point application without change the
code for this central access point application. This is
some what like adding plugins to internet explorer (how is
this done btw?).
Click to expand...

<http://www.codeproject.com/csharp/livecodedotnet.asp>
 
In addition to Andrias' point about creating a standard plug-in interface
for your components, you may want to consider using the App.config file.
This is an XML file residing in the same directory as the <yourapp>.exe and
is named <yourapp>.exe.config. There is excellent design time support for
this in Visual Studio .NET. You just need a file in your project called
App.Config. When your project is built, it is copied into the build
directory and renamed to the appropriate name. The easiest way to create
one of these is to put a form in your project and create a DynamicProperty
for it. That creates the app.config file and enters the dynamic data in
there. We store records in that file defining which components get loaded
and the order in which they are loaded. In addition to making the
application content more configurable, this gives developers the ability to
work on their component without having to load everything else.

Take a look at the System.Configuration namespace, and in particular the
ConfigurationSettings.GetConfig() method. It works beautifully for us.

Tom Clement
Apptero, Inc.
 
Back
Top