We Keep Coding

getting swagger to run in asp.net

I've inherited a class library that is using .NET Framework 4.7.2. In the library there are a bunch of ApiControllers with a number of HttpPost and HttpGet Methods on them. Errors have started occurring on some of the methods and these methods are typically called from a wordpress site.
To try and make things a bit easier for me to debug, I'm trying to install swagger into the solution. I've installed Swashbuckle.core with a runtimne version of 4.0.30319 and this has created a basic SwaggerConfig.cs file in my App_Start folder.
In the properties for the solution the project url is http://localhost/WordpressService and it's running under local IIS.
I have a local version of wordpress running in Microsoft Edge, and in IIS I can see that the WordpressService is running on port 80.
So now in the WordpressService solution I try to attach the debugger to the browser, then in the browser I try to enter http://localhost/WordpressService/swagger and other variations of the address, but all the time I receive the following error:
HTTP Error 500.21 - Internal Server Error Handler
"ExtensionlessUrlHandler-Integrated-4.0" has a bad module
"ManagedPipelineHandler" in its module list
I have this section in my web.config file:
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" />
</handlers>
</system.webServer> >
within IIS in the Handler Mappings section I can see ExtensionlessUrlHandler-Integrated-4.0 and it is enabled.
it also suggests that asp.net may not be installed correctly but it must be as I'm using VS 2017 and would need to be there for that. Looking around the net, the default SwaggerConfig.cs should be enough to get me going.
The only thing I can think of is that I may have installed the wrong version of swagger, but I'm not sure in that case which version I should be installing for this .NET Framework.

Ok, I figured the issue out and thought I'd post my answer for anyone else that may come across this issue. From IIS installation, it appears that only Framework 3.5 had been installed and not Framework 4.8. Installing 4.8 in the IIS section seems to have resolved this and I can now see my end points via swagger.

Simulating WCF route in WEB API 2

