How can I let web users create a subdomain on the fly for Windows Server 2008 for my website?
My application is in MVC 1.0 and ASP.Net 3.5 with C#.
Take a look at this... http://blog.maartenballiauw.be/post/2009/05/20/ASPNET-MVC-Domain-Routing.aspx
The most common way (in terms of theory) is to map *.domain.ext to your one web-application. It itself parses the request to see which subdomain is being used and therefore which "site" to show.
In practice, I'm not sure how simple this is with IIS or ASP.NET. When I still used ASP.NET, I used UrlRewritingNet.UrlRewrite. It was light-years ahead of the competition two years ago, and it still looks a pretty handy thing to have in a fight now.
If you just want to map wildcard you do that in IIS (and in the DNS), then you can parse the requested url to get the subdomain. Otherwise Clarify the question.
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 developing an ASP.Net MVC application in C#, and it is hosted in an IIS server. Right now the client asked me to have a CMS on the same app url, that will be used to serve the public pages.
I have looked for ASP.Net MVC CMS apps and could not find anything that would be easily integrated with the current application, so I choose to do it by changing the server configuration.
What I need is:
Custom App:
exampleappurl.com/User
exampleappurl.com/Company
etc
CMS:
Any other URL, including "index" (exampleappurl.com)
Can I do it using any kind of Rewrite rule? Or IIS configuration? What is the best solution?
Thanks in advance!
On IIS6, there is a feature called 'host headers', that does exactly this: several websites may share the port 80, and the request goes to one of the sites its URL points to.
http://www.it-notebook.org/iis/article/understanding_host_headers.htm
http://technet.microsoft.com/en-us/library/cc753195(v=ws.10).aspx (this one is about IIS 7)
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 CRUD application written in Classic ASP (not .net) which transfers (routes) page requests to relevant servers using a loadbalancer DLL.
It works like this:
Someone requests for www.mywebsite.com/products
There is an index.asp under folder products that redirects the request to either:
http://www1.mywebsite.com/products
or
http://www2.mywebsite.com/products
based on a loadbalancer logic.
Another scenario:
Someone requests for www.mywebsite.com/products/details
There is a index.asp under the sub folder details within the products folder that redirects the request to either:
http://www1.mywebsite.com/products/details
or
http://www2.mywebsite.com/products/details
based on loadbalancer logic
The main issue with application is whenever I include a new page, I need to create a folder and index.asp page to redirect the page.
We have a CMS database which contains the details of all pages. So I want to create an MVC application to replace the existing Classic ASP application.
But I didn't find any database driven MVC applications and I'm bit confused by routing. Do I need to create a separate route for each main folder I have or should I create a generic route for all pages.
Any help would be appreciated.
You don't have to migrate to ASP.NET MVC just for the URL rewriting.
IIS 7 does have an integrated URL rewrite module and ASP.NET 4 includes routing as well.
IIS URL Rewriting and ASP.NET Routing
URL Rewriting in ASP.NET
Anyhow, if you search e.g. on Codeplex for ASP.NET MVC projects, you'll find a lot of them which are database driven.
You don't need to create individual routes for each seperate item. Think about the concept of querystrings (?id=15&day=monday). URL rewriting is pretty much the same.
Update
I've overseen that your talking about classic ASP.
The build in URL rewrite module in IIS 7 works also fine with classic ASP. If you are having an older IIS version you need a 3rd party ISAPI rewrite module.
Anyhow, switch it to ASP.NET MVC ;)
MVC would lend itself very well to sorting your routing problem. So would ASP.NET 4.
However, the problem you have is that you don't know enough to ask a precise question. Hence your confusion with routing in MVC.
I would therefore suggest reading the nerddinners tutorial. You can get a PDF download for free. To go a step further, read Stephen Sandersons book on MVC 2 (or MVC3 in a couple of months).
If you follow the nerddinners tutorial and Stephen Sanderson's tutorial, that will give you a better idea of how it works.
In short, this is how MVC works:
In MVC, you forget about files and folders.
Instead, you have Controllers and actions. The routes map the requests to the right controller and action.
The code in the actions then decide which View to stuff full of data (from a database or wherever, it doesn't matter). The Views are just templates that are told what to do and what data to display.
The Controllers ask the Model for the data that they want.
Ie, the data access is all done in the Model, neatly separated from the User Interface.
M: Model
V: Views
C: Controller
The above is probably meaningless to you. It is a VERY different mindset to ASP classic.
If you are coming from old ASP, you will have a long hike, but it can be done. I came from Access. Anyway, read the books, follow the tutorial and see if it is for you.
When you are ready, we will still be here to help with more precise questions.
Asp.net MVC routing in your migrated application
Based on requests you've shown here you can sort everything up with just default route:
{controller}/{action}/{id}
In your case you'd have a ProductsController with all the actions you need.
Load balancing application
But having an Asp.net MVC application is just one part. This application will run on both load balanced servers. All redirecting should be done before they hit the MVC application.
If you intend to continue using the same loadbalancer DLL you could create a different Asp.net MVC application with only one route definition:
{*path}
and a single controller and action that does it all:
public Load: Controller
{
public ActionResult Balance(path)
{
// decide for web server and attach path to subdomain
}
}
This should do the trick just fine as long as the overhead of this action is very small. Otherwise your load balancing logic will become the bottleneck of your application since all requests go through this load balancer (it does that now as well so bare in mind this is no different now; never mind the authentication process on different subdomains you may be using).
Load balancing alternative
You should consider using the web farm balancing capabilities on the IIS 7 that will run your application on several web servers (because that's what your load balancing does in the first place). Search the web for web farm information. You can start with this:
http://www.iis.net/download/webfarmframework
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