a couple of XML files are created in the following location when an MVC application starts.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\<AppName>\Sub1\Sub1\UserCache
MVC-AreaRegistrationTypeCache.xml and MVC-ControllerTypeCache.xml
When I change or just re-save my web.config file, the app restarts, and MVC reuses those XML files from a previous run. For simple changes, and especially if no new assemblies are added, then this doesn't cause any problems.
I have found that if I re-save global.asax, then these xml files do get regenerated. This is my current solution for my following problem.
In my case, I change the web.config to point to a plugin assembly that contains controllers and areas. The application restarts, my app finds the new assembly, I do a BuildManager.AddReferencedAssembly(assembly), but MVC doesn't care, because
it reuses the cached area assemblies in those XML files. The restart, in my opinion, is corrupt because you are using files on disk from a previous run.
If I go and delete those files by hand, then MVC doesn't find them, and things are good. Also, as stated above, when I resave global.asax this seems to also recreate the XML files, which is good too, just not desirable from a deployment
point of view.
I view this as a defect due to corruption criterias.
I did look at the MVC source, and I couldn't find any way to turn this off, as it is hard coded in AreaRegistration.cs to use the cache if it exists.
I haven't tracked down why re-saving global.asax results in a complete refresh, vs web.config.
So, will this become a defect that will be corrected, or is there another solution that I don't know about yet that doesn't make me go down the global.asax route.