I've been dealing remotely with a weird situation with a Windows Server 2003 virtual machine that's running a ASP.NET 3.5 website... Or, at least is trying to run it.
The website was installed using the standard installer for the project, which has been used to install at several different locations. However, this one is behaving differently.
The website fails when it runs. In the Event Viewer, the following error is reported:
Exception information: Exception type: HttpException Exception message: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The error is reported on the website as:
Exception Details: System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Running the fusion log viewer, I can see that ASP.NET is attempting to load the following assemblies:
CppCodeProvider, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a VJSharpCodeProvider, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
First off, there is no reason why ASP.NET should be loading these assemblies. I can't find anywhere in machine.config or any other config where these assemblies are listed as required. We tried installing the 3.5 SDK, but neither was installed. I've only got version 10 of the CPPCodeProvider on my development machine.
What the heck is going on here??
NB: Please don't do a cursory google search and answer. Nothing I found applies. And if anybody answers
"Define DEBUG constant" and "Define TRACE constant"
I'm going to punch you through the intertubes.
Damnable red herring.
It turns out that I had a dependency that had a dependency on msvc71.dll. Because my virtual machine did not have this DLL, loading of the dependency failed. However, because of crappy exception messages in the code (and this part of the framework, frankly), this error showed up as
My first instinct when seeing something like this is to spin up
fuslogvw. Now, when I turned on fusion logging, it was telling me thatCppCodeProviderandVJSharpCodeProvidercould not be found. So, I thought that these were the cause of the error. QED.THEY WERE NOT. The fact that fusion couldn't locate them as absolutely no effect on the execution of an ASP.NET website. Know this well, internet searchers! Its a red herring!
I figured this out when I did what I should have done from the beginning--I dropped Process Monitor on the server, set the filter to watch the w3wp process for attempts to load DLLs, and waited for FILE NOT FOUND.
I found a copy of msvc71.dll on my dev machine (Sql Server had it) and dropped it on the virtual box's system32. All I had to do then was allow Network Service read and execute permissions on the DLL and everything was working again.