Plugins Design Question

In a Winforms app, I've currently got a 'plugin' architecture that
'discovers' available plugins at runtime and then uses dynamic assembly
loading to make them available within the "shell" application. In terms of
assemblies, this (in simplified terms) looks like:

launcher.exe <-- a nearly empty bootstrapper for the app
common.dll <-- the NON-visual portions of the architecture
main.dll  <-- the visual UI stuff, including the main MDI parent form
pluginX.dll <-- an example plugin assembly

Currently all is well with the pluginX project having only a reference to
the common.dll. This gives it access to the application object and all the
services it needs (data, security, configurations, etc).

I'm working on a new app-wide service now that has both non-visual
components and a UI component (a form). I'm trying to maintain the
separation between the common.dll and the main.dll, but the synapses aren't
firing in the right order today.

If I have the plugin (with it's reference to the non-visual COMMON) call the
non-visual component, then I will need that component to create the form.
This breaks my goal because it means that COMMON (the non-visual project)
has to know about MAIN (the project with the visual stuff). And when the day
comes that we want to use COMMON.DLL on a web project or with a different
winforms app, it gets ugly.

I could give the plugin a reference to MAIN.dll, in which case it could open
the form (from MAIN) and the form could create the non-visual component
(from COMMON). The downside here is that we've thus far avoided having any
reference to MAIN in the plugins. If we should need the plugins to work in a
different "plugin host" application, it gets ugly.

I *know* there's a simple solution pattern here, but darned if I can find it
on a Friday afternoon.

Any suggestions would be appreciated,

JD