Just a quick note today, this time about Reporting Services.
I won’t go into too many details, but we have a Windows Service which loads nearly all of the assemblies it uses (barring the ones installed with the standard .Net Framework install) from a database, into custom application domains in memory, then unloads them when done. This means the assemblies never exist on disk.
I have just spent two days tearing my hair out, because scheduling local Reporting Services reports via this service didn’t work at one of our client sites (but did work on our test server). Server reports worked in both environments, but local reports threw an exception saying the ‘main’ report definition was invalid. Examining the exception detail showed an inner exception stating a path was invalid, which was coming from calls to System.IO.Path methods used to retrieve the version information stored in binary files (exes/dlls etc.).
At first we hadn’t noticed the version/System.IO.Path stuff and we thought the problem (given the top-level exception) was caused by us loading the report definition (rdlc) from an embedded resource. We assumed we were loading the wrong resource, or the resource was corrupt etc. Additional logging added to the service proved the retrieved definition was in fact correct.
Anyway, long story short… we solved it by installing the Reporting Services Redistributable on the server hosting the service (which is not the same server as is running the Reporting Services web server, hence the need for the install). Once the appropriate files were installed the system worked fine. It seems that code inside the Reporting Services assemblies, when working with local reports, tries to read the version number of one or more binaries (to work out what version of the rdlc to expect ?) and without the files existing on disk this process fails and throws an exception.
Most people will probably never encounter this, but on the off chance I’m not the only one who does, I thought I’d blog it for prosperity.