IIS: Parser Error Message: Could not create type

Question

I am trying to build a simple web service in C# using VS2015 to be hosted on Windows Server 2012R2.

I have the code written and it works properly when hosted in the Visual Studio debugger. The debugger will launch IE and give me the UI to test the simple methods in my code. I can enter a temperature in Celsius and get back the temperature in Farentheit. So my understanding is that my code itself is working.

However, when I publish my project and attempt to load it in IE, I get:

Server Error in '/' 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 create type 'TestAutomation.AutomationInterface'.

Source Error: 



Line 1:  <%@ WebService Language="C#" CodeBehind="~/App_Code/WebService.cs" Class="TestAutomation.AutomationInterface" %>



 Source File:  /TestToolsAutomation/AutomationInterface.asmx    Line:  1 


Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.6.81.0 

I am publishing my project by going to Build -> Publish Web App. I am selecting "File System" as my publish method and am publishing to "C:\inetpub\wwwroot\MyAppName" in the Debug configuration with no check boxes in the File Publish Options. When I publish, I have the following files in the MyAppName folder:

-AutomationInterface.asmx
-Web.config
\App_Code
  WebService.cs

The obvious issue I see here is that there is no .dll file created with my compiled code. I'm far from an IIS expert, but isn't this supposed to be created the first time a user requests the page?

I then re-published and checked "Precompile during publishing" in the file options. When I do this, a \bin folder is created with files "App_Code.compiled" and "App_Code.dll" files. However, I get the same error in the browser.

Because my code works in the VS debugger but not when hosted in IIS, I suspect the problem is on the IIS side of things, but I'm not 100% certain of that.

When I request the IIS page in IE, I get an event 1310 with source "ASP.NET 4.0.3.30319.0" in the application event log that says "Event code: 3006 Event message: A parser error has occurred" along with a stack trace that shows a bunch of System.Web.Compilation functions.

I have searched for this error on Stack Overflow and other sites, but none of the suggested solutions appear to solve my particular problem.

I would appreciate any help the community could offer.

UPDATE: I enabled failed request tracing on the server. It appears that the error happens here:

154. view trace 
Warning 
-MODULE_SET_RESPONSE_ERROR_STATUS 


ModuleName
ManagedPipelineHandler 

Notification
MAP_REQUEST_HANDLER 

HttpStatus
500 

HttpReason
Internal Server Error 

HttpSubStatus
0 

ErrorCode
The operation completed successfully.
 (0x0) 

ConfigExceptionInfo

 ManagedPipelineHandler 

I lack the background to fully understand what IIS is trying to tell me. Any tips would be appreciated.

Answer 1

After struggling with this for hours and making all kinds of settings changes, and uninstalling and reinstalling IIS several times, I finally solved this.

I had to right-click on the folder in which I published my files in IIS Manager and select "Convert to Application." It's now working!

Answer 2

Here are a few possible ideas to explore:

Have you looked at the permissions for the account that the Application Pool in IIS is using to run this? There can be ASP.Net Temporary files that aren't being generated that could be an issue here.

Is ASP.Net registered with IIS? I've remembered more than a few times to have to run "aspnet_regiis -i" on servers to install the ASP.Net part so that it'll be present within IIS.

Is IIS configured to allow ASP.Net requests? In the IIS Manager on the machine level there is an "ISAPI and CGI Restrictions" to note.

---

Update: Perhaps you could look at the configuration for the Application Pool and see which .Net version it is using and whether it is integrated or classic mode. Those would be the next level of things to examine.