Enabled features with missing/disabled dependencies should be automatically disabled.


Otherwise we get an YSOD with Autofac resolution exception.
It may happen in various scenarios - eg. when you update the module code and there is a new dependency added, which is currently disabled. Or when a dependent module got missing for some reason.

So there are two options:
  1. Enable the disabled dependencies (if possible)
  2. Disable the feature(s) depending on disabled/missing features (if a dependency is missing it's the only option)
Second seems safer beacuse it lets you see the changes first and decide whether to enable the new dependencies at the moment or not.


PaulDevenney wrote Aug 1, 2013 at 11:08 AM

This is actually quite a severe problem. Take for example a scenario with 2 features, a "Caching" module and a "Caching.Azure" module. Enabling the Caching.Azure module suppresses the original dependency. If this feature is enabled on an environment that does not support it, it throws an exception (not a dependency issue, but same basic problem). You now cannot turn off this feature via UI or via command line (both throw the same error.

I would suggest the resolution to both these issues is the same. Feature disabling needs to be able to work without loading up an entire shell context (somehow).

pszmyd wrote Aug 5, 2013 at 9:43 PM

Good idea. There should be some fail-safe mechanism implemented that in any case would allow user to enter admin and/or CLI and perform some maintenance tasks.

The only problem is it's sometimes hard to determine which component is actually the source of the problem. Exception may be thrown by the one not necessarily responsible and we don't want to disable half of the features because one of the dependencies throws exceptions around. Anyway - it's really worth looking into and a topic for a bigger discussion.

CSADNT wrote Aug 6, 2013 at 7:18 AM

May be a 'debug' mode where you select features to enable before start

hkui wrote Oct 14, 2013 at 8:58 AM

Another duplicate: https://orchard.codeplex.com/workitem/20205
Although it describes a different scenario, which makes this issue even more important.

AimOrchard wrote Oct 14, 2013 at 10:38 AM

It is also a big problem if you wish to add a new dependency to an existing module where the module was already enabled but the dependency was not.

Jimasp wrote Dec 6, 2013 at 1:16 PM

While this issue is a bigger problem, in the case of most of the duplicate issues, a warning message at the top of the dashboard would suffice.

AimOrchard wrote Dec 6, 2013 at 2:26 PM

I would prefer that, by default, it would try to enable any new found dependencies that are not enabled at startup and the launch should FAIL (optional?) when it cannot.

Piedone wrote May 20, 2014 at 3:00 PM

AimOrchard wrote May 20, 2014 at 3:29 PM

Imho this should be considered an 'issue' not a 'feature'.

It would be nice if this got picked up in the near future.

Always such a pain at the moment if we add a new module and make an existing module (that is already enabled) depend on that: we always have to 'hack' the new module into the enabled state @ the database...

Force-enabling modules that we depend on, or force-disabling modules if not all dependencies are enabled (or could be loaded) both sounds fine to me.

CSADNT wrote May 20, 2014 at 3:36 PM

Anyway the site should not break, because we have no more way left to solve.
I think it is a recent regression, before the site was starting.