I am not clear that what is the purpose of running asp.net application in IIS. Why we go for IIS. Any difference amoung running in VS and IIS?
Please suggest me.
Simply because you won't run asp.net in VS on production !
IIS Express and the VS Development Server are designed to emulate IIS, but they are configured differently and may fail to reveal errors that can occur when you deploy to a production version of IIS.
Visual Studio Development Server, also known as Cassini, is very limited. It does not have all IIS features and we will have a few problems when resolving References to Root-Level Resources or on security.
For example, when you run a page using IIS Express/VS Development Server, the page runs in the context of your current user account (often Admin). In IIS 7, by default ASP.NET runs in an account that has limited privileges (know as AppPool Identity, see here). This difference can be a source of problems when you deploy on production a web application.
A complete list of Hosting options is available here.
Internet Information Services (IIS) for Windows® Server is a flexible, secure and manageable Web server for hosting anything on the Web. From media streaming to web applications, IIS's scalable and open architecture is ready to handle the most demanding tasks.
Application pools allow you to isolate your applications from one another, even if they are running on the same server. This way, if there is an error in one app, it won't take down other applications.
Additionally, applications pools allow you to seperate different apps which require different levels of security.
Here's a good resource: http://www.advancedinstaller.com/user-guide/tutorial-iis.html
http://www.iis.net/learn
Related
I've seen a web application running by Classic App Pool with Network Service identity. What should be the reason behind? what issue we face if use Local System/Local Service or other.
Please share your knowledge if anyone knows.
IIS 4.x/5.x used to use Local System/Local Service as default identity for IIS processes, which became a system-wide risk, as web servers like IIS can be hacked. Once hacked, malicious code would be executed under those powerful accounts to hack the whole Windows machine, and possible other resources in the same domain.
Thus, when Microsoft designed IIS 6, they switched to Network Service, which has significantly less permissions than the old options. Further on in IIS 7 and above, Microsoft introduced Application Pool Identities accounts to reduce more permissions. That's what #mason commented as "the principle of least privilege".
However, the whole IIS security story does not end here. Concepts such as DMZ and so on would bring more security to your web environment, which you should spend some time learning via specific materials (IIS security books and so on), not simply via a web forum.
What is the kestrel web server and how does it relate to IIS / IIS Express?
I come from developing apps on IIS Express and hosting them on an IIS web server. With ASP.NET Core I have a dependency on Microsoft.AspNetCore.Server.Kestrel and my startup has .UseServer("Microsoft.AspNetCore.Server.Kestrel"). But when I run my website, I still get the IIS Express icon in the system tray. Someone asked me if I was using IIS Express or Kestrel and I didn't know what to say!
I don't have any cross-platform requirements as I develop on a PC and host in Azure, so I'm confused if I even need Kestrel, but it doesn't seem like there's an alternative - even the simplest samples use Kestrel.
I'd like to offer an alternative answer, with some history, so that you might understand why Kestrel comes, even if you only use Windows and IIS.
At the very beginning of ASP.NET development before year 2000, clearly Microsoft created two pieces to host ASP.NET WebForms apps,
Cassini, later became ASP.NET Development Server in Visual Studio. It is a fully managed web server written in C# based on HttpListener. Of course, since it was for development only, many features were never implemented. As Microsoft made the source code of Cassini available for the public, there are third parties who forked the code base and added more features, which started the Cassini family.
ASP.NET support on IIS (revision 1). Because IIS was 4.0 and 5.0/5.1 at that time, which has nothing like application pools, ASP.NET even has its own worker process (aspnet_wp.exe).
So to develop a web app, you use Cassini, and to deploy you use IIS.
The introduction of application pools in IIS 6 required some changes on ASP.NET side, so aspnet_wp.exe became obsolete and replaced by aspnet_isapi.dll. That can be seen as ASP.NET support on IIS revision 2. So ASP.NET apps are being hosted in IIS worker processes w3wp.exe.
The introduction of integrated pipeline in IIS 7 and above required further changes, which replaced aspnet_isapi.dll with webengine4.dll. That can be seen as ASP.NET support on IIS revision 3. ASP.NET and IIS pipelines are unified.
You can see ASP.NET has become much more complex and tightly integrated with IIS, so Cassini started to show its age, and gradually was replaced by IIS Express (a user mode lite IIS).
Thus, in many cases, when people blame that IIS is slow, they should blame ASP.NET in fact. IIS itself without ASP.NET is pretty fast and stable, while ASP.NET was not developed with enough performance metrics in mind (as WebForms focuses quite a lot of productivities and RAD).
Then in November 2014, ASP.NET 5 (later renamed to ASP.NET Core) was announced and became a cross platform technology. Obviously Microsoft needed a new design to support Windows, macOS, and Linux, where all major web servers, nginx/Apache (or other web servers) should be considered besides IIS.
I think many would agree that Microsoft learned quite a lot from NodeJS, and then designed and developed Kestrel (based on libuv initially but might move to other technology soon). It is a light-weight web server like Cassini initially, but later more features are being added (like another answer commented, much more features so can be treated as a full web server). Though fully managed (some native dependencies exist), it is no longer a toy web server like Cassini.
Then why cannot you just use Kestrel? Why IIS Express and potentially IIS, nginx, or Apache are still needed? That primarily is a result of today's internet practice. Most web sites use reverse proxies to take requests from your web browsers and then forward to the application servers in the background.
IIS Express/IIS/nginx/Apache are the reverse proxy servers
Kestrel/NodeJS/Tomcat and so on are the application servers
Another answer already showed a link to Microsoft documentation, so you can take a look.
Microsoft developed HttpPlatformHandler initially to make IIS a good enough reverse proxy for Java/Python and so on, so planned to use it for ASP.NET Core. Issues started to appear during development, so later Microsoft made ASP.NET Core Module specifically for ASP.NET Core. That's ASP.NET support on IIS revision 4.
Starting from ASP.NET Core 2.2, ASP.NET Core Module for IIS (version 2) can host .NET Core environment inside IIS worker process (w3wp.exe), quite similar to ASP.NET 2.x/4.x. This mode is called "IIS in-process hosting". It can be considered as ASP.NET support on IIS revision 5.
Well, quite lengthy, but I hope I put all necessary pieces together and you enjoy reading it.
One recent update (Jan 2023) is that ASP.NET Core/Kestrel can be used to host reverse proxy functionalities itself, as the open source YARP project revealed.
Kestrel/YARP is now widely used inside Microsoft Azure to replace IIS ARR in many scenarios as reported, so literally now you can host your own production web apps with Kestrel/YARP without any other web server (IIS/nginx/Apache) in front as well.
What is Kestrel
It's a full blown web server. You can run your ASP.NET Core application using just Kestrel.
But when I run my website, I still get the IIS Express icon in the system tray
In your ASP.NET application, probably in the wwwroot directory, you'll see a web.config that contains this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<handlers>
<add name="httpPlatformHandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified"/>
</handlers>
<httpPlatform processPath="%DNX_PATH%" arguments="%DNX_ARGS%" stdoutLogEnabled="false" startupTimeLimit="3600"/>
</system.webServer>
</configuration>
This is the HttpPlatformHandler. Essentially, what this does is forward all requests to Kestrel. IIS Express (and IIS for that matter) will not run ASP.NET themselves anymore. Instead, they will act as proxies that simply pass requests and responses back and forth from Kestrel. There is still advantages of using IIS, specifically it gives you security configuration, kernel-level caching, etc.
From ms docs at:
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?tabs=aspnetcore2x
Kestrel is a cross-platform web server for ASP.NET Core based on
libuv, a cross-platform asynchronous I/O library. Kestrel is the web
server that is included by default in ASP.NET Core project templates.
You can use Kestrel by itself or with a reverse proxy server, such as
IIS, Nginx, or Apache. A reverse proxy server receives HTTP requests
from the Internet and forwards them to Kestrel after some preliminary
handling.
UPDATE: .net core 2.1, Kestrel uses managed sockets instead of libuv
From asp.net core 2.1 docs at: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-2.1#transport-configuration
With the release of ASP.NET Core 2.1, Kestrel's default transport is
no longer based on Libuv but instead based on managed sockets.
Multiple apps on the same port is not supported in Kestrel.
Windows Authentication does not exist on Kestrel.
Request Filtering is much more fully featured in IIS.
Mime Type Mapping is much better in IIS.
HTTP access logs aren’t collected in Kestrel.
We have a simple Visual Studio solution containing 2 projects:
A.) Simple ASP.Net website
B.) RESTful web service hosted in another ASP.Net application
We want to simply start the projects in Debug mode (F5) and have A consume data from B through Ajax. We do not have the possibility to configure IIS on all development machines (because some of them are on the client's side). The problem might be that JavaScript needs to be in the same domain as the URL it posts to.
Is there any way we can use Visual Studio 2010 Development Server to start both applications simultaneously in debug mode on the same port?
If this is not possible, what is the next best thing you can recommend?
We solved this problem by installing IIS on the development workstation.
In each Visual Studio project, on the Web property page, select Use Local IIS Web server.
Do not check Use IIS Express. The Project URLs will be set to http:localhost/<projectname> (note: in the same domain). You’ll be prompted to Create a Virtual Directory for each. Each will be assigned to the default IIS app pool. Open the Internet Information Services (IIS) Manager. Click Application Pools on the left pane. On the right pane add another integrated application pool. For one of the applications, open the Advanced Settings... In the properties view select the app pool you just created as the application pool. The applications should be debuggable in parallel because each Application Pool spawns a new operating system process to which a separate debugger can be attached.
Yo won't be able to host different apps on the same port within a Cassini instance, there are tools that might be useful but I would leave Cassini host them on different ports which is its regular behavior.
Options are (not tested):
UltiDev
Cassini Extesion
By the way, not sure if you know this, but to start both projects go to Set startup projects, there's an option on the Solution context menu.
We have a desktop client application and recent customer requests indicate that they would like to have some dynamic HTML content served and displayed by the application.
We are considering hosting a simple ASP.NET application in a local process, accessible only from the local machine (similar to the ASP.NET development web server used when debugging from Visual Studio).
How can we run an ASP.NET application locally without IIS? IIS is not an option because most client machines will not have it installed.
Is there a leightweight ASP.NET web server that could run locally similar to the development web server that VS is using?
I have found some information about "Cassini". Is this suitable for production use? Can it handle ASP.NET MVC? Are there any alternatives we should consider?
I have not used it myself, but you can try the mono XPS server.
It is a stand alone webserver.
The easiest way to start XSP is to run it from within the root directory of your application. It will serve requests on port 8080. Place additional assemblies in the bin directory.
Cassini is in fact also a good option - it is the development web server that comes with visual studio (so widely distributed, used and tested) and is also used by the open source ScrewTurnWiki. See wikipedia.
In regards to your "only locally" requirement - a web server will serve any request made to the right port. In order to limit accessibility, you should use a firewall that will block any external requests.
You might consider using WCF to host a service on the local machine that can serve the data without having to host a full blown web server.
If you do this, WCF allows you to expose the service with multiple endpoints and make it available through HTTP, TCP, or Namepipes. Namepipes would restrict traffic to only the local machine.
I have also tried IIS Express. It works great with ASP.NET MVC. Right now it is available only with Web Matrix, but installing web matrix is easy.
Coming back to this question three years later, ServiceStack.NET with self-hosted option seems like a good choice. While it is not ASP.NET MVC directly, it provides a good API and features are on par with ASP.NET MVC/WebAPI (or in some ways better).
Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.