Is inter-assembly circular dependency bad?

[Anton Shepelev]

Hello all,

In our plugin system, not only the host calls the
plugins over a specified interface, but also plugins
call methods from the assmebly where the host is lo-
cated. In other words, we have a circular dependen-
cy between assemblies but not between classes:

+-Host assembly-+-Plugin assembly-+
Host------------>Plugin
|
Helper<------------+

Studio does not prevent this because plugins are
loaded using reflecion.

Do you see any drawbacks in this organization, and
any advantages in extracting the Helper class into a
separate assembly?

 

[Arne Vajhøj]

In our plugin system, not only the host calls the
plugins over a specified interface, but also plugins
call methods from the assmebly where the host is lo-
cated. In other words, we have a circular dependen-
cy between assemblies but not between classes:

+-Host assembly-+-Plugin assembly-+
Host------------>Plugin
|
Helper<------------+

Studio does not prevent this because plugins are
loaded using reflecion.

Do you see any drawbacks in this organization, and
any advantages in extracting the Helper class into a
separate assembly?

I can not see any hard problems. It should work.

I would split the helper stuff out in a separate
assembly though.

For various soft reasons:
* layers should only call down never up and a layer should
have its own assembly
* plugins can be developed and unit tested without the
entire application
* If you bundle the plugin interface contract and the
helper classes then the version of that becomes the
important version and you can evolve application and
plugins somewhat independently

Arne

 

[Anton Shepelev]

Thanks for the reply, Arne.

I can not see any hard problems. It should work.

I would split the helper stuff out in a separate
assembly though.

For various soft reasons:

-- layers should only call down never up and a
layer should have its own assembly

This is true, but on the other hand the more coher-
ent grouping as plugin assemblies and a single host
assembly seems good as well.

-- plugins can be developed and unit tested
without the entire application

I plan to deploy the host assembly with the helper
assembly embedded, while for testing and debugging
the latter can be used separately without the host.

-- If you bundle the plugin interface contract
and the helper classes then the version of
that becomes the important version and you
can evolve application and plugins somewhat
independently.

Hmmm. The helper classes do not deal with the plug-
in interface, the host does. Therefore, I plan to
embed the plugin interface into the host as well.