I'm currently struggling with httphandlers in IIS.
I'm developing a website in .NET4 in VS2010 and Cassini. In this website, i have a gallery, whose pictures are loaded through my handler.
For example http://mywebsite.com/Gallery/123/Pic1.jpg
My HTTP Handler gets the id 123 and returns the picture from the database (simplified).
So, everything works fine in Cassini (VS integrated webserver) and in IIS7 in "integrated mode". Pictures are loaded like they should.
But I have to deploy this site on a shared hoster, who is using IIS6.
After many searching and own logging, I found out, the the request isn't routed to my handler, and so I get a 404 from IIS.
My definition which is enough for IIS7 integrated mode:
<system.web>
<handlers>
<add verb="*" path="Gallery/*/*" type="[coorect Type spec]" />
</handlers>
</system.web>
For IIS7 in classic mode I had to add
<system.webServer>
<handlers>
<add name="ImageHandler" verb="*" path="Galler</*/*" type="[type]" modules="IsapiModule" scriptProcessor="c:\windows\Microsoft.net\framework\v4.0.30319\aspnet_isapi.dll"/>
</handlers
</system.webServer>
This last config only works whith the stuff in the module and scriptprocessor attributes...
But this config doesn't work in IIS6....
Can anyone help me ?
The issue is that IIS6 typically decides what ISAPI handler to pass the request to by using the file extension. So it sees .jpg and tries to serve a static file from that path. This is also what IIS7 refers to as classic mode. And you'll note you are referencing aspnet_isapi.dll in your configuration because it needs to be told what should handle this. Once you've passed it into aspnet_isapi, the asp.net http handling pipeline kicks in and you can execute your handler.
The easiest fix would be to find a host that supports IIS7. Failing that, you could see if they have any url rewriting options. With that, you could rewrite things so that you append an .ashx on the url, which will let IIS6 grab it and put it into the asp.net pipeline and your handler would fire. You could also see if they allow wildcard mappings, but that is a very tall order for most shared hosts.
Related
I created a .net core api (version 2.2.0) and I'm getting the following error when I try to run on IIS.
The application process failed to start The application process
started but then stopped The application process started but failed to
listen on the configured port
I verified my web config and it appears to have correct set of values.Enabled logging and log file comes as empty.
Event log shows the following error.
I installed hosting bundle and checked still getting same error. Also tried giving permission to IIS_IUSRS to the output folder. It didn't make any difference. Having said that error code "'0x80004005' " suggests a permission error. Still couldn't figure it out. Appreciate any help !
Web config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\MyApi.exe" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
</system.webServer>
</location>
</configuration>`enter code here`
<!--ProjectGuid: 4d7644bb-9348-46f9-8397-95f01e03d599-->
Make sure you publish the site properly in iis. Your site root folder has enough permission to access it by iis. assign the iis_iusrs and iusr permission to the site folder. your application pool identity is set application pool identity or local system. anonymous authentication is enabled. and you installed the iis asp.net feature. make sure your site binding is correct and the application pool is using correct .net version and running under integrated application pool.
The reason behind the error message
The HTTP Error 502.5 - Bad Gateway and HTTP Error 502.5 - Process
Failure error messages occur in ASP.NET Core when IIS fails to execute
the dotnet process.
.NET Core Runtime is not installed
web.config file has not been transformed
To resolve this issue you could refer one the below-suggested way:
Install the .NET Core Runtime
The most common reason for this to occur is when you haven't installed the .NET Core runtime on the server.
You can download the latest .NET Core runtime from Microsoft's .NET download page.
After installing Bundle stop iis and start again.
Publish a Self-Contained Deployment
If you don't want to install the .NET Core Runtime. An alternative for .NET Core web applications is to publish them in the Self-Contained deployment mode, which includes the required .NET Runtime files alongside your application.
If you go with this option, you'll also need to choose a target runtime: win-x86, win-x64, osx-x64, or linux-x64. Because self-contained deployments are not portable.
Transform your web.config file
Another reason for this error to occur is when you deploy an untransformed web.config file.
This is likely to be your issue if you had a previously working web application and merely deployed a new version of it.
In ASP.NET Core applications, the web.config file contains a handler that directs requests to the AspNetCoreModule and an aspNetCore element that defines and configures the ASP.NET Core process to execute your web application.
Here is a minimal web.config file for an ASP.NET Core application:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false"/>
</system.webServer>
</configuration>
The issue is The untransformed web.config contains the variables %LAUNCHER_PATH% and %LAUNCHER_ARGS% rather than the correct paths. When IIS tries to run ASP.NET Core, it uses %LAUNCHER_PATH% and %LAUNCHER_ARGS% rather than the correct path and arguments.
To fix the HTTP Error 502.5 in ASP.NET Core, you need to transform the web.config and replace the untransformed web.config file on the IIS web server.
steps to transform web.config file:
This transformation takes place when you choose to publish your web application. The transformed web.config ends up in the published output folder. Therefore, you simply need to publish your web application and copy the resulting web.config file onto the server.
In a transformed web.config file, the aspNetCore element will look something like this:
<aspNetCore processPath="dotnet" arguments=".\MyApplication.dll" stdoutLogEnabled="true"
stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
%LAUNCHER_PATH% has been replaced by dotnet and %LAUNCHER_ARGS% has been replaced by the path to the main web application dll .\MyApplication.dll.
links:
Publish an ASP.NET Core app to IIS
To get some diagnostics for our MVC4 application (with an WebRole for Microsoft Azure) we installed Glimpse through NuGet.
Everything went fine, but when I enable Glimpse through the ~/Glimpse.axd page our application is completely unreachable. On every request we get the message "This Webpage is not available" (Chrome).
In the output window in Visual Studio 2013 I saw an error message which suggests to disable async support through the web.config:
<appSettings>
<add key="Glimpse:DisableAsyncSupport" value="true"/>
</appSettings>
Unfortunately this is not helping. When we turn off Glimpse everything is just fine.
How can I find out what the problem is?
Update
The logs shows me this warning:
WARN | Unable to locate '</body>' with content encoding 'Unicode (UTF-8)' for request. The response may be compressed or the markup may actually be missing a '</body>' tag.
Found my solution on the troubleshooting page of Glimpse.
In short, url compression was applied so had to disable this in the web.config:
<system.webServer>
<urlCompression doDynamicCompression="true" dynamicCompressionBeforeCache="false" />
</system.webServer>
I have an ASP.NET MVC 4 application running under IIS 8.5. My previous understanding/experience of these scenarios in MVC is that if a static file exists, it will be served. If it doesn't exist, the path will be sent through MVC routing. This is the desired behaviour, but doesn't seem to be happening.
By default if I create a catchall route at /blah.html and no corresponding static file, IIS serves up a 404 (courtesy of the StaticFile handler). The MVC route is never hit. If the file exists, it is served.
So, I did some Googling and chatting to colleagues and came up with the answer as posted here:
https://stackoverflow.com/a/14327897/1043198
In goes the handler:
<add name="ApiURIs-ISAPI-Integrated-4.0" path="*" type="System.Web.Handlers.TransferRequestHandler" verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" preCondition="integratedMode,runtimeVersionv4.0" />
Great! The request now hits the MVC app and my dynamic content is served as expected. Except now, when I put a physical file in place, I get an error again. An uninformative 500 error with the following information (and nothing else):
Module: ManagedPipelineHandler
Notification: ExecuteRequestHandler
Handler: ApiURIs-ISAPI-Integrated-4.0
Error Code: 0x800703e9
What's going on? Why does IIS not fall back to my MVC app when static files don't exist and how come when I fix that, the inverse occurs and static files are no longer served properly? I'm fairly sure this has always been default behaviour in the past.
App pool is running in Integrated mode, CLR v4.0.
After finding various answers and blog posts suggesting enabling runAllManagedModulesForAllRequests, it seems that this - while it works - isn't the right approach.
RAMMFAR does exactly what it says on the tin and runs all requests (including those for "unmanaged" static resources) through all managed modules, which has a performance overhead and can also cause unusual side-effects depending on the modules enabled and the requests run through them.
Turns out the only module required to solve this problem is the UrlRoutingModule which, when the precondition is removed, causes all static resources to be run through MVC routing (when no static file exists):
<remove name="UrlRoutingModule" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule"
preCondition="" />
I am developing an application based on .Net Framework 3.5 sp1 and hosted on windows server 2008(64bit).
While browsing wcf service (.svc) locally every things is ok but while browsing with full domain URL, it got an error.
local address is like this: http://localhost/MyService.svc
and domain address is like this: http://MySite.ir/MyService.svc
by the way pages (.aspx) and other files work correctly both on localhost and with domain address.
any Idea would be appreciated
Here is detailed error:
HTTP Error 404.3 - Not Found
The page you are requesting cannot be served because of the extension configuration. If the page is a script, add a handler. If the file should be downloaded, add a MIME map.
Detailed Error Information
Module: StaticFileModule
Notification: ExecuteRequestHandler
Handler: StaticFile
Error Code: 0x80070032
Requested URL: http://MySite.ir:80/MyService.svc
Physical Path: D:\inetpub\vhosts\MySite.ir\httpdocs\MyService.svc
Logon Method: Anonymous
Logon User Anonymous
Please make sure you've activated WCF components from here.
Or alternate and easy way is, go to control panel -> Turn Windows feature on or off -> and make sure you've all the options ticked as mentioned in below screenshot.
You might need to activate each box and accept in case you get errors when activating all features at once
OK, here is the answer:
Go to Handler Mappings | Add Handler Manager --> And then add below information
Request Path: *.svc
Type: System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Name: svc-Integrated
If anyone has this issue on Windows Server 2012, Bill Moon's answer here solved it for me:
"For Windows Server 2012... From the Server Manager, click on Add roles and features, select the appropriate server, then select Features. Under .NET Framework 4.5 Features, you'll see WCF Services, and under that, you'll find HTTP Activation."
I have windows 10 in my laptop and using visual studio 2015 for WCF development. WCF is running fine in visual studio but when hosted in IIS I got the same error.
I checked IIS handler. svc extension was missing. So I tried to add new handler in IIS as suggested by Mori in first answer. I didn't find type "System.ServiceModel.Activation.HttpHandler".
So I opened "Turn windows features On or Off" and installed features as highlighted in screen shot.
This worked for me.
If you're using .Net 4.x, the PublicKeyToken is 31bf3856ad364e35.
However, following this post about installing WCF Services properly in IIS, the handler was set up for me.
I wanted to add this as a comment to the answer but didn't have enough rep for it. I tried running ServiceModelReg and aspnet_regiis.exe with various flags and added HTTP Activation feature but it still didn't work. Even using the Handler mapping UI in IIS didn't work since it could not find System.ServiceModel.Activation.HttpHandler. What finally worked was adding the handler Mori mentions manually to my web.config file.
<system.webServer>
<handlers>
<add name="svc-Integrated" path="*.svc" verb="GET,HEAD,POST,DEBUG" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" modules="ManagedPipelineHandler" scriptProcessor="" resourceType="Unspecified" requireAccess="Script" allowPathInfo="false" preCondition="integratedMode" responseBufferLimit="4194304" />
My project was running .Net 3.5 and IIS 7.5 on Windows 7 and IIS 7.0 on Win Server 2008 R2.
Try unchecking WCF HTTP activations from "Turn Windows featured on or off" window (See here) and re-install by going to
%windir%\Microsoft.Net\Framework\v3.0\Windows Communication Foundation\
and execute ServiceModelReg -i
I have deployed a few WCF services to a server via a web setup project
they are being hosted in an IIS Application, which appears to be running fine.
However when i try to navigate to the wsdl, nothing is found.
I am trying to set up diagnostics logging, to get some information.
I have followed the advice from here: wcf trying to set up tracing to debug, not writing to log file
Also, I have tried what is in the referenced MSDN documentation: under "Recommended Settings for Deployment or Debugging" .. my web.config has that identical configuration. But no log file is being created.
Nothing useful in the event viewer.
Any ideas?
Could be a permissions issue; IIRC those don't always turn up in the event log. Ensure the user IIS runs under has write permissions to the log file path.
This is typically the diagnostic config I use. Seems to work for me.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
...
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.ServiceModel"
switchValue="Verbose">
<listeners>
<add name="sdt"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="D:\wcfLog.svcLog" />
</listeners>
</source>
</sources>
</system.diagnostics>
</configuration>
If you are not getting any output it may be because your service is not starting correctly. The ServiceHost must be up for diagnostics to output anything. With IIS even though your site is running it does not mean that the ServiceHost started correctly. It's usually a config issue. I'm not a web guy but doesn't IIS write to EventViewer if there is an unhandled exception in the website?
Also, you could try creating a custom ServiceHostFactory. That way your code controls the ServiceHost creation and you can trap any exceptions and log them on your own.
Creating a custom ServiceHost in IIS -> LINK
This is an old question but for the benefit of anyone who might stumble upon the issue:
Make sure you have configured both the system.diagnostics and the System.serviceModel/diagnostics sections configured.
Make sure you have them configured in the correct App.config/Web.config file. The thing to note is that multiple config files may exist in a project, and the one used depends on the Build Configuration.
Personally I had the very same symptom until I noticed that I put the sections
under app.config (in my case, client side tracing), instead of
app.DebugLocal.config. The later was used as my build configuration was set to DebugLocal.