I have an application, that uses System.Web.Routing and it works great on all my environments. The only issue is, that my staging environment needs the ".aspx" at the end or I will get a 404. All other environments do not require it. They all run in Classic for the Managed Pipeline Mode with v4.0 .NET framework. I keep comparing IIS settings, but I can't find any differences. I've even compared web.config and machine.config, but no differences there either. Anybody know what it could be?
Make sure you have this in your web.config (and normally you do want Integrated, unless you can't for some reason and jump through the hoops so it works under Classic).
<system.webServer>
<!-- omitted for brevity -->
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
runaAllManagedModulesForAllRequests has gotten me a couple times in the past.
Related
I'm in the process of converting an existing ASP website into PHP while retaining the ASP website as an older version. Since I'm not an ASP developer, I thought it would be simple as moving the contents of the root directory into its own directory that I've labeled as v1.0 so that the ASP version can be viewed by going to www.mysite.com/v1.0 while the new PHP version (v2.0) can be viewed by going to www.mysite.com
Herein lies the problem. Doing this causes flags all kinds of errors (all related to "Server Error in '/' Application. Runtime errors"). The best I can figure out is that the web.config file needs to be tweaked in the v2.0 directory. Can any of you ASP experts recommend a simple solution to make this happen? I would like to have an empty root directory if possible since the new v2.0 version will be in all PHP and want to "self contain" the ASP version within the v1.0 directory as much as possible.
Thanks!
After a bit of wrangling, finally figured out that I needed to set up v1.0 as its own application under the IIS control panel. Once that was done, then all the contents of the root directory could be moved over to the v1.0 sub-directory and viewed via www.mysite.com/v1.0 -- thanks to Sean! for his help!
Most Classic ASP pages use Server Side Includes, if the site is using a SSI such as:
<!-- #include virtual = "include-file.inc" -->
, then you will need to change all of these to be
<!-- #include virtual = "v1.0/include-file.inc" -->.
I assume that you are using IIS 7 or IIS 7.5, since you are not seeing the actual error, you will need to modify your web.config file.
<configuration>
<system.webServer>
<asp scriptErrorSentToBrowser="true" />
<httpErrors errorMode="Detailed">
</system.webServer>
</configuration>
Reference:
http://learn.iis.net/page.aspx/564/classic-asp-script-error-messages-no-longer-shown-in-web-browser-by-default/
Update
Since it now sounds like you are using ASP.NET, you would need to change your web.config as below to see the full error:
<configuration>
<system.web>
<customErrors mode="Off" />
</system.web>
</configuration>
I am trying to implement the TinyMCE Spellcheck plugin that uses GoogleSpell. The thing is I am trying to install it in an MVC environment.
I started by referencing the .NET class Library DLL (MoxieCode.TinyMCE) in my project.
Then, I added this code to my web.config:
<system.webServer>
<handlers>
<add name="TinyMCE" verb="GET,HEAD,POST" path="TinyMCE.ashx" type="Moxiecode.TinyMCE.Web.HttpHandler,Moxiecode.TinyMCE" />
</handlers>
<!--previously existing rules-->
<validation validateIntegratedModeConfiguration="false"/>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
I then added these lines to my tinyMCE.init({}); call:
plugins: "spellchecker",
theme_advanced_buttons3: "spellchecker",
spellchecker_languages : "English=en",
spellchecker_rpc_url : "TinyMCE.ashx?module=SpellChecker",
These steps are outlined in the tutorial here. I then followed instructions from this stack overflow post which recommended the following modification to global.asax to make it mvc friendly:
routes.IgnoreRoute("TinyMCE.ashx");
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
Everything seems fine accept that when I browse to /TinyMCE.ashx i get this error:
Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly.
Requested URL: /TinyMCE.ashx
Why can't asp.net mvc process that url?
Make sure the handler is being applied at the correct element in the web.config.
IIS supports 2 types of modes, an integrated mode and a classic mode.
The classic mode is the how versions previous to IIS 7 worked. Depending on that, you put the handlers in the web.config section that applies to asp.net, or in the section that is picked by IIS directly.
After a fair bit of frustration I stopped messing with it on localhost in VS 2010. I suspected that it was a problem relating to IIS configuration, so I uploaded the site to a sub-domain of the live server. It worked without any problem.
I'm not sure why the code didn't work on localhost but evidently, the steps I followed to execute TinyMCE .NET and GoogleSpell were correct because they work on the live server.
I've used the UrlRewriting.Net module for a couple years now without any problems in Windows XP and Windows 2003. I just recently upgraded my home PC to Windows 7 and started developing a new website.
The plan was to use .html extensions and rewrite them to their .aspx counterparts using the UrlRewriting.Net module. Everything works flawlessly in VWD 2008, but when I try running it through IIS7 it is a different story.
When I try to access a page via the .html rewrite I can no longer access Page.User; it keeps returning null. If I hit the page using it's .aspx extension, Page.User is correctly populated. I should also mention that I have a LoginView controller in my Master Page and it suffers from the same symptoms: When accessing via .html extension it shows the AnonyousTemplate; When using .aspx extension it properly shows the LoggedInTemplate. I'm guessing the two are related.
[Note: I've also tried extensionless URLs and they exhibit the same problem]
The only way I've gotten it to work is to switch the application pool to Classic, which then requires me to add an ASP.Net ddl handler for the .html extension [otherwise it is handled by the StaticFileHandler and comes up as a 404 error]. However, I'd like my web app to run properly for people without having to fiddle around with IIS.
So I am left with several questions:
Does anyone have ideas as to why Page.User always equals null for .html => .aspx rewritten pages?
Why does it work in VWD 2008, but not IIS7?
What changed from IIS6 => IIS7 that could have caused this?
Any other thoughts on workarounds?
[Note: I just tried a .aspx => .aspx rewrite and it did not exhibit the problem. Not really what I want, but thought I should mention it.]
Just had a breakthrough with the UrlRewriting.Net module. This makes it work in Integrated Mode in IIS7:
<modules runAllManagedModulesForAllRequests="true">
After figuring it out I did a search on "runAllManagedModulesForAllRequests" and the first thing that popped up was Scott Guthrie's blog which actually talks about using it for this purpose.
Another approach that seems to work is to remove the Session module and readd it leaving the "Invoke only for requests to ASP.NET applications or managed handlers" checkbox unchecked. It looks like this in the web.config file:
<system.webServer>
<modules>
<remove name="Session" />
<add name="SessionManualAdd" type="System.Web.SessionState.SessionStateModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</modules>
</system.webServer>
It seems the problem is that the Session module doesn't execute for say '*.htm' files when HttpContext.RewritePath is used, but removing and readding the module in this fashion causes the Session handler to be executed for the request.
This solution was suggested on the thread below. Unfortunately Microsoft chose not to explain the reasoning behind this behavior fully:
http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7
Microsoft included a fix for this issue (at least for extensionless urls) in Service Pack 1 for Win7 and Windows Server 2008 R2:
http://www.microsoft.com/download/en/details.aspx?id=5842
Also available as a hotfix: http://support.microsoft.com/kb/980368
After this patch is applied, ASP.NET 4 applications can handle requests for extensionless URLs. Therefore, managed HttpModules that run prior to handler execution will run. In some cases, the HttpModules can return errors for extensionless URLs. For example, an HttpModule that was written to expect only .aspx requests may now return errors when it tries to access the HttpContext.Session property.
After applying SP1 or the hotfix, no web.config changes are needed to make the session and forms auth work for extensionless URLs rewritten to asp.net pages/handlers/etc.
I don't know if this fixes anything for rewrites to static file extensions like .htm. My guess is, probably not. I would try to avoid setting runAllManagedModulesForAllRequests="true" in production environments, because it adds unnecessary overhead on static file requests.
I wrote a tiny HttpHandler, which works beautifully on my machine. However, once it was deployed to our staging server, requesting it gave an 404. I usually prefer configuring HttpHandlers in web.config, but this apparently didn’t work on the server: I fixed it by creating an .ashx file containing just the reference to my HttpHandler.
The .ashx file:
<% # WebHandler class="MyNamespace.MyProject.MyHttpHandler" %>
The web.config setting:
<httpHandlers>
<add verb="GET" path="myhandler.ashx" type="MyNamespace.MyProject.MyHttpHandler"/>
</httpHandlers>
I assume the problem is caused by the server using a "special" port (888, don’t ask why) for the website. Can it be something else, what could I be missing?
Why am I seeing this behavior on the server? The HttpHandler runs fine on my local machine with configuration just in web.config, and here it’s also served from a “random” port, i.e. http://localhost:61229/myhandler.ashx.
It sure sounds like the web.config setting is not being found.
Is this IIS 7 by any chance? In that case make sure you're putting the handler in the <system.webServer> and its <handlers> section.
If you are using IIS7 but still want to keep your old IIS 6 config files.
By setting the Application pool to run in "Classic" mode, the handler will work again.
Not recommended, but sometimes this is a quick and good enough fix.
We are using the Intelligencia URLRewriting module for asp.net with version 2.0 of the framework and IIS6. Our URLs typically have no extension.
I understand that IIS6 cannot really deal with this situation without a blanket wildcard (which causes other problems).
However, it works! Sometimes. At other times (e.g. on one dev's machine, and on my machine when I point a different virtual directory at the app) it doesn't. By "it doesn't work" I mean the configured HttpModules never even get hit.
Can anyone explain this?
Thanks.
So it turns out what was happening was the following:
request comes in to (say) http://website/products/productid
IIS can't find this hence we get a 404
by chance we have a custom error page set up in IIS for 404s
this error page sticks the referring URL on the end of the 404 error.aspx page
so we get a redirect coming into asp.net along the lines of:
http://website/error.aspx?404;http://website/products/productid
our URLRewriting regexes were now set up in such a way that they discarded the error.aspx bit and dealt with http://website/products/productid as if it were the actual URL
so asp.net renders http://website/product.aspx?id=productid as requested!
I guess this could prove to be a useful kludge for someone, but we're moving to an isapi filter. One heads-up is that this will by default lead to a tight loop of redirects!
If you run a site using the Visual Studio development web server all requests will be handled by asp.net so your HttpModule will run.
On IIS6 this should not happen unless it is set up to forward the requests to asp.net.
Are you sure that when "it works" you aren't running under the Cassini development web server included in VS.NET ? Because extensionless wildcards do work under Cassini, which can be very confusing to say the least.
If you are using an IIS6 with ASP.net 4.0, you must specify and register the modules like this:
<system.web>
<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
not
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
</modules>