Basically, I asked for an update on this issue (raised a
while ago) as it causes most of my problems due to shared assemblies:
http://support.dotnetnuke.com/issue/ViewIssue.aspx?ID=1354
John replied that this could be a workaround:
The way I would work around that until there is a way to
handle it in the core, is to put the shared components into their own install
package. That way, shared components will not get removed unless that
specific module definition is removed, and you could let the people who have
installed that component know that it should not be removed unless all other
modules from your suite are removed in the description of the module and in
your documentation.
And Erik:
thats actually the way i deliver my shared components... about the ui: i
just added a dummy module view... i'm not sure its possible to have a PA
install package without at least one view control, but you could use that view
control to explain that its a module that contains shared code, and tthat
it should not be removed yadayadayada
You could then use the module version to do version checking in your own
modules.
And
then:
That's probably right. I remember having to create a simple module
to make an install work. Joe has already put this item on the
roadmap though (the ability to install a component without a UI), so that
should be remedied soon.
If you really don't want that module to show in the DektopModules dropdown
then you could put code in an UpgradeModule method to remove that entry after
it gets put in by the core. A hack I know, but it is nice that we have a way to
run code after a module is installed and registered in in the core.
That’s
the gist of it….