I noticed that asp.net 4.0 now installs a top-level isapi plugin (in iis6), such that it can inspect every request coming to the server. Should this now allow us to run MVC applications with extensionless URLS and have the aspnet isapi process them correctly without requiring the wildcard mapping (and avoid the performance penalties associated)? I havent found anything written about this yet, and havent had time to investigate. Thanks
ASP.NET 4.0 installs the C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll ISAPI filter in order to map incoming request to the new CLR, but this filter is not registered as wildcard mapping but is associated only with known extensions. It does not intercept every incoming request. If you want to have extensionless urls you will need to perform the same steps as for ASP.NET 2.0 but use the new ISAPI filter instead.
found the answer:
Link
appears that there are new features in asp.net 4.0 that enable extensionless urls. I need to do more research on this to find out how to utilize it.
Basically it appends /eurl.axd/GUID to each routed request, which then gets passed to aspnet_isapi.dll to be processed. the eurl.axd is then removed at this point.
The problems Im having is how these interact between my Ionics rewriter IIRF software and this new .net rewriting... they seem to be interfereing with each other at times.
Related
I am attempting to do some domain redirects on one of the sites on my server (Server 2003, IIS6), but the Extensionless URLs feature of .Net 4 keeps tacking on that eurl.axd/GUID before the redirect. I found some info on that here.
I would just disable this feature, as described here, but I am pretty sure this will impact an MVC .Net site I also have set up in IIS (because MVC uses extensionless URLs).
Can someone please assist me in finding other options? Is there a way to just remove the eurl.axd/GUID from the URL, via an IHttpModule? I haven't been able to find an example of anyone doing this or something similar.
Ok, I seem to have fixed things on my own. Originally I had both my websites set up in IIS under the same App Pool. I separated them into different app pools, made sure they were both set to .Net 4, and everything started working. Now when users are redirected from one domain to another, the eurl.axd/GUID does not get tacked on to the end of the URL.
I'm looking at putting together a REST based system which still has a standard browser style access. My desire is to have both of these on the same machine, but what are my options?
Use IIS to host both the web-site and the REST service (different URIs, e.g. http://mysite.com/ and http://mysite.com/api
Use IIS and some magic I don't yet know to have two domains mapped to the same machine but different services (e.g. http://www.mysite.com and http://api.mysite.com
Combine the two technologies into a single service (that perhaps uses routing tables to direct the requests to MVC or WCF where appropriate).
My preference would be the third option, this would allow me to have a single code-base and single repository accessing. The WCF page on codeplex mentions in its release notes, "not tested with MVC3" - is this suggesting that this is a possible approach?
I'm not keen on using MVC for the REST implementation as it is intended that the majority of interaction with my site goes via API, so I want that as the focus.
I've ported the contact manager to use MVC 3. It definiately works though we've not done exhaustive testing. The one thing in general to cognizant of with regards to web api is that both MVC Routes and Service Route are greedy. If your default route is first then MVC will try to grab your HTTP Service requests. One thing you will want to do is put your Service Route first before your MVC routes. If you run into additional issues, you may need to use custom routing constraints.
In http://webapicontrib.codeplex.com there is a sample that works with MVC 3. It is in the Samples/experimental folder. However, it was built with a custom version of WCF Web API. I don't believe it needs to be though. I've been meaning to get the author of the sample to switch it over.
I have a .NET 4 application that runs as a windows service. It runs periodic tasks and provides WCF restful webservices. It already hosts a silverlight web page (via WCF) that allows a user to configure the service.
Now I have a requirement to provide information on HTML/java script pages (e.g. for browsers and platforms that don't support Silverlight). I can serve simple HTML and javascript pages through WCF but that becomes laborious very quickly. I'd like to use MVC2.
Is it possible to provide MVC2 web pages from within a windows service? Or at least use some of the functionality provided by MVC like routing and the view engine?
Or is it more trouble than it's worth and should I head down the path of a separate app hosted on IIS?
You can host the ASP.NET runtime in any type of application including a Windows Service using the CreateApplicationHost method. Although note that by doing this you lose the robustness, security, logging, etc... that a real web server such as IIS provides.
Since you're asking the question about what route to take, I'd host an MVC2 application in IIS. Why recreate a web server using WCF when IIS is already there - and since you're asking, it sounds like that's a viable option.
I agree with Darin's answer that you can host ASP.NET MVC2 in any application, but I think you're going to end up recreating a lot of plumbing that's already in place with IIS.
On the upside, if you go with serving up ASP.NET MVC2 resources in a WCF service application, it may end up rocking and you could have a nice application you can sell on the side. :)
We are getting ready to do a an initial deployment of an ASP.net MVC app on IIS 6 running on Windows Server 2003. We've been reading about performance issues involving the use of extenionless urls in MVC applications specifically in the case of removing the '.aspx' extension from the controller portion of the url.
Has anyone who has deployed an MVC app in the past experienced any performance degradation in this area? Was it noticeable, and was it worth it for having the cleaner URLs? Our application will rarely have to deal with more than 1000 or so concurrent users.
Edit: Thanks for all the responses, it's working quite well, although there are a few strange requests going through as some people mentioned, I think we can work around these using the suggestions mentioned here.
We recently deployed an app that received approx. 20 million page views over a 3 month period using the IIS 6 wildcard mapping setup and had no performance issues. We did host most of our images on a CDN, but other static content was served directly from the site.
For what it's worth, IIRC, the asp.net handler will pass requests for static file types back to IIS through a default handler for processing. The only practical performance hit is the time during that process that a worker thread is occupied identifying and transferring the request. In all but the most extreme scenarios, this is too trivial to matter.
As an extra note, we load tested the application I mentioned prior to going live and found that it could handle nearly 2000 static requests per second and around 700 requests per second for pages that involved database activity. The site was hosted on 4 IIS 6 servers behind a ZXTM load balancer with a 1GB internet pipe.
Here's a link with some good advice on the whole static file handling business:
http://msmvps.com/blogs/omar/archive/2008/06/30/deploy-asp-net-mvc-on-iis-6-solve-404-compression-and-performance-problems.aspx
The problem with not using extensions on IIS 6 is that you don't want static requests to go through the ASP.NET stack. If all of your static requests come from one (or two...) subfolder(s), you can exclude them. This should fix the performance issue.
Quoting from the linked post:
Now, to remove the wildcard map on the
/Content subdirectory, open a command
prompt, go to c:\Inetpub\AdminScripts,
and run:
adsutil.vbs SET /W3SVC/105364569/root/Content/ScriptMaps ""
… replacing 105364569 with the
“identifier” number of your
application. (Also, you could replace
“Content” with the path to any other
directory.)
We ran a fairly busy site with IIS6 wildcards on for extensionless URLs and although we never noticed much of a performance hit, we did have a little hack that worked quite well:
For all folders that contained only static files, like /css, /images, /scripts etc, in IIS we set them as their own application, and disabled the wildcard setting, which meant IIS handled the requests rather than routing through ASP.Net.
Url rewriting can help you to solve the problem. I've implemented solution allowing to deploy MVC application at any IIS version even when virtual hosting is used.
http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx
Instead of serving all the requests by ASP.NET, you could specify e.g. mvc as the extension (say index.mvc) and map that extension to aspnet_isapi.dll in IIS 6.
This means only known extenions will be processed by asp.net, others like static files stay the same as before i.e. served by IIS itself.
As a dev team, we're looking to switch to asp.net MVC and I've heard rumors about IIS 6 not being able to support all of the MVC functionality. Is this true? Is there any official set of functionality supported in IIS 7 vs IIS 6? Should we completely avoid running it on IIS6?
You do not loose any functionality of ASP.Net MVC; however, you have one of two options. You can either define an extension on your URL's which will allow you to set up mapping. So for example:
www.example.com/books/computer/list
might become:
www.example.com/books.mvc/computer/list
You can use any extension you want so long as you map to ASP.Net. I am currently using .aspx which meant I could avoid changing IIS configuration at the sacrifice of having extensionless URLs.
The other option as mentioned is using a wild card mapping. What this does is route all requests to ASP.Net. Even requests for static content such as images. This does have a negative effect on performance that you will want to measure. There are ways around this, I believe such as placing all your content in a specific virtual directory that you turn off the wild card mapping for, but I haven't fully explored that option.
I think the issue with IIS6 is extensionless URLs that you can easily achieve by adding a wildcard ISAPI map in IIS configuration.
So, no. While I love IIS7 integrated mode and strongly recommend using it, you won't lose functionality using it. I've deployed several ASP.NET MVC 1.0 projects on Windows Server 2003/IIS6.
Url rewriting can help you to solve the problem. I've implemented solution allowing to deploy MVC application at any IIS version even when virtual hosting is used.
http://www.codeproject.com/KB/aspnet/iis-aspnet-url-rewriting.aspx