Moving from IIS6 to IIS7.5 - Custom Handlers - iis-6

I am moving a site from IIS6 on one server to IIS7.5 on another.
This site was not writen by me, and from what I can tell, they use custom handlers to get around the AJAX limitations of the day.
I copied the code from the old server to the new (pre-compieled) and everything works except the "AJAX" stuff. There are several calls in the code to ashx files. These calls return .js files. On the old server this works great. Does not work on the new server.
In the web.config file I found the following lines:
<httpHandlers>
<add verb="*" path="*.ashx" type="AjaxPro.AjaxHandlerFactory,AjaxPro.2"/>
</httpHandlers>
For some reason this is not working in IIS7.5
Any suggestions are welcome.
Thank you!

I suspect this could be down to the configuration of the application pool managed pipeline mode. You can easily confirm this by changing the Managed Pipeline Mode for the application pool the site runs under to Classic. If this works and you want to continue to run in Integrated mode then you will need to add a handlers section to the web.config. This is different from the httpHandlers information you noted above.
The new handlers section should be in the system.webServer section. I'm sorry I do not know the exact setting for the item you note but you will need to include the preCondition="integratedMode" if you wish to run in integrated mode.

Related

Why are my Script Bundles only working on Server

I have deployed my app to my IIS server. The javascript/css seem to work when I browse the webpage from the IIS server (although some of the css seems to not be loading as well). However, when I go to another machine and view the webpage from a client, none of the Javascript seems to be enabled. The links to the scripts are there, and when I type their path into the browser, I am able to retrieve the file (so it's not a permissions issue or a path issue). Yes the browser I am viewing the page from has javascript enabled (it's my dev machine where everything works if I'm working from visual studio).
Can anyone help me figure out what is happening here? Everything works fine in my dev machine.
Edit
Ok I have tried everything I can find on the interwebs. I have tried adding the 'bundle' module, removing then adding (as below), I have tried with and without 'runAllManagedModulesForAllRequests', I have tried enableing and disabling the
<compilation debug="false" targetFramework="4.5" />
Nothing seems to work.
<modules runAllManagedModulesForAllRequests="true">
<remove name="UrlRoutingModule-4.0" />
<add name="UrlRoutingModule-4.0" type="System.Web.Routing.UrlRoutingModule" preCondition="" />
<remove name="BundleModule" />
<add name="BundleModule" type="System.Web.Optimization.BundleModule" />
<!-- any other modules you want to run in MVC e.g. FormsAuthentication, Roles etc. -->
</modules>
I just don't understand why IIS7 would be doing something different when you browse the website locally on the server and another thing when you browse the site on different machine?
Edit 2
Even more baffling. I figured there might be something wrong with bundling (some assembly not loaded correctly who knows) so to test the theory, I commented out all the bundling code on my layout and replaced it with hard coded links to the styles/javascript. Again, it works in development, it works when previewing on the server, but when you go to a client machine, none of the javascript seems to work!!! I've installed it on two different IIS servers now... still same problem!
Edit 3
Unbelievable. It looks like the problem is... drum roll. IE10. I am using integrated authentication so I was only using IE. Until I realised that chrome can prompt/pass credentials as well. So I opened the site from Chrome and no problem! I compared the html from my local version on my dev machine to the html coming from the server, and other than the fact that the URLs have an extra element in the path (the site is deployed to a virtual directory) the html is identical. So for whatever reason, IE has decided that it will not run javascript from my IIS server, but it will from every other website on the internet. I even used fiddler to double check that all of the css/javascript was being fetched and received (they are, even checked the temporary files folder after a clean sweep to see if the css/js was downloaded). So, as usual, IE is a piece of crap causing nothing but headache and misery. Now to figure out how to fix this (my organisation is 80% IE).
So for anyone out there who might run into the same issue and has to work with IE I solved the problem by adding this to my _layout.cshtml:
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
What this does is instructs IE to use the latest available rendering engine to process the html (in other words don't try to be smart and guess what my html is built for). So it essentially tells the versions of IE that have 'compatibility mode' to not use it.
For me this works fine because our organization is small and we are usually within one version of the latest release of IE. If the latest version causes issues, I can easy fix and deploy with no harm done. However, this IS NOT optimal for a general purpose website or organization with high numbers of users on a variety of IE browsers.
I came across this problem too.
I found was that Internet Explorer was set to "high" when browsing the internet when using our corporate network. Once I added my site to the trusted sites zone, everything worked.
You can check if your site in the Trusted Sites zone, but going to Internet Options -> Security -> Sites

What's the difference between publishing and building an Mvc 4 app with respect to unsafe code?

I have an asp.net mvc 4 app that references a c# project which uses the unsafe keyword and this is allowed for in the project properties. The problem is when I publish the web app and I get the unsafe errors. In another post (Publish web application with unsafe code), someone says there is a difference between publishing and building and the app's web.config file needs to be edited.
I added in the following to the web.config file:
<configuration>
<!--Some other configuration code-->
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" compilerOptions="/unsafe" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
</compilers>
</system.codedom>
<!--Some other configuration code-->
</configuration>
But this didn't work (also didn't work for the other poster). Rather than restate his question, my question is:
Given there's a difference between publishing and building for unsafe code, how can I check if this web.config change is being picked up correctly?
In addition, I've using IIS8 Express. Is there additional configuration I need to do in IIS to allow unsafe code to be published perhaps?
Possibly relevant: Before referencing the unsafe code project I was able to build the web app and view the unpublished result in the browser by binding some url in IIS to that project. After referencing, I get an error when using the url. Running the debugger from visual studio is fine and so this makes me think that IIS is the culprit. I'm a novice though and really am grasping for ideas. Any help much appreciated.
(Windows 8, VS2012)

403 Error (Forbidden) when trying to view my MVC4 application on AppHarbor

I'm new to both ASP.net and AppHarbor. I also have never deployed an ASP.net application before.
I've set up an MVC4 website using the Visual Studio 2012 release candidate and it is near completion. Locally, it is working fine / as expected.
To send the client a current progress demo, I've been advised that I should use AppHarbor to host the application / website.
I've gone through the process of setting up a Git repository and connecting that with AppHarbor. I then used the Build -> Publish Selection option in Visual Studio to create a 'Web Deploy Package' within my local copy of the repository. Finally, I pushed the files (shown below) that were created to the repository and AppHarbor listed the commit as 'Active'.
However, when I click Go to your application, all I get is this magnificent 403 page.
I've tried a bunch of things (none of which have worked so far) that I've seen in forums (including here and AppHarbor support), including:
Adding a <modules runAllManagedModulesForAllRequests="true"/>
Ensuring I didn't have multiple web projects.
Checking and confirming that there are no errors listed in AppHarbor.
I've turned CustomErrors off, yielding no differences.
I haven't touched any of the .config stuff since I began the project (because I don't know how to use them yet). Perhaps I've just not added something blatantly obvious in there?
You shouldn't use the Web Publish stuff when you want to deploy to AppHarbor. AppHarbor takes your source code straight up, builds it, tests it and deploys it.
Here's a guide on deploying your first app on AppHarbor using Git. There's also a video on the AppHarbor front page that you can check out.

