Web Hosting Forum | Lunarpages

Author Topic: Installing/Supporting ASP.NET MVC  (Read 9236 times)

Offline webnelly

  • Space Explorer
  • ***
  • Posts: 7
Installing/Supporting ASP.NET MVC
« on: April 26, 2009, 11:10:41 AM »
Aloha,

I've been an existing Lunar Pages client for a little over 4 months on the LAMP side of the house, and have been pretty happy so far.  I've going through quite a few hosts in my day (last 8 years), so I do have something to go against.

While I've always developed my own (personal) sites on the LAMP platform, professionally I'm an MS developer.  I'm looking to sign up for my very first Windows hosting plan, but before I do I was wondering if Lunar Pages supports ASP.NET MVC which just went to a full release this month?  I've been working with it on my local development machine and at the office, but I don't have a lot of experience knowing what would be needed to install it on a shared hosting plan (rather than a machine I just remote into and have admin rights).

Does anyone know where I can find out before signing up for another account?

Also, anyone here given ASP.NET MVC (http://www.asp.net/mvc/) a try yet?  Interested to here your thoughts on it.

Thanks in advance,
- Kris

Offline Mitch

  • Berserker Poster
  • *****
  • Posts: 12641
    • MitchKeeler.com
Re: Installing/Supporting ASP.NET MVC
« Reply #1 on: April 27, 2009, 04:40:27 AM »
Unless you are willing to go to VPS or Dedicated, chances are this will not be support.  The server admins are a little nervous putting anything that is too new or untested on the shared hosting platform.  However, it could be that we do support it in the future.  If it is something you would like to see, please send the suggestion along to feedback@lunarpages.com.
New to Web Site Hosting? Check Out the Lunarpages Blog Hosting Guide!


Follow us @lunarpages on Twitter!
Important Threads: Read This Before Posting! | Lunarforums Rules! | Mitch's Link of the Day!
Also, be sure to check out and subscribe to the Lunartics Blog and the Lunarpages Newsletter !

Need Web Hosting Help? Check out the Lunarpages Web Hosting Wiki. It has tons of tips, tutorials and resources!

Offline webnelly

  • Space Explorer
  • ***
  • Posts: 7
Re: Installing/Supporting ASP.NET MVC
« Reply #2 on: April 27, 2009, 04:52:53 AM »
Thanks Mitch.

I might go ahead with the basic plan anyway since I believe the team behind the MVC stuff at MS has a few workarounds for getting this to work without the additional framework components installed (via edits to the Global.asax file in your application folder).  I haven't tried that part out in my local development yet, but if that works, I'll probably give it a shot and maybe wait patiently until it becomes more mainstream and comfortable for the admins.

If you had to guess based on your experience, would you say these types of new components typically takes 3, 9, or 18 months to be adopted here at LP?

Offline Mitch

  • Berserker Poster
  • *****
  • Posts: 12641
    • MitchKeeler.com
Re: Installing/Supporting ASP.NET MVC
« Reply #3 on: April 27, 2009, 04:58:42 AM »
It would be hard to put your finger on an exact time frame, due to the fact that you have to weigh in with user demand too. 
New to Web Site Hosting? Check Out the Lunarpages Blog Hosting Guide!


Follow us @lunarpages on Twitter!
Important Threads: Read This Before Posting! | Lunarforums Rules! | Mitch's Link of the Day!
Also, be sure to check out and subscribe to the Lunartics Blog and the Lunarpages Newsletter !

Need Web Hosting Help? Check out the Lunarpages Web Hosting Wiki. It has tons of tips, tutorials and resources!

Offline wrhighfield

  • Space Explorer
  • ***
  • Posts: 6
Re: Installing/Supporting ASP.NET MVC
« Reply #4 on: May 10, 2009, 10:41:55 AM »
Thanks Mitch.

I might go ahead with the basic plan anyway since I believe the team behind the MVC stuff at MS has a few workarounds for getting this to work without the additional framework components installed (via edits to the Global.asax file in your application folder).  I haven't tried that part out in my local development yet, but if that works, I'll probably give it a shot and maybe wait patiently until it becomes more mainstream and comfortable for the admins.

If you had to guess based on your experience, would you say these types of new components typically takes 3, 9, or 18 months to be adopted here at LP?
FYI: ASP.NET MVC works on Windows Hosting as I have been doing proof of concepts with it for a while now.  When you deploy the web site you will need to set the following assembly reference properties to Copy Local so that they will be pulled from the GAC and placed into your bin folder.

System.Web.Abstractions
System.Web.Routing
System.Web.Mvc

MWaqas

  • Guest
Re: Installing/Supporting ASP.NET MVC
« Reply #5 on: February 10, 2011, 06:13:30 AM »
Hello,

Yes, asp.net MVC was installed on a couple of servers; so partially yes its available  you will have to copy the following DLL files into your /bin/ directory


System.Web.Abstractions
System.Web.Routing
System.Web.Mvc

aaaah and as a final note please do make sure that IIS worker process user has full permissions on  your /bin/ directory if you dont know how to do that drop an email to the magical email address windows@lunarpages.com we will set the permissions for you.  :shades:

MWaqas

  • Guest
Re: Installing/Supporting ASP.NET MVC
« Reply #6 on: January 08, 2012, 09:51:49 PM »
Hello,

Yes, asp.net MVC was installed on a couple of servers; so partially yes its available  you will have to copy the following DLL files into your /bin/ directory


System.Web.Abstractions
System.Web.Routing
System.Web.Mvc

aaaah and as a final note please do make sure that IIS worker process user has full permissions on  your /bin/ directory if you dont know how to do that drop an email to the magical email address windows@lunarpages.com we will set the permissions for you.  :shades:


Moreover I tried MVC today myself and I can tell that Deploying ASP.NET MVC applications to IIS 6 always causes confusion at first. You’ve been coding in Visual Studio 2008, seeing your lovely clean URLs work nicely in the built-in web server, you stick the code on some Windows Server 2003 machine, and then wham! It’s all like 404 Not found  and you’re like hey dude that’s not cool. 
This happens because IIS 6 only invokes ASP.NET when it sees a “filename extension” in the URL that’s mapped to aspnet_isapi.dll (which is a C/C++ ISAPI filter responsible for invoking ASP.NET). Since routing is a .NET IHttpModule called UrlRoutingModule, it doesn’t get invoked unless ASP.NET itself gets invoked, which only happens when aspnet_isapi.dll gets invoked, which only happens when there’s a .aspx in the URL. So, no .aspx, no UrlRoutingModule, hence the 404.

I’d say you’ve got four ways around this:
Option 1: Use a wildcard mapping for aspnet_isapi.dll

This tells IIS 6 to process all requests using ASP.NET, so routing is always invoked, and there’s no problem. It’s dead easy to set up: open IIS manager, right-click your app, go to Properties, then Home Directory tab, then click Configuration. Under Wildcard application maps, click Insert (not Add, which is confusingly just above),  then enter C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll for “Executable”, and uncheck Verify that file exists.

Done! Routing now just behaves as it always did in VS2008′s built-in server.

Unfortunately, this also tells IIS to use ASP.NET to serve all requests, including for static files. It will work, because ASP.NET has a built-in DefaultHttpHandler that does it, but depending on what you do during the request, it might use StaticFileHandler to serve the request. StaticFileHandler is much less efficient than IIS natively. You see, it always reads the files from disk for every request, not caching them in memory. It doesn’t send Cache-Control headers that you might have configured in IIS, so browsers won’t cache it properly. It doesn’t do HTTP compression. However, if you can avoid interfering with the request, DefaultHttpHandler will pass control back to IIS for native processing, which is much better.

For small intranet applications, wildcard mappings are probably the best choice. Yes, it impacts performance slightly, but that might not be a problem for you. Perhaps you have better things to worry about.

For larger public internet applications, you may need a solution that delivers better performance.

Update: It turns out that you can disable wildcard maps on selected subfolders, which may give you the best of both worlds.

Option 2: Put .aspx in all your route entries’ URL patterns

If you don’t mind having .aspx in your URLs, just go through your routing config, adding .aspx before a forward-slash in each pattern. For example, use {controller}.aspx/{action}/{id} or myapp.aspx/{controller}/{action}/{id}. Don’t put .aspx inside the curly-bracket parameter names, or into the ‘default’ values, because it isn’t really part of the controller name – it’s just in the URL to satisfy IIS.

Now your application will be invoked just like a traditional ASP.NET app. IIS still handles static files. This is probably the easiest solution in shared hosting scenarios. Unfortunately, you’ve spoiled your otherwise clean URL schema.

Options 3: Use a custom filename extension in all your URL patterns

This is the same as the above, except substituting something like .mvc instead of .aspx. It doesn’t really create any advantage, other than showing off that you’re using ASP.NET MVC.

Just update your route entries as described above, except putting .mvc instead of .aspx. Next, register a new ISAPI mapping: Open IIS manager, right-click your app, go to Properties, then Home Directory tab, then click Configuration. On the Mappings tab, click Add, then enter C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll for “Executable”, .mvc (or whatever extension you’re using) for “Extension”, and uncheck Verify that file exists. Leave Script engine checked (unless your app has Execute permission) and leave All verbs selected unless you specifically want to filter HTTP methods.

That’s it – you’re now using a custom extension. Unfortunately, it’s still a bit of an eyesore on your otherwise clean URL schema.

 

Share |