The Global.asax(.cs) Application_BeginRequest fires on Cassini and IIS 7.5 (Windows 7) but not on IIS 8.5 (Windows Server 2012).
I've researched this in every way possible, changed settings both in web.config and IIS Manager and compared settings between 7.5 and 8.5. There doesn't seem to be much documentation on IIS 8.5 at this level.
The code is a simple Context.RewritePath call on selected urls.
Any suggestions on what to try or where to look for answers?
Related
I have turned on IIS on Windows feature but I am unable to open IIS in my personal laptop. Can you please help to solve the issue?
But if I try to open inetmgr, it shows the below error.
One thing I observed that IIS is not there in in Windows Administrative Tool(screenshot below) so tried to install IIS from https://www.microsoft.com/en-us/download/details.aspx?id=48264 but its is showing that latest version is already present in your computer.
Can you please help?
To enable IIS and the required IIS components on Windows 10, do the following:
1)Open Control Panel and click Programs and Features > Turn Windows features on or off.
2)Enable Internet Information Services.
3)Expand the Internet Information Services feature and verify that the web server components listed in the next section are enabled.
4)Click OK.
Required IIS components:
-Web Management Tools
IIS 6 Management Compatibility
IIS Metabase and IIS 6 configuration compatibility
IIS Management Console
IIS Management Scripts and Tools
IIS Management Service
-World Wide Web Services
Application Development Features
.NET Extensibility 4.5
ASP.NET 4.5
ISAPI Extensions
ISAPI Filters
WebSocket Protocol
Common HTTP Features
Default Document
Static Content
Security
Basic Authentication
Request Filtering
Windows Authentication
To ensure that IIS is installed and working, type IIS in the Search bar near the Start button. You’ll see the Internet Information Services Manager as a result. Click on that to open it.
We are trying to make a cut over from IIS 6.0 to IIS 8.0 Integrated pool on Windows Server 2012 Standard edition for an application built on ASP.Net Version 4.0. Our web application requests go into a RequestAcquireState ( ASP.Net Session gets locked for concurrent requests working with the same sessionid ) , in IIS 8.0 Integrated pool on the above Windows Server . However this behavior does not show up when we run the same app in Classic mode on IIS 8.0 .
Session is stored InProc.
We can rectify this situation on a Windows Server 2012 Data Center by modifying SessionStateLockedItemPollInterval in registry. However that solution does not work in Windows Server 2012 Standard edition.
This has left us perplexed -
why does an ASP.Net Run time Session issue surface in IIS 8.0 Integrated Pool for an application we have run successfully on previous versions of IIS and classic mode in IIS 8.0 ?
How do we rectify this problem now on Windows Server 2012 Standard edition ?
Thanks, will appreciate if some body can help
IIS 8 comes with .net framwork 4.5 so you may be running into missing the fix http://support.microsoft.com/kb/2828842
Issue 6
Symptoms
When you send many concurrent requests that have the same SessionId to an ASP.NET 4.5 web application, some requests may freeze at the RequestAcquireState stage unexpectedly.
Resolution
After you apply the hotfix, the hotfix makes sure that the EndRequest event will always trigger.
try installing this fix and see if that addressed the issue
On my IIS 7.5, my SignalR application always used long polling.
As per my search, IIS 7.5 does not support WebSockets yet.
I hope, I missed some tools or configurations to enable WebSockets in IIS 7.5. Or I didn't?
You cannot use WebSocket on IIS 7.5 (in other words on Windows Server 2008 R2 or Windows 7) because it requires HTTP.sys level changes AFAIK. So, you need IIS 8.0 and Windows Server 2012 or Windows 8 combination to leverage WebSocket. Also, IIS Express 8.0 supports WebSockect, too but you cannot still leverage that if you are on an OS which is lower than Windows 8 or Windows Server 2012.
IIS 8 Express Supports websockets New Features
Windows 7 is considered a Down-Level Operating system and doesn't support Web Sockets. Known Issues and Limitations
Time to upgrade to Windows 8 if you want to support for web-sockets!
Here's a summary of the required setup steps to host on Windows 2008r2 with IIS 7.5:
Update the SignalR application's web.config file to enable "run all managed modules for all requests" (for short, this is the RAMMFAR setting).
Update the web page that uses SignalR to communicate with the server:
Add a reference to the json2.js library.
Add a tag that forces the content to display in a recent browser mode.
Set up a Windows Server 2008r2 with IIS 7.5 as follows:
Install the .NET Framework version that your SignalR application requires.
Create a site and associate it with the appropriate application pool.
Update the Signalr Application's Web.config File
In your SignalR application's web.config file, add the RAMMFAR setting to enable running all managed modules for all requests. This setting was required to get the SignalR sample application running in on Windows 2008r2 and IIS 7.5 in all browsers.
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
</modules>
</system.webServer>
Update the Web Page that Uses SignalR
In the application web page that uses SignalR to communicate with the server, add the following code.
Add a reference to the json2.js JSON parser library. This script provides a JSON parser for previous browser versions that don't have it. You can add the script in one of two ways:
Add the NuGet package json2.js to your project, and then reference it in your web page:
Or as an alternative, reference json2.js on a CDN:
Add the following tag in the head section of the page. This tag, specifically the IE=edge value, forces Internet Explorer to display content in the most recent version available, rather than earlier modes (such as IE7) which prevent SignalR code from working.
Set up Windows Server 2008r2 and IIS 7.5
As noted, I built the sample SignalR application from the Getting Started with SignalR tutorial on .NET 4. This is a common hosting scenario on Windows 2008r2 and IIS 7.5. The server was a new default default installation of Windows Server 2008r2 and IIS 7.5.
Install the required .NET Framework version. In this case I installed .NET Framework 4.
Create a new site in IIS Manager, and associate the site with an application pool. Use integrated mode application pools, classic mode is not supported for SignalR. For this application I used the ASP.NET v4.0 application pool.
After following the above setup steps, I was able to deploy the .NET Framework 4-based version of the Getting Started with SignalR sample to the server, and it worked perfectly in IE (versions 8, 9, and 10), Chrome, and Firefox even though it was using fallback transport methods (forever frames in IE, and server-sent events in the other browsers). The interesting thing for SignalR developers is that apart from the above steps, I didn't have to change a single line of the SignalR code anywhere in the application to make this work.
This is a simple case but shows that SignalR really does support "automatic fallback" to earlier transport mechanisms when websockets support is not available on the server.
Hallo,
I am tryiing to migrate an application written with visual studio 2008 from windows XP IIs 6.0 To Windows 7 with IIS 7.5 and I have this problem:
Sometimes when I post the page, the server does not respond and after some minutes i receive e message "Internet explorer can not display a web page"
With IIS 6.0 the application works perfectly.
Please, can you help me ?
Mauro Servi
Try switching the AppPool to Classic .NET mode rather than integrated mode.
You can do this on the Application Pool's Basic Settings in IIS Manager
When I run my asp.net mvc site in visual studio 2008 is it running iis7 or iis6 Internally?
Also does mvc require iis7 (is intended for?)
Via Visual Studio, you're not really running IIS6 or IIS7. You're running Cassini. You can find out how Cassini differs from IIS here. As for ASP.NET MVC, it may be deployed to run under IIS6 or IIS7. As mentioned previously, you have to jump through some hoops if you want to run under IIS6 so IIS7 is ideal if possible. If you are stuck with IIS6 (maybe you're on Windows Server 2003) there are a couple of best practices (Url file extensions or wild card application maps) which Phil Haack has well documented which will help to get your application running correctly.
If you mean the one built in to windows, that is tied to your OS version rather than to your version of Visual Studio.
If you mean the version that Visual Studio uses as a development webserver, then that version is not IIS. Its an internal webserver (very similar to Cassini) suited for testing and debugging only.
MVC can work in IIS6 but you need to make sure to set your routing to "{controller}.aspx/{action}/{id}".
As for IIS6 or 7 for the "IISLite" that VS uses, I am unsure of that. I think VS2008 uses IIS7 because I do not need to add ".aspx" to my controller in the route when debugging.