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:
- Running Process Monitor to see if file or registry ACLs were preventing something from getting to what it needed.
- Modifying ACLs on the ASPNET temporary files folder.
- Modifying ACLs on the Report Manager folder.
- Modifying Local Security Policy settings.
- Comparing a working SSRS install on a W2K3 Server machine.
- Copying SSRS files from a working machine.
- Repeatedly running aspnet_regiis with various parameters
- 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.
- 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.