I'm a corporate developer and was recently tasked with copying a live website that is already up. It's step one of a project and this is meant to be a testing copy. Project spec requires the site be an exact clone of how the site appears now. This is all being done on IIS 8.
I copied the folder and set it up as its own website, but the "_dev" version. I changed nothing at all in the web.config and even used KDIFF3 when I started having issues to ensure everything I'd copied was a binary copy (It's a Winforms site). Any time I attempt to navigate to the page, I get a 500 error. The original site, in the same box on the same IIS, is still fine.
Naturally, I enabled failed request logging and it turned out to be this:
ModuleName
IsapiModule
Notification
EXECUTE_REQUEST_HANDLER
HttpStatus
500
HttpReason
Internal Server Error
HttpSubStatus
0
ErrorCode
The specified module could not be found.
(0x8007007e)
ConfigExceptionInfo
I don't use IIS much, but I'm pretty sure the only reference either the working site or the problem site has which involves ISAPI is a reference to the .Net 2.0 aspnet_filter in System32 for the .Net 2.0 framework.
Since the sites have identical content, which is very simple content, I thought it was permissions. For 20 minutes or so I gave r/w/x for "Everyone" with inheritance to child objects enabled, essentially ensuring permissions could be ruled out on the folders or on web.config, and still had the same issues.
I'm sort of at the end of my rope here. I can't find anything more than the steps above as a fix, but I'm in the same boat, even after restarting IIS. Both sites are using the same Application Pool (a 2.0 one, Classic mode) and are simple WebForms. Does anyone know why I'm having this issue?
Update: I also tried it locally on my desktop instead of on the web server. I can connect flawlessly to it via Localhost. I then installed a second on my desktop just by copying the folder and adding a page to IIS. That worked as well. Copying the working local install to the server still gives me a site that doesn't work.
The answer was a strange one. The previous developer working on the site was familiar with the AJAX tools from earlier versions of Visual Studio and had installed .Net 1.1 on the box to ensure compatibility with his code. IIS was defaulting new sites to point to the .Net 1.1 DLLs, while running in a .Net 2.0 app pool. Changing all of these manually to point to the 2.0 DLLs fixed the problem.