Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeGetting StartedGetting StartedInstalling DNN ...Installing DNN ...Auto "upgrades" to .NET 4.0 with each page visitAuto "upgrades" to .NET 4.0 with each page visit
Previous
 
Next
New Post
2/7/2011 4:42 PM
 
I am moving my DNN site to a new server.  I had everything upgraded (5.6.1 and all of the modules) running on .NET 3.5 on a Server 2003 box.  I backed up the db, copied the folder and moved the instance over in the usual manner.  I set the app pool on the new server to .NET 2.0 to start and everything works fine.

When I changed the app pool to .NET 4.0, I noticed a serious performance drop.  I happened to have web.config open in VS on the server and it kept asking me to reload the changes (when there should not have been any).  Then I noticed that DNN kept "upgrading" the framework on each page load, changing web.config and causing the app to reload which caused the performance issue (changes to web.config shown below).  I realize that it should do this the first time it detects the app pool is .NET 4, but something is messed up.  I looked through the Upgrade class and I can see  TryUpgradeNETFramework() called by UpgradeToVersion_510() but I'm not seeing why this is happening.  The host page is correctly reporting the version as 5.6.1.  I've also tried setting AutoUpgrade to false, but that had no effect.

I'm at a loss here; any help is appreciated.

I followed Michael Washington's directions here
http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/2619/Upgrading-DotNetNuke-to-ASP-NET-4-0.aspx


setup on the new server:
windows server 2008 x 64 (it is not R2)
IIS 7
.NET 4.0 classic app pool

snip from web.config
        <!--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" />-->
        <!--Upgraded by .NET 4.0 Upgrade version 5.6.1 - Date: 2/7/2011 4:11:31 PM-->
        <!--<bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.0.0.0" xmlns="urn:schemas-microsoft-com:asm.v1" />-->
        <!--Upgraded by .NET 4.0 Upgrade version 5.6.1 - Date: 2/7/2011 4:11:43 PM-->
        <!--<bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.0.0.0" xmlns="urn:schemas-microsoft-com:asm.v1" />-->
        <!--Upgraded by .NET 4.0 Upgrade version 5.6.1 - Date: 2/7/2011 4:14:55 PM-->
        <!--<bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.0.0.0" xmlns="urn:schemas-microsoft-com:asm.v1" />-->
 
New Post
2/7/2011 8:56 PM
 
The method Upgrade.TryUpgradeNETFramework() is actually called on each application restart from the Initialize.InitializeApp() method. TryUpgradeNETFramework in turn calls Upgrade.IsNETFrameworkCurrent(ByVal version As String) to test if web.config modifications for ASP.Net 4.0 have already been made. In IsNETFrameworkCurrent, we find the following test for ASP.Net 4.0:

Case "4.0"
    'Look for requestValidationMode attribute
     Dim configFile As XmlDocument = Config.Load()
     Dim configNavigator As XPathNavigator = configFile.CreateNavigator().SelectSingleNode("//configuration/system.web/httpRuntime")
     If configNavigator IsNot Nothing AndAlso _
             Not String.IsNullOrEmpty(configNavigator.GetAttribute("requestValidationMode", "")) Then
                        isCurrent = True
     End If
As you can see, the test is based on whether the <httpRuntime . . . > node has been updated to include the requestValidationMode attribute which is specific to ASP.Net 4.0. I suspect that this modification is failing to be completed, most likely due to the <system.web> section of your site's web.config being wrapped in a <location> section which is a known issue with this and some other web.config modifications done by the XmlMerge API.

If this fits your situation and you find that no requestValidationMode attribute was added to the <httpRuntime . . . > node, I would manually make the modification adding the following attribute and value:

requestValidationMode="2.0"

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
3/6/2011 6:54 PM
 
William Severance wrote:
...snip...
As you can see, the test is based on whether the node has been updated to include the requestValidationMode attribute which is specific to ASP.Net 4.0. I suspect that this modification is failing to be completed, most likely due to the section of your site's web.config being wrapped in a section which is a known issue with this and some other web.config modifications done by the XmlMerge API.

If this fits your situation and you find that no requestValidationMode attribute was added to the node, I would manually make the modification adding the following attribute and value:

requestValidationMode="2.0"

 
I have a similar situation. Comments are being added to the web.config file for each page view.

But:

requestValidationMode="2.0"

Is already present. And the problem is still there. 

I'm getting 4 lines of comments added per web page visit. (Can we say OUCH?) This is added twice:


<!--Upgraded by .NET 4.0 Upgrade version 5.6.1 - Date: 3/6/2011 4:52:47 PM-->
<!--<bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.0.0.0" xmlns="urn:schemas-microsoft-com:asm.v1" />-->

Those are in both "assemblyIdentity" nodes, i.e.:

runtime/assemblyBinding/dependentAssembly/assemblyIdentity

<assemblyIdentity name="System.Web.Extensions.Design"...
<assemblyIdentity name="System.Web.Extensions"...

But not in the Telerik node.

LOCATION NODE

I have both system.webServer and system.web wrapped in a location node as I have a subapplication running. i.e.:

<location path="" inheritInChildApplications="false">
    <system.webServer>
...
    </system.webServer>
    <system.web>
...
    </system.web>
  </location>

Removing system.web and setting:

<validation validateIntegratedModeConfiguration="true" />

Only results in an error.

I found this IIS.net forum post:

http://forums.iis.net/t/1176128.aspx

Which only confirms that this is something like what you've described above, i.e. An application is doing it (DNN). 

I cannot find anything that points me in the right direction to solve this though. 

This is show-stopper problem. 


Is there any way to work around this by modifying the web.config or something?


I could swap out the subapplication and put it under a subdomain and lose the "<location>" wrapper for the "system.web" and "system.webServer" nodes, but that's really an extremely poor solution. 

Or is there another way to get subapplications to work with DNN? 



 
New Post
3/6/2011 7:24 PM
 
Ryan,

After I had posted my comment I took a second look at web.config and at the .Net 4.0 upgrade code and found that even if requestValidationMode="2.0" had been added successfully (most likely from outside of the DNN application - i.e. manually or Visual Studio, etc.), the test will still fail and there will be repeated attempts (partially successful hence the growth of web.confiig) logged with each restart. And, since a change made to web.config forces a restart, it becomes an endless loop with severe performance hit.

At this time I see only three options:

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 (EventLog table) as it will continue to record each attempt.

Although this issue has been logged to Gemini (DNN-14940), it was not discovered and verified in time to make forthcoming 5.06.02 stabilization release. I would suggest that you add a comment to that issue in Gemini so that it stays near the top of the issue stack.

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner
 
New Post
3/6/2011 7:25 PM
 
Not sure if this helps, but these are the affected nodes that get comments added for each web page view:

     <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions.Design" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="4.0.0.0" />
      </dependentAssembly>

 
Previous
 
Next
HomeHomeGetting StartedGetting StartedInstalling DNN ...Installing DNN ...Auto "upgrades" to .NET 4.0 with each page visitAuto "upgrades" to .NET 4.0 with each page visit


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out