We currently have an old legacy WCF service that I really don't want to maintain but several clients still have access. We currently run all our API services in WEB API 2 in Azure. To enable backward compatibility I was hoping to simulate the WCF routing in WEB API using attribute routing like so:
[RoutePrefix("registration.svc")]
public class RegistrationDeprecatedController : ApiController
{
[HttpPost]
[Route("login")]
public async Task<HttpResponseMessage> Login(CredentialModel creds)
{...
Locally this runs like a dream. As soon as I publish to an Azure AppService however all I get is 404 not found. The specific route in question:
/registration.svc/login
My suspicion is that IIS hosting has the .svc route file associate to process the requests as a WCF call. An extensive search online failed to find anything on how I can change this association or even confirm if this is the case. Any ideas on how to fix or alternative solutions will be greatly appreciated.
Update
Found a solution but its not perfect. Found out that it is possible to directly connect to IIS on the AppService instance and change the Handler Mappings. This is not perfect as it would require a manual change when creating a new instance or deployment slot and I would prefer to automate the entire process.
If anyone else would like to do this you can follow a tutorial by benjamin perkins. I did have to install an IIS Manager for remote administration extension on windows 10 however for this to work. I removed all mappings associated to *.svc and the routing is now working.

Final solution was to remove the handlers in the web.config.
<system.webServer>
<handlers>
<remove name="ExtensionlessUrlHandler-Integrated-4.0" />
<remove name="OPTIONSVerbHandler" />
<remove name="TRACEVerbHandler" />
<remove name="svc-Integrated" />
<remove name="svc-Integrated-4.0" />
<remove name="svc-ISAPI-2.0" />
<remove name="svc-ISAPI-2.0-64" />
<remove name="svc-ISAPI-4.0_32bit" />
<remove name="svc-ISAPI-4.0_64bit" />
....
</handlers>
I was able to find the names by connection to IIS on the AppService instance. I was unsure which ones needed to be removed so I removed all that handlers associated with *.svc.

Deploying MVC4 .net 4.5 website to IIS7 Forbidden 403

I am trying to deploy a website to an IIS webserver but I keep getting a 403 forbidden error. I have tried all the solutions on this question but to no avail so I was wondering what else could be causing the 403
When I publish a different site to the same folder with the same app pool it will run and the only difference between the 2 sites is the one that isn't working is .net 4.5 and the one that is is .net 4
Has anyone got any ideas what may be causing the site to throw a 403 - I have checked the event viewer and nothing seems to be showing up

After trying and failing with a lot of things, I have found that it was due to the routing with MVC and adding the following line into my web config seems to have fixed it:
<modules runAllManagedModulesForAllRequests="true"></modules>

Put this in your web.config file:
<system.webServer>
<modules>
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
</modules>
Also copy to the bin folder on IIS any missing DLLs it complains about (like. System.Web.Http). Set them to copylocal=true in VS to prevent this error in future.
The other anwswer to this question (
<modules runAllManagedModulesForAllRequests="true"></modules>
) runs all modules all the time. According to this blog it's too drastic and will lead to errors and slow speeds: http://www.britishdeveloper.co.uk/2010/06/dont-use-modules-runallmanagedmodulesfo.html

How can I get a custom error page for trace.axd in MVC3?

My MVC3 application displays custom error pages for 403, 404, and 500 status codes, but browsing to trace.axd displays the following YSOD:
Server Error in '/' Application.
Trace Error
Description: Trace.axd is not enabled in the configuration file for this application. Note: Trace is never enabled when <deployment retail=true />
Details: To enable trace.axd, please create a <trace> tag within the configuration file located in the root directory of the current web application. This <trace> tag should then have its "enabled" attribute set to "true".
<configuration>
<system.web>
<trace enabled="true"/>
</system.web>
</configuration>
So I have trace disabled, which is good, but why is the 500 page not being displayed, since this it's a 403 being returned from the server? I'd be happy enough with a 404, 403, or 500 really - just as long as it's not an ugly yellow screen!
Edit: I was getting a 500 along with the YSOD when running on localhost, but it's actually a 403 on the server which is closer to what I was expecting - but still no custom error page. It's also a slightly different standard error page on the server:
Server Error in '/' Application.
Trace Error
Description: The current trace settings prevent trace.axd from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine.
Details: To enable trace.axd to be viewable on remote machines, please create a <trace> tag within the configuration file located in the root directory of the current web application. This <trace> tag should then have its "localOnly" attribute set to "false".
<configuration>
<system.web>
<trace localOnly="false"/>
</system.web>
</configuration>

Removing the IgnoreRoute as suggested by #Cosmologinaut didn't work for me and as he says feels wrong. I found a better solution which is to remove the tracing HTTP handler in the Web.config file:
<system.webServer>
<!-- remove TraceHandler-Integrated - Remove the tracing handlers so that navigating to /trace.axd gives us a
404 Not Found instead of 500 Internal Server Error. -->
<handlers>
<remove name="TraceHandler-Integrated" />
<remove name="TraceHandler-Integrated-4.0" />
</handlers>
</system.webServer>
Navigating to /trace.axd now gives us a 404 Not Found instead of 500 Internal Server Error.

Since there were no responses I asked #shanselman on Twitter, who suggested <deployment retail = "true" /> might solve it, but it still returned the same YSOD.
In the end I solved it by removing routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); from the routing config. Doesn't quite seem right, but it works.

Getting "The WebResource.axd handler must be registered in the configuration to process this request." error

I'm getting this error while running my ASP.NET app on IIS7. I've tried doing what it says to do but it doesn't help.
The WebResource.axd handler must be
registered in the configuration to
process this request.
> <!-- Web.Config Configuration File -->
>
> <configuration>
> <system.web>
> <httpHandlers>
> <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="True" />
> </httpHandlers>
> </system.web>
> </configuration>
I'm using a little bit of AJAX which is what I think is causing the issue. Has anyone encountered this before?

I figured it out so I'm posting it here for search reasons. It is a bug in ASP.NET and it has to do with having ColdFusion installed. Microsoft hasn't yet released a fix.
There are two ways to fix this.
Change the AppPool in IIS7 to "Classic .NET AppPool". I'm not sure of any implications with this setting.
Remove all the references to ColdFusion from your applicationHost.config file in system32\inetsrv\config.

ColdFusion installs a global wildcard handler mapping which apparently overrides many of the standard .NET handlers. The solutions mentioned work just fine, but if you can't switch to Classic Mode and don't want to screw with your ColdFusion installation, you can remove the inherited handler mapping at the individual site level.
To do this, go to the site in question in IIS, double-click on "Handler Mappings" under the "IIS" section, and find the handler named something like "AboMapperCustom-XXXXXX" with "*" for the Path. Select the entry and click "Remove" in the sidebar. This will only remove the mapping for your application, so it won't break any existing CF sites on the server.

In IIS7 you need to add the <httpHandler> section to <system.webServer> instead of <system.web>. Here is an example.

I got this error after carelessly copying my app's web.config between a pair of clustered servers, which overwrote the tag:
<system.webServer>
<handlers>
<remove name="AboMapperCustom-XXXXXXXX" />
</handlers>
</system.webServer>
with
<system.webServer>
<handlers>
<remove name="AboMapperCustom-YYYYYYYY" />
</handlers>
</system.webServer>
Locating the proper ID as per Josh's response and correcting the tag fixed it, but more importantly, will presumably keep that handler mapping from sneaking back in.

The issue happened to me on new Windows 2016 server where ASP.NET 4.6 was not installed. After installation everything got fixed.
Steps
- Run Server Manager
- Manage > Add Roles and Features
- Server Roles
- Web Server (IIS) > Web Server > Application Development > ASP.NET 4.6

I had this problem and that reason was incompatibility between Coldfusion and some configurations of ASP.NET applications when IIS App pool is in integrated mode. Coldfusion must be disable .