Thursday, October 30, 2008

"We have met the enemy and he is us."

- Pogo

So I've spent the last two days going crazy trying to get Microsoft SQL Server 2005 Reporting Services working on my laptop. I was getting an ASP.NET error when I tried to hit the report server's Web user interface (i.e. http://localhost/Reports). My error (for the datasphere search engines) was along the lines of:


Server Error in '/Reports'
Application.


Parser Error

Description: An error occurred during the parsing of a resource
required to service this request. Please review the following specific parse
error details and modify your source file appropriately.


Parser Error Message: Could not load type
'Microsoft.ReportingServices.UI.GlobalApp'.


Source Error:
Line 1: <%@ Application Codebehind="Global.asax.cs" Inherits="Microsoft.ReportingServices.UI.GlobalApp" %>


Source File: C:\Program Files\Microsoft SQL
Server\MSSQL.3\Reporting Services\ReportManager\global.asax


Line: 1

Version Information: Microsoft .NET Framework
Version:2.....



After much grasping at thin straws from the short list of online references to this error, and getting nowhere, I had gone so far as to uninstall and re-install MSSQL Server 2005 and IIS twice. I then spent a ton of time:

  1. Running Process Monitor to see if file or registry ACLs were preventing something from getting to what it needed.
  2. Modifying ACLs on the ASPNET temporary files folder.
  3. Modifying ACLs on the Report Manager folder.
  4. Modifying Local Security Policy settings.
  5. Comparing a working SSRS install on a W2K3 Server machine.
  6. Copying SSRS files from a working machine.
  7. Repeatedly running aspnet_regiis with various parameters
  8. Playing with the GAC trying to get my stupid laptop to "understand" the parent assembly (i.e. ReportingServicesWebUserInterface.dll) it couldn't seem to find.
  9. Swearing, begging, giving up, swearing some more.


Then, in the fashion such successful epiphanies seem to come in - i.e. randomly, sans connection to proceeding efforts - I remembered that on some work laptops we had had problems with Mortgage Cadence Orchestrator installs and had ended up modifying the machine Web.Config file (i.e. C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\Web.Config) to remove a line that was causing MCO to fail to launch.


<configuration>
blahblahblah...
<system.web>
<authorization>
blahblahblah...
</authorization>

<browsercaps>
blahblahblah...
</browsercaps>

<clienttargets>
blahblahblah...
</clienttargets>

<assemblies>
blahblahblah...
<add assembly="*">
blahblahblah...
</assemblies>
blahblahblah...

This wildcard directive to load all assemblies in the Web application's folder caused the MCO app to try and load non-.NET DLL files that were in the MCO app folder. I never heard a good explanation as to why this caused problems on only some consultants' laptops. Regardless, our "quick-fix" to circumvent that problem was to delete that wildcard line in the machine's Web.config file (this was known as the "Web.config line 61 wildcard problem"). Yet, now when I returned that line to the laptop's Web.Config file - SHAZAM! - the report server started working. Two days gone due to short-routing around a problem many months ago. Life at times seems nothing but dealing with the unintended consequences of previous actions/decisions...and I'm talking not just about I.T., parenting, or rescued turtles.

1 comment:

Nicole said...

Can i hear a hallelujah!
Glad it all worked out!