This project is read-only.

Web.config in Modules

Topics: Administration, General, Installing Orchard
Feb 3, 2014 at 1:48 PM
I would like to specify the module configuration in a web.config that is located with the module. This is to make deployment and management of applications within Orchard simpler. It seems others have contemplated this but most have left the settings to be placed in the Orchard.Web web.config. This leaves me with 2 questions:

1) What is the design time decision behind this? In MVC I have the ability to override and add settings in child folders.
2) If I were to create a way of specifying module specific configuration in the module web.config (similar to this , what else will break :-)!

Hope this makes sense.

(P.S. This is against Orchard 1.6.1 deployment)
Feb 3, 2014 at 11:02 PM
Why are you insisting on adding configuration to the module? I mean the module is part of the application code, and even its Web.config kind of is. If you add configuration (that is depending on the environment for example) to it then you make that module unportable. So why don't you want to store that config in the root Web.config, in the DB or even in some config file in App_Data?
Feb 4, 2014 at 9:34 AM
Thank you for you response.

I think it makes sense for the configuration settings that a module uses to be placed in the web.config file that the module owns. I have multiple web applications contained within a single instance of Orchard and as I add additional capabilities it would be easier and neater for the config that these require to be contained within their own web.config.

I have decided in this instance to allow configuration of the module in the dashboard and therefore negate the need for any web.config changes.

The main part of my question is why I am prevented from using the web.config mechanism that is delivered out of the box in ASP.NET. I was interested in why this mechanism is unavailable in Orchard.
Feb 4, 2014 at 12:46 PM
I agree with NiceJumper. Personally, I think the inability for modules to contribute to Web.config is one of the most painful limitations of the Orchard extensibility system. Piedone, you're forgetting that there are many things that MUST be configured in Web.config, such as most settings that control the behavior of IIS and ASP.NET. The fact that modules cannot contribute to such settings, neither at a global scope nor for requests that are local to the module, is the source of a lot of trouble. I was constantly tormented by this limitation when writing the Orchard.Azure module.
Feb 4, 2014 at 2:21 PM
Could give some concrete examples?
Feb 4, 2014 at 2:33 PM
Separate of concerns would be one for me. Currently we are running 2 of our own modules and one theme. When all the developers are touching the one web.config that is creating a much bigger concern than working on their own modules and web.config.

Perhaps it would be easier to discuss if we understood the reason for the lock down.
Feb 4, 2014 at 3:06 PM
I don't think it's a lock down but a lack of implementation. Also probably there are also limitations given by how MVC areas work but I don't know.
Feb 4, 2014 at 4:25 PM
Agree with Piedone on that one, it's not a conscious decision, it's just a tricky-to-solve side effect of how Orchard is structured vis-à-vis MVC.

To give one example I had recently, I implemented upload of large files using a controller action in a module. For this specific action, the IIS max request length needed to be increased to allow for bigger files. That can only be done on the root Web.config level, even if you only apply it to a specific route path using a <location> element.
Feb 4, 2014 at 6:21 PM
@Decorum: this is a case where I see a risk in module-level Web.config modification. The max upload size is something I, as a webmaster, would like to control myself at the application level.

Also this is an example where the config is, although related to a module, tied to an environment (because in some environments the limit would be too big, in other it could be further increased; it greatly depends who uses the module). Thus it can't go into a module as that would make the module a subject to necessary modification when used in different environments (i.e. if I wanted a smaller limit I'd have to modify the module's own Web.config, essentially forking the module). Also Web.config is something application-wide and not tenant-aware.

With modules that you only use internally and just in a specific environment this might be not something to worry about but for the majority of configuration scenarios for modules that should be portable (and tenant-aware) there are better options for storing configuration.

Now I don't say that wanting to use module-specific Web.configs is wrong (as you say, there are cases when there is simply no other choice either; the Web.config needed for serving static files for example) but I think it's rare that it's the best option if it's not the only one.

That said, the root Web.config of modules do work to an extent and are even necessary for e.g. for some assembly bindings so it might be not just reasonably possible but probably also straightforward to implement full support, whatever that would mean. I'd encourage you to open an issue to bring this discussion further, where both of you could also list use cases.
Feb 4, 2014 at 8:14 PM
I would also add that this would just give greater options for developers. The specific use case that I have is that the module has web services that it uses (and only this module will use). I would like this configuration to be place into the module web.config where it can be managed independently of Orchard.