Hi Rich,

Both. I plan to have a "common" folder that contains common assemblies with
types to be shared among all the assemblies. I plan to use binding redirects
so that all plugins/components that refer to these common assemblies are all
forced to use the same (current) version. This requires that all common
assemblies be backwardly compatible.

Plugins may have private assemblies that should be kept private (i.e. they
do not share types contained within them). Some plugins may use the same
assembly, (e.g. both reference foo.dll) but possibly of different versions -
local copies of each will be kept.  Private assemblies will not use binding
redirects to force all references to the same version, so there is no
requirement that they be backwardly compatible.

The private assemblies can possibly be handled using the AssemblyResolve
event and using LoadFrom, but this only works so long as types do not need
to get shared. I prefer to have the fusion layer automatically resolve the
references. One possible issue is that as the system evolves and new plugins
get added but old ones do not get modified, an assembly that used to be
private now needs to be shared - in this case the assembly now really ought
to be loaded using Load, not LoadFrom. There wont be binding redirects of
these private assemblies so strict versioning should prevent type
incompatiblities.

Some plugins will use the default appdomain - in fact, most probably will as
it is the easiest and presents the fewest obstacles. But even if it isn't
the default, loading more then one plugin into the same appdomain after it
has been created, default or otherwise, presents the same set of problems -
once the appdomain is created the private paths searched will need to to be
modified.

There is another use case as well: even if all known plugins are determined
and their requirements fed into an appconfig prior to creating the
appdomain, if we don't have the ability to modify the path after that then
this may prevent us from dynamically adding a new plugin without shutting
down the running appdomain. This would create huge problems. One of our uses
for these features is to build a highly available server that loads service
agents dynamically when a master scheduler determines that new work needs to
be done. We cannot have the other agents shutdown while a new agent gets
loaded and initialized.

Also, many people load plugins by examining assemblies in a well known
directory, or pointing the app to a particular directory, and this all
happens after the app is loaded and running. I would expect many of these to
break if that method is removed.

It's not impossible for static plugins but it does severely constrain what
we have to do to make it work. Here's what I think it would take to make
this work...

I would have to write an engine that runs during installation of the server
that fully analyzes all plugin dependencies and figures out what binding
redirects and codebase hints are needed for all the plugins so they can
locate their dependencies, and then add/merge them into an app config file.
Then figure out how to download a file with a .config extension over a web
service (often this gets blocked) because the files are stored on a central
server and this is a smart client (actually this is easy, but a pain
nonetheless - use a different file extension, but then it becomes a custom
file), then figure out how to tell the launcher which app config to use - we
want this to be a generic launcher, not one that is product specific. If a
plugin is added to the default list on the server then the installation
piece has to run again to add in the new dependencies, then all running
clients need to be shutdown and restarted to use the new plugin, instead of
just updating the files in place.

It does not handle adding new plugins at runtime without shutting down a
running application. It also does not handle the case where a user may want
to add a plugin locally on the client without adding it to the central
server's repository.

Perhaps there are simpler ways of handling this.

I would prefer to not have to write this as a collection of entirely
separate executables - that's what we did in the past and it was very
constraining.

Believe me, I appreciate the chance to provide input - I think everyone up
here appreciates it. Unfortunately, I don't have all the use cases worked
out because this is still a work in progress.

Here are some requirements:
All assemblies shall be signed - this forces strict binding.
This is a smart client that is centrally distributed on a server. The
product is initially installed on the server and clients distributed by a
click-once type installation (not using click-once, but similar).
Each plugin may have a set of private assemblies.
Each plugin may bind to common assemblies for shareable types. Common
assemblies must be backwardly compatible.
Plugins can bind to the same private assembly, the same version (located in
one or more directories), for non-shareable types.
Plugins can bind to the same private assembly, but of different versions
(located in different directories), for non-shareable types.
Private assemblies do not need to be backwardly compatible (but ought to be
if possible). If not, then it cannot be shared.
Each plugin can choose to or be forced to load in a separate appdomain. The
default is to load in the default appdomain (or the appdomain of the smart
client frame).  e.g. if it must run with reduced security settings.
A set of plugins ships with the product and is installed on the server -
this constitutes the base set of plugins.
The application is field extensible - plugins can be added after initial
installation.
Plugins can be added centrally so that it is common to all clients.
Plugins can be added locally so that it is private to a single client.
Plugins can bind to other plugins.
The plugin assemblies must be capable of being updated while the client is
running; the new bits wont take effect until the plugin is restarted.
Plugins may be written by third parties. This implies that they may be built
against different versions of common assemblies then what is actually
installed in the field. It also requires that a means of installing the
plugin to the client or server be provided.
All plugins are to be xcopy deployable - nothing needs to be installed into
the GAC.

I'm sure others can be added to this list...it's a start.

Agreed.

Thanks for listening; regards,
Dave