Quirky ASP.NET Issue and Fix – A 3essentials Tech Support Rep’s Experience
The .NET application itself installed to the c:\program files directory but was served via a virtual directory on the site in question. When I would try to access the application after installation IIS was showing a compilation error which is strange because we had made no changes to the application and it ‘should’ work out of the box.
After editing the web.config on the main site to show detailed errors I was seeing errors related to not being able to load assemblies from the main site on this web application. This was strange because the web application had its own web.config and none of the assemblies that were failing to load were needed or called for by the web application.
The answer to this problem was found in the following forum post:
http://runtingsproper.blogspot.com/2010/04/solved-breaking-parent-webconfig.html
So adding the encompassing tags specified in that post:
<location path=”.” inheritInChildApplications=”false”>
<system.web>
<!– … –>
</system.web>
</location>
Around the system.web and the system.webserver tags prevented the daughter web.config from inheriting assemblies from the parent web.config.
However, the location tags had an interesting unforeseen effect on the DNN parent site.
With each page visit DotNetNuke was adding a couple lines to the web.config consisting of:
<!–Upgraded by .NET 4.0 Upgrade version 5.6.1 – Date: 2/7/2011 4:10:14 PM–>
<!–<bindingRedirect oldVersion=”1.0.0.0-1.1.0.0″ newVersion=”4.0.0.0″ xmlns=”urn:schemas-microsoft-com:asm.v1″ />–>
Eventually after so many hits the web.config eclipsed its maximum default size, which is 251kb. Aside from the obvious issue of the file growing too large each time something is written to the web.config the whole site recompiles. This means that every page hit was causing the site to recompile causing a significant performance hit.
This was an issue familiar to us but we hadn’t seen it in a while and the usually very helpful DotNetNuke forums were down for a site redesign. Luckily my googlefu eventually found the answer here:
The options given by the poster who answered our question is:
1. Remove the location elements from web.config and move the child application so that no location elements are required in the DNN web.config.
2. Revert the Application Pool back to ASP.Net 2.0/3.5 SP1 – Note several changes will have to be made to web.config to reverse the .Net 4.0 upgrade. Also note that if you are using the Razor Host Module and Razor based modules, those require 4.0. This is probably the best option for now.
3. Delete or rename the file /Install/Config/Net40.config. This will cause an error to be logged each time the site restarts but should stop the repeated modification of web.config and its resultant growth in its size as well as reduce (but not eliminate) the performance hit. You will need to periodically truncate your Event Viewer (Event Log table) as it will continue to record each attempt.
We decided to follow option 3. While this means the event log will fill up quicker than normal there is very little danger of the site going down for this issue, and most DNN sites should have a task that truncates the event log every couple weeks or so anyway.