Why in Themes folder the mvc assembly binding is for v 3.0

Topics: Customizing Orchard, Troubleshooting, Writing themes
May 2, 2013 at 12:32 PM
Edited May 2, 2013 at 4:25 PM
Seems these instructions must be removed, they don't bind to correct version and don't use the Dependencies path ?
Is there any reason for this ?

here is the code in the Themes\Web.Config
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="2.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
Moreover I dicovered that 90% of the web.config load mvc 3, the 10% left use MVC 2.0 ????

But the main web.config reference system.web.mvc 4.0
May 2, 2013 at 4:39 PM
Edited May 2, 2013 at 4:40 PM
In fact that's a total anarchy, some modules (autoroute) use system.web.mvc 3 and system.web.webpages 1
some others (mail) system.web.mvc 2 and system.web.webpages 1,
others system.web.mvc 3 and system.web.webpages 2
and the root web.config uses system.web.mvc 4 and system.web.webpages 2

Is it intentionnal ? Does this has any influence ?
May 2, 2013 at 5:00 PM
We should migrate to 4.5 and synchronise all this
Developer
May 3, 2013 at 3:07 PM
I think there was a work item from someone with the same or similar comment: https://orchard.codeplex.com/workitem/19444.
May 3, 2013 at 3:59 PM
Edited May 3, 2013 at 3:59 PM
Hello Spyke,
Ok but this work item is refering to the root web.config, isn't it ?
Here I am speaking of many web.config in orchard modules from the core distribution from codeplex.

Seems that the instructions from the upper web.config 'supersede' in the case of system assemblies mapping these contained in the down-level web.config.
So every System.Web.Mvc.dll is mapped to 4.0 ?

But for webpages, I am not sure, I have not found the mapping instruction.

And as I am experimenting actually lot of difficulties with Azure Web Sites, I am reviewing any point that could cause a problem in this special hosting environment where Microsoft has optimized asp.net.

So if for some reason mapping is not interpreted identically on AWS, I would prefer to have homogenous writting of web.config.

I don't see how a web.config from core orchard modules in v1.7 could have any influence on an external module ?
Coordinator
May 4, 2013 at 2:40 AM
The web.config file at the root of modules does not do anything, as far as I know. I'm not even sure why we have it at all.
May 4, 2013 at 7:05 AM
So what's the logical in all these hierarchical web.config ?
Pbs on AWS drive me to try having a better understanding of any élément of them, and the conf files are a major one.
Coordinator
May 4, 2013 at 9:07 PM
I don't know. Nothing is served from the root of a module, so they don't matter. The ones in Script, Content or Styles subdirectories do, and those web.configs matter, but as I said, I don't know why we even have the ones at the root of each module.
May 5, 2013 at 8:14 AM
Edited May 5, 2013 at 8:15 AM
May be suppressing would avoid any misunderstanding and questionning ?
Coordinator
May 6, 2013 at 5:01 AM
Yes.
May 6, 2013 at 9:52 AM
and in themes ?
Coordinator
May 6, 2013 at 6:14 PM
Should be exactly the same. The one in views, scripts, content, and styles should matter, but not the one in the root.
May 7, 2013 at 10:09 AM
The (module) root web.config is mostly for intellisense is it not? VS wouldn't have any intellisense in the views otherwise. Its the same for MVC Contrib Portable Areas.

It would therefore only encumber the developer with incorrect versions being there and only within that module. Potentially features could be invisible to the developer that are within newer versions of MVC and ASP.NET. As long as the references in the project file are correct it should all be good though.
Coordinator
May 7, 2013 at 5:10 PM
Ah yes, good point.
May 7, 2013 at 5:13 PM
Edited May 7, 2013 at 5:14 PM
WTF. Wrong thread. My bad.
May 8, 2013 at 7:42 AM
So the idea is to keep them for developper with correct versions and may be not deploy ?
May 8, 2013 at 10:10 AM
I say update as we go as it brings a little more clarity on the technologies that area used .

We do want the web.config file to be deployed for modules that are packaged and shared as others may start using and adapting that code to their needs from the gallery or shared along.
Its probably used by webmatrix as well when opening a site. I quite often use webmatix to open a site from Azure and make some quick changes (or then open in visual studio). So its probably best to attempt to keep them up-to date but letting them rust is probably not a breaking thing. (unless you don't have older versions of MVC installed and its referencing the GAC rather than the lib folders).

More detail about web.configs and areas (The module acts as an area and is like a portable area (also acts like an area)) ... you can stop reading :)
Areas -
http://mstechkb.blogspot.co.uk/2010/10/areas-in-aspnet-mvc-20.html
Portable Areas -
http://elegantcode.com/2012/04/06/mvc-portable-areas/

Styles and Scripts folders are bound by physical location rules of IIS. The module root directory should still be invisible to the process to my knowledge (could be wrong). The Scripts, Styles and theme folders describe their own accessibility and access rights.
May 8, 2013 at 10:53 AM
Its probably used by webmatrix as well when opening a site
It is not logical, but I don't use web matrix, it should use the site web.config ?

My thinking is that the less files we deploy, the less questionning we have when a pb raises.
May 8, 2013 at 11:52 AM
You are probably right about webmatrix as its loaded as a website rather than a solution.

What problems are arising that make you seek the web.config files out? I've mostly turned off to them apart from needing to change the odd setting in Orchard.Web and making different content serving directories.

Deployment:
There could be an extra step added to "click to build" process to delete that file i guess. For packaging and general deployment I would rather it still being there by default. Packaging for sharing modules to test and play with, and deployment i have my reasons (mostly for some older orchard sites and copying them down).
May 8, 2013 at 12:52 PM
Edited May 8, 2013 at 12:58 PM
What problems are arising that make you seek the web.config files out
I recently entered a full week of problem on Azure Web Site concerning Monitoring and cache.
(monitoring is set from a config file \config\hostcomponents.config and this file is not always used on AWS ?
and cache is not working, a reason could be a missing parameter in web.config ?)
As I was having no idea of the problem I started eliminating its possible reasons.
One question raised about the influence of all these web config: if you use 50 modules, you deploy more than 150 web.config files.
Then I noticed that some of them, in Orchard Core and Framework were containing different information.
From this point I started questioning myself on the influence of these files.
Bertrand told they are useless, so let's rip them out reducing the error factor.

For deployment I am using VS2012 publish and this process is spending part of its time
1) to adapt web.config for non debug and some other adaptations
2) deleting and copying web.config ... that had never changed, but as it changes them before comparing....

I also noticed that some VS2012 deployment settings have no influence on Orchard deployment, as for the debug file info which is always deployed if generated, whatever be the VS flag.
So I stared searching for info on what orchard is doing in the packaging process? is the VS publish packaging using what orchard has builtin for ?
I know that I have to dive into this code one day or another....

To come back to web.config: if we suppress them, we have less to maintain and deploy faster seems the conclusion.