Creating extensible applications with dotnet

[Jim Horvath]

I know how to create exe applications in dotnet that use functions
supplied by pre-existing dlls. How do you turn that around?

I want to create an exe program that will be the pre-existing piece.
It's functionality can then be extended (using new dlls) without
re-compiling the exe.

My proposed program is a test sequencer for an industrial control
application. I want the exe to handle common housekeeping functions
(stepping through tests, saving/recalling data, etc.). I want to
implement the actual tests in such a way that they can be
added/removed/changed at a later time without touching the code of the
main exe application.

I guess my question comes down to: What are the mechanics within an EXE
program to call functions in DLLs that don't exist yet?

How do you architect such a program in dotnet? Can anyone direct me with
some helpful links?

Thanks,
Jim Horvath

[Tom Shelton]

On Dec 21, 7:36 am, Jim Horvath <not_here@no_spam.orgwrote:

I know how to create exe applications in dotnet that use functions
supplied by pre-existing dlls. How do you turn that around?

I want to create an exe program that will be the pre-existing piece.
It's functionality can then be extended (using new dlls) without
re-compiling the exe.

My proposed program is a test sequencer for an industrial control
application. I want the exe to handle common housekeeping functions
(stepping through tests, saving/recalling data, etc.). I want to
implement the actual tests in such a way that they can be
added/removed/changed at a later time without touching the code of the
main exe application.

I guess my question comes down to: What are the mechanics within an EXE
program to call functions in DLLs that don't exist yet?

How do you architect such a program in dotnet? Can anyone direct me with
some helpful links?

Thanks,
Jim Horvath

Jim,

What it sounds like your looking for is a plug-in architecture. There
is a lot of information on this on the web, and it's been discussed in
these groups. So, you might want to do some searches for plug-in's
for .NET. In fact, in .NET 3.5, there is a whole architecture built
into the framework for this very thing.

In previous versions, the way this is normally accomplished is to
define an interface for you plug-ins in a class library, that will be
referenced by the app and the plug-in. Essentially this interface/
base class forms the contract for communication between your
application and your the plug-in library. Then the main application,
will usually look in a sub-directory and load any dll's it finds there
(Assembly.Load) and then use reflection to find all classes that
implement the interface, and create instances of those objects.

Where things become hairy is if you want to be able to unload the
assemblies dynamically or if you want to protect your app from
crashing if a plug-in does something stupid... In that case, you need
to load the plug-in assemblies into their own AppDomain. Sounds easy
on the surface, but deceptively so. the reason is that it's all to
easy to directly reference a type in the assembly, which will then
cause it to be loaded into your main AppDomain. To get around this,
you need to build a class loader (in a separate library), and then use
it as a proxy to all of your other assemblies.

Anyway, none of this gives specifics I know, but it should give you
enough information to find many of the good articles on the subject
out there on the web. And, if you need some sample code, I probably
have some here in C#. I was working on a prototype for a rules engine
that dynamically loaded rules - though it was scrapped when .NET 3.0
came out, since the rules engine built into Windows Workflows fit our
needs. Anyway, I can probably crop out the relevant bits for you :)

--
Tom Shelton

[Chris Mullins [MVP - C#]]

"Tom Shelton" <to*********@comcast.netwrote

>I want to create an exe program that will be the pre-existing piece.
It's functionality can then be extended (using new dlls) without
re-compiling the exe.

System.AddIn, found in the new .Net 3.5 stuff, is exactly what you're
looking for.

A recent MSDN article on the topic is here:
http://msdn.microsoft.com/msdnmag/is.../CLRInsideOut/

The Add-In team's blog can be found here:
http://blogs.msdn.com/clraddins/

--
Chris Mullins

[Jim Horvath]

Tom and Chris,

Thank you for your guidance. I can see that this is not quite as simple
as I had hoped, but you gave me exactly what I needed: some reference
material and some keywords to search for.

Thanks again,
Jim Horvath

Tom Shelton wrote:

On Dec 21, 7:36 am, Jim Horvath <not_here@no_spam.orgwrote:

>I know how to create exe applications in dotnet that use functions
supplied by pre-existing dlls. How do you turn that around?

I want to create an exe program that will be the pre-existing piece.
It's functionality can then be extended (using new dlls) without
re-compiling the exe.

My proposed program is a test sequencer for an industrial control
application. I want the exe to handle common housekeeping functions
(stepping through tests, saving/recalling data, etc.). I want to
implement the actual tests in such a way that they can be
added/removed/changed at a later time without touching the code of the
main exe application.

I guess my question comes down to: What are the mechanics within an EXE
program to call functions in DLLs that don't exist yet?

How do you architect such a program in dotnet? Can anyone direct me with
some helpful links?

Thanks,
Jim Horvath

Jim,

What it sounds like your looking for is a plug-in architecture. There
is a lot of information on this on the web, and it's been discussed in
these groups. So, you might want to do some searches for plug-in's
for .NET. In fact, in .NET 3.5, there is a whole architecture built
into the framework for this very thing.

In previous versions, the way this is normally accomplished is to
define an interface for you plug-ins in a class library, that will be
referenced by the app and the plug-in. Essentially this interface/
base class forms the contract for communication between your
application and your the plug-in library. Then the main application,
will usually look in a sub-directory and load any dll's it finds there
(Assembly.Load) and then use reflection to find all classes that
implement the interface, and create instances of those objects.

Where things become hairy is if you want to be able to unload the
assemblies dynamically or if you want to protect your app from
crashing if a plug-in does something stupid... In that case, you need
to load the plug-in assemblies into their own AppDomain. Sounds easy
on the surface, but deceptively so. the reason is that it's all to
easy to directly reference a type in the assembly, which will then
cause it to be loaded into your main AppDomain. To get around this,
you need to build a class loader (in a separate library), and then use
it as a proxy to all of your other assemblies.

Anyway, none of this gives specifics I know, but it should give you
enough information to find many of the good articles on the subject
out there on the web. And, if you need some sample code, I probably
have some here in C#. I was working on a prototype for a rules engine
that dynamically loaded rules - though it was scrapped when .NET 3.0
came out, since the rules engine built into Windows Workflows fit our
needs. Anyway, I can probably crop out the relevant bits for you :)

--
Tom Shelton