Wow… this has been one hack of a week.
After applying the .NET 4.0 Framework to all of My DNN 5.4.4 sites… I had no errors that I knew of… but know I am getting a dymanic forms error:
|
Error: is currently unavailable.
DotNetNuke.Services.Exceptions.ModuleLoadException: System.Web.UI.HtmlControls.HtmlTableCellCollection must have items of type 'System.Web.UI.HtmlControls.HtmlTableCell'. 'asp:Literal' is of type 'System.Web.UI.WebControls.Literal'. ---> System.Web.HttpParseException: System.Web.UI.HtmlControls.HtmlTableCellCollection must have items of type 'System.Web.UI.HtmlControls.HtmlTableCell'. 'asp:Literal' is of type 'System.Web.UI.WebControls.Literal'. ---> System.Web.HttpParseException: System.Web.UI.HtmlControls.HtmlTableCellCollection must have items of type 'System.Web.UI.HtmlControls.HtmlTableCell'. 'asp:Literal' is of type 'System.Web.UI.WebControls.Literal'. ---> System.Web.HttpException: System.Web.UI.HtmlControls.HtmlTableCellCollection must have items of type 'System.Web.UI.HtmlControls.HtmlTableCell'. 'asp:Literal' is of type 'System.Web.UI.WebControls.Literal'. at System.Web.UI.CollectionBuilder.GetChildControlType(String tagName, IDictionary attribs) at System.Web.UI.ControlBuilder.CreateChildBuilder(String filter, String tagName, IDictionary attribs, TemplateParser parser, ControlBuilder parentBuilder, String id, Int32 line, VirtualPath virtualPath, Type& childType, Boolean defaultProperty) at System.Web.UI.ControlBuilder.CreateChildBuilder(String filter, String tagName, IDictionary attribs, TemplateParser parser, ControlBuilder parentBuilder, String id, Int32 line, VirtualPath virtualPath, Type& childType, Boolean defaultProperty) at System.Web.UI.TemplateParser.ProcessBeginTag(Match match, String inputText) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ProcessException(Exception ex) at System.Web.UI.TemplateParser.ParseStringInternal(String text, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) --- End of inner exception stack trace --- at System.Web.UI.TemplateParser.ParseString(String text, VirtualPath virtualPath, Encoding fileEncoding) at System.Web.UI.TemplateParser.ParseFile(String physicalPath, VirtualPath virtualPath) at System.Web.UI.TemplateParser.ParseInternal() at System.Web.UI.TemplateParser.Parse() at System.Web.Compilation.BaseTemplateBuildProvider.get_CodeCompilerType() at System.Web.Compilation.BuildProvider.GetCompilerTypeFromBuildProvider(BuildProvider buildProvider) at System.Web.Compilation.BuildProvidersCompiler.ProcessBuildProviders() at System.Web.Compilation.BuildProvidersCompiler.PerformBuild() at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean throwIfNotFound, Boolean ensureIsUpToDate) at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile, Boolean ensureIsUpToDate) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at DotNetNuke.UI.ControlUtilities.LoadControl[T](TemplateControl containerControl, String ControlSrc) at DotNetNuke.UI.Modules.ModuleHost.LoadModuleControl() --- End of inner exception stack trace ---
|
This is unrelated to the email issues and CPU spikes we have been discussing on these forums... but...
The bigger issue is now this – when I applied the .NET 4.0 Application Pool (Integrated) The sites seems to be working fine… after seeing the error above I proceded to switch the Appl;ication Pool back to using 3.5 SP1… that now results in a server error:
Server Error in '/' Application.
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable the details of this specific error message to be viewable on remote machines, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "Off".
Notes: The current error page you are seeing can be replaced by a custom error page by modifying the "defaultRedirect" attribute of the application's configuration tag to point to a custom error page URL.
If I turn on error reporting for this – I get the following…
Server Error
If I switch everything back to running the .NET 4.0 Framework and take away the that was added to the web.config file… The site comes right back up no issues.
What’s even more strange is that this symptom of the site going down when switching the frameworks is that is only happens if I have a DNN Instance that has 2 or more portals.
This is on a Win 2008 Server running IIS7… All patches/hot fixes have been applied… with the exception of KB982519 – this should not affect anything like this…
Any ideas? What is your thoughts on the recompile of the DotNetNuke.dll file? See here:
http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/108/postid/377864/scope/posts/Default.aspx#377864
Besides the email issue, the CPU issue is causing havoc as well. In your mind - do any of the following make sense?
1. Our Setup is wrong… I don’t believe this as every version of DNN before 5.4.4 was working just fine… Not a problem at all. No changes in IIS7 were made since the upgrades either... everything was smooth running.
2. It is a bug in DNN… even thought they have not recognized it as one.
3. It is a bug in .NET 3.5 or 4.0 that is being exploited by DNN 5.4.4 and Microsoft will have to fix?
There seems to be no clear answer here?