This past Saturday, I played with DNNGrid and ultimately wrote a blog about it.  On Sunday I returned to the site to see if any comments were present.  What I got was a dead web-site and the DotNetNuke Error page telling me that there was an error on my site.  Yikes!

So now what?

I did the first and most important thing -- blamed someone else! I wrote a note to my Hosting Company asking what was wrong.  But the reality started to hit me - so I didn't send the note ... good thing!

The reality of this issue was the DotNetNuke Error page -- this meant that DotNetNuke was able to contain the error and display a message.  So some things were working ... but the Home page was failing and the exception handler of DotNetNuke was catching the error and posting the error page.

So next I blamed the most recent blog post.  I opened the database via Microsoft's SQL Management Studio and viewed the recent blog post -- possibly something was wrong here as the home page does read the Blog Entries table to display the most recent post.   All was good.   RATS!

So what did work?  I have a child portal called www.tressleworks.ca/samples. So I open this site -- fully expecting to get an error page - Wrong again! -- worked fine.  Actually this was good news as now I could look at the Eventlog and see what error I was getting.  Progress ... limited, but still progress.

Opening the Eventlog showed a large number of errors.  Seems my blogs post was now on DotNetBlogs and I was getting addition traffic - all showing my Error Page.  Not what I wanted.  I started looking at the different events ... most we indicating "object reference not found" - my favorite error as it does not tell you what object and in this case the error was in a low-lever routine in-side DotNetNuke and below (Asp.Net).  So no real help, however I persisted on and discovered the following error:

DotNetNuke.Services.Exceptions.PageLoadException: Unhandled error loading page. ---> System.Web.HttpCompileException: c:\WebSites\PScarlett\tz3p9v.s20.dotnetsql.com\Portals\_default\Skins\sl02_6\horizontal full.ascx(27): error BC30560: 'admin_skins_login_ascx' is ambiguous in the namespace 'ASP'. at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath) at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.Compilation.BuildManager.GetVPathBuildResult(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile) at System.Web.UI.TemplateControl.LoadControl(VirtualPath virtualPath) at System.Web.UI.TemplateControl.LoadControl(String virtualPath) at DotNetNuke.Framework.DefaultPage.LoadSkin(String SkinPath) --- End of inner exception stack trace ---

Wow --- error BC30560: 'admin_skins_login_ascx' is ambiguous in the namespace 'ASP' --- what does that mean?

After some investigation it became obvious that this was not an error on my site -- I knew it! -- time to blame the Hosting Company --- off to write a nasty E-mail.   Again I slowed down (good thing) and asked that the Hosting company cycle the Application Pools associated with my site.  No Change -- ugh!

More investigation and I discovered that this is really an issue with the ASP.NET compiler not being able to resolve an element on the web-site.  Suggestions varied on the Web as to what to look for - most pointed to an error related to page naming. You could end up with two pages or libraries resulting in the ambiguity for ASP.NET.  I discounted these suggestions as the site has not changed in over 1 year (another issue) and has been solid.  This site based on V4.9.4 of DotNetNuke, which is a very solid build.

Back to the hosting company and requested that the Temporary ASP.NET Files directory be purged.  Apparently this is part of the Hosting Company's standard procedure when cycling the Application pool, so still no change.  RATS!

As it was getting late, I created an App_offine.htm file that would at least tell visitors I was "working on it" ... Actually the truth was closer to “I was sleeping” on it.   But, as one last desperate act, I sent out a Twitter message:

 "My site is down due to BC30506 error - 'admin_skins_login_ascx' is ambiguous in the namespace 'ASP' - Suggestions #DotNetNuke".  

It was a bit of a "Hail Mary" -- I was hoping someone would have a viable suggestion by Morning.

Well the morning came and I looked -- nothing -- ugh! So off to work and I would "deal" within once I got home.  Once at work, I took another look at Twitter to see if there were any suggestions.  There were two messages! - One from Cathal Connolly (CATHALC) and the other from Antony (WEBPC).  Cathal had a suggestion, while Antony pointed to some useful blogs posting on DNN.  Thanks Guys.

By the time I go home, the site had been down for about 25 hours. I was eager to try Cathal's suggestion, although it did seem a little lame.  He suggested updating the Web.Config changing the Compilation Debug Setting to “true” then after a bit reset it back to “false”.  Well at this point I was will to try anything.

So I did what Cathal suggested -- It work. 

It took the site several minutes to "wake up" from a full re-compile.  Once the site was visible, I poked around various pages ensuring all was working again.  After about 10 minutes I reset the Web.Config back to Debug="false".   Fingers crossed that the site would continue to work -- which it did. 

The issue was not a site error, nor a hosting issue, but rather an issue with ASP.NET.  So without Cathal's suggestion I was truly caught between haven and hell - in ASP.NET purgatory.

So ... Many thanks to DotNetNuke Community and specifically Cathal for the help.

Hope this blog will help someone else who, for a while looked like a "dear in the headlights" - completely at a loss what to do. 

Paul.