I have a number of web apps running on several IIS6/Server 2003 boxes. They run well and are happy. They are all asp.net web apps and use .NET 3.5.
What, if any, would be valid reasons for contemplating moving the web apps to IIS7/Server 2008?
IIS7 is rewritten from the ground up with a concept of being "pluggable". IIS7 is more extensible than it ever has been before. The entire request pipeline has be reworked to allow you to more easily work with requests, as well.
From a performance aspect, these changes are immediately recognizable. You can run sites developed for IIS6 in a "Classic" application pool that will preserve compatibility, but provide a noticeable performance boost. In the non-scientific evaluation that we have done so far, our legacy application has seen about a 20% reduction of load times on our IIS7 test machine.
Of course, the reason we have to run in "classic" mode is an interesting side note. Inside the global.asax, there is some pre-fetching on application start which touches the HttpContext. Specifically, there is pre-caching done, which IIS7 does not allow. So, before we can switch from "classic" mode, there are some changes that we will have to make.
Eventually, Microsoft will discontinue Server 2003 support. Admittedly, that won't be for several years, so it doesn't impact you today.
Improved support for ASP.NET MVC. This is probably the big one for most of us. You can get ASP.NET MVC working on IIS6, but there are some hoops to jump through.
I'd give you more, but I myself am not yet on Server 2008 yet, and have nothing else to give. Presumably Vista (which I do use, both at work and at home) has the "same" IIS7 as 2008 does -- the UIs certainly look very similar -- but I wouldn't consider my experience there to be useful to your question.
Ability to write pipeline components in managed langauges. Previously, if you wanted to write an ISAPI filter to handle a certain type of web request, you'd have to write it in C++. Now, you can use good ol' .NET code. This allows more customization with the ability to write reusable pipeline components for handling various types of request. For example, all .js file request are routed to a ScriptCompressor pipeline component which zips and returns them with lots of cacheability set up.
The improved support for MVC is linked to this as you can set II7 to route requests without extensions to .NET so you can have urls which are "cleaner" such as http://www.yourwebsite.com/customer/1 without having any extension visible which reveals what type of server technology you're using and is very untrendy these days.
Related
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
I am looking to build a small ASP.NET application using WebAPI and a html front-end, on .NET 4.0. I need to support authentication, authorization, data access (EF), logging / tracing. It can be an intranet/internet application, so it should support load balancing / clustering.
I am sure if I just go with ASP.NET and IIS I will get all these features. However I like OWINs idea of independent async modules and its goal of being high performance hosting environment. But how much of OWIN/ KATANA is matured and what functionalities are still missing/buggy?
The whole idea of Owin/Katana is to build a light weight server with only the function we need. Your question is better to be "What are things missing in Owin/Katana, which is available in IIS?"
The short answer is, IIS is a full-blown server. Many of the websites we developed only requires a small fraction of all its functions. It is like shipping a bag of grocery using an 18 wheeler.
If you look at Katana, all functions are modular. Say, if I need WebAPI, I can add in that function. When CORS is needed, I will extend appBuilder to the related functions. So in a sense, we have a fully customizable server. Since all functions can be added in, I would say nothing is missing.
Another thing to mention is that an installation of IIS would require you to run a Windows Server. If you are on a Mac or not a server version of Windows, you can host your website on Katana or any other OWIN implementation.
I have a need to run an application in classic mode for backwards compatibility with a specific application, and am trying to understand what kind of impact that will have on the performance of an MVC application that is running on the site.
If we put a few static file maps (for .js, .css, .png, etc) above the ASP.NET wildcard map to reduce the amount of processing by the ASP.NET handler, will we be approaching the integrated mode in terms of performance?
The thing i'm primarily concerned with is any effect this might have on output caching. I understand that integrated mode might (?) allow for the output cache to handle non ASP.NET content, but that isn't really a concern. We're more interested in ensuring that the MVC application has full use of the output cache.
Empirically i've found that the two configurations operate on par when things go well, but if the page references resources that are not available, the integrated mode tends to fail much more quickly than the classic mode (e.g. 500 ms vs 10 seconds), reducing 'hang time' on the page load.
Thanks for any feedback.
The thing is you have told IIS to run a particular application in classic mode. Now sit back and see. I should do it.
I don't think if you are running only one application on classic mode, it should affect another application running on integrated mode.
I'm trying to start on a new project to help enrich my asp.net knowledge, since I'm not completely satisfied with what my class is teaching me. From my (very little) experience with Rails, I recall every application containing its own development web server. Say I were trying to create a local-only application, but I want it to run in a web browser (Therefore ASP.Net). Are there any options in terms of being able to distribute an application and have it launch its own, or just not require IIS/VS/Apache-mono?
You may want to look into aspNETserve. It sounds like it would fit your needs. I haven't worked on it recently, so it probably has some rough edges.
On the plus side its all open source, and if you are just getting started with ASP.NET it would be a real eye opener on how the internals of the ASP.NET lifecycle operate.
The simple answer is that you need a web server to run the application. It cannot run without one.
If we're talking demo purposes or you don't require that many features of a web server there are redistributable web-servers that you can include with your setup package.
Like Alex mentioned the most popular one seems to be Cassini.
I'm assuming that you want to run the site on the same machine you are developing it on.
Visual Studio 2005 and up allows you to run the site from VS itself if you want to view it locally on your development machine.
To my understanding Visual Web Developer allows you to do the same as well.
Visual Web Developer
You can use the cassini web server. Please note that those are different redistributable:
http://www.asp.net/Downloads/archived/cassini/
http://ultidev.com/products/Cassini/
I'm not really certain why you would want to develop a web application (with all the difficulties it entails, due to the fact that you are dealing with a stateless connection to an unknown client machine), but then run the entire thing on the client machine.
Surely it makes more sense to develop a WinForms application?
Follow this guide to setup IIS on your PC to run ASP.NET apps:
http://www.geekpedia.com/tutorial25_Setting-up-your-ASPNET-server-IIS.html
I am a junior developer, doing my last year at college. I'm mostly asp.net oriented and even have a part time job coding in that language. I am interested on converting to linux and since visual studio is unsupported write my code in Mono.
Are there any notable limitations in Mono that I should be aware of (regarding ASP.NET)?
According to the Mono website:
Mono's ASP.Net does not implement the
following features:
Precompiled Websites
Webparts APIs.
Also most if not all 3rd party ASP.Net controls are not compatible with Mono unless otherwise specified. ComponentArt controls for example are not usable in Mono. However, there's no reason to think that this won't change as Mono gains popularity. ComponentArts has already mentioned that they are considering adding support in the future.
I'd say the biggest thing you lose is IIS. ASP.net and IIS were very deeply linked. Many of the advantages from ASP.net come from the utilization of hosting features in IIS. The biggest one I can name is the ability of HTTP.sys to directly respond to a request in kernel mode if the page is in cache. This means that the socket open is responded to immediately and can allow for orders of magnitude more hits to your webserver.
Its a bit of an edge case but Microsoft's Web Service Enhancements are not supported on Mono. I ran into this problem trying to get some WSE services working on Mono.
Regarding web services there are two very good open-source alternatives: ServiceStack.Net (using it) and NANCY.
These area a lot easier implement, use and maintain, IMHO, than services built on top of WCF.