Viewstate still present in page even though I'm using sqlserver to store the viewstate

I have an ASP.net web app and on my test (database) server I have enabled sqlserver to store the viewstate and when I run the app from visual studio this works fine.
However when I try to host the app on the production machine (IIS 6) the viewstate is still present in each page request.
If I use the exact same connection settings against the production machine and run the web app from within visual studio the viewstate is not present.
This leads me to believe that theres either
1) Something I need to enable/disable in IIS
2) Something in my production web.config thats interfering.
If anyone can help me solve this problem it would be much appreciated.
Note Should add that I'm using Ironspeed to generate the pages. So there might be a configuration issue that ironspeed requires.
SOLVED It was an issue with Ironspeed which is a third party application for generating asp.net pages - a key was required in the web.config which was on my local machine but not in the production machine. Guess when you inherit another framework you also need to make sure you follow the framework requirements.
The first problem I see is with your question itself because 'session' and 'viewstate' are two entirely different things.
Viewstate will be there regardless what your session persistence mechanism is...
POST EDIT:
Good that you changed your question but there is not a native or built in method for persisting viewstate outside of the default behavior - which begs the question what method are you using?
Do you have <pages enableViewState="false" /> inside the system.web section of your web.config...? This should disable viewstate for all pages.
Make sure you understand the difference between Session and View State. They are similar, but separate concepts. You are storing your Session in SQLServer, but you still have View State enabled.
SOLVED It was an issue with Ironspeed which is a third party application for generating asp.net pages - a key was required in the web.config which was on my local machine but not in the production machine. Guess when you inherit another framework you also need to make sure you follow the framework requirements.

IIS is closing connection on dynamic content

There is a strange problem I am facing, if any of you might have seen before.
I have freshly install OS (Windows 2003 SP2) and just have configured IIS on it and on the default site,the static content say hello.htm is working fine.But any dynamic content like hello.asp (classic asp) or hello.aspx (asp.net) is not working.
If I telnet and issue HTTP headers manually for static content it works but for dynamic content IIS is basically forcefully closing the connection.
There's nothing in event logs.
Any clues?
Stupid question, but do you have ASP.Net enabled in add/remove programs in and IIS itself? I don't think that would cause it to close the connection, but it is a common "gotcha" along with registering ASP.Net.
Look under Web Service Extensions in IIS.
Is ASP.NET marked "enabled"? Do you see it? If not, do a aspnet_regiis -i from your %windir%\Microsoft.NET\Framework\WHATEVERVERSION\ directory on the command line, and you will.
Then re-check Web Service Extensions and make sure it is enabled.