Posts Tagged ‘ASP.NET’

ASP.NET Web Forms were launched as part of .NET Framework 1.0 in 2002. It was a logical evolution from ASP, moving away from interpreted web pages with dependency on a scripting engine, towards type safe and compiled web pages model with more well structured code. ASP.NET Web Forms offered developers with a event based programming model, which helped to create web applications quickly. But over time, we found certain limitations of this framework in developing and maintaining large web applications.This was mostly due to lesser control on the generated HTML , poor testability and an artificial/complex stateful model as opposed to the stateless nature of the web.

ASP.NET MVC was released around 2009 which was based on the Model-View-Controller architectural pattern leading to clean separation of concerns, improved testability and more tighter control on HTML. This was more in line with other popular frameworks of the time like Ruby-On-Rails etc.

However , both ASP.NET Web Forms and ASP.NET MVC were built on the same underlying framework and relied heavily on features provided by System.Web.dll. This assembly is a part of the .NET Framework and explicitly coupled with Windows Web Server i.e. Internet Information Services., IIS. Also, the heavy dependency on this assembly made changes to ASP.NET complex and release cycles slow.

The key goals of ASP.NET Core was to make the framework cross platform and the overall architecture more modular. So, clean separation of the web server from the web application was key. The figure below shows the key components of the ASP.NET Core request processing pipeline and how this separation is achieved.

Every ASP.NET Core application runs within an in-process HTTP Server implementation. This HTTP Server receives the raw HTTP request and converts it to an internal representation by creating a HttpContext object. This object is then used by the web application for further processing.Kestrel is a cross platform web server built on libuv , asynchronous request processing library. This is the default HTTP Server implementation for all ASP.NET Core applications.

Kestrel is a very basic HTTP server and does not have advanced features like

Windows Authentication

Port sharing

Http Access Logs

Process Activation

Response Caching etc.

This is why its recommended to use the ASP.NET Core Web Server with a reverse proxy. A reverse proxy is a web server exposed directly to the Internet and responsible for forwarding the requests to the appropriate web servers serving the requests. A web server like IIS , Nginx or Apache can be easily configured as a reverse proxy working in conjunction with the ASP.NET Core Web Server.

This model of having a separate reverse proxy and a web server might sound bit cumbersome. But this helps in making the web application framework independent of the operating system and web servers like IIS, Nginx or Apache. This results in a clean separation of concerns with a lightweight HTTP server handling requests / generating responses while the reverse proxy doing rest of the heavy lifting like security related hardening , application start-up etc.

An ASP.NET Core web application cannot be directly hosted in IIS / Nginx / Apache without a server like Kestrel or any custom ASP.NET Core Http Server implementation. This is because ASP.NET Core is designed to run independent of this servers, ASP.NET Core is not meant to adapt to these servers but these servers needs to be configured to act as a reverse proxy and forward request to the ASP.NET Core Web Server.

IIS works as a reverse proxy , forwarding requests to ASP.NET Core using the ASP.NET Core Module ( ANCM). This is a native IIS module which hooks in the request pipeline ,activates the ASP.NET Core process and forwards the request to the ASP.NET Core Web Server. The IIS worker process ( w3wp.exe) and ASP.NET Core runs as two separate processes , ANCM is responsible for restarting in case the ASP.NET Core application crashes.

There is another option for ASP.NET Core Web Server, HTTP.sys.This is Windows only HTTP Server implementation based on HTTP.sys kernel mode driver. However it has some advanced built in features compared to Kestrel like support for Windows Authentication , Port sharing , response caching etc.HTTP.sys kernel driver is a very advanced technology and IIS itself runs on top of it. So this HTTP Server is protected against security attacks etc. and is suitable for running without a reverse proxy for internet facing applications. For intranet applications also this can be good choice given its support for Windows Authentication.

Those who have been working in ASP.NET MVC are already aware of the ASP.NET Routing feature introduced with .NET 3.5 SP1.But I have seen many who has developed a perception that ASP.NET Routing is something that can be used with only ASP.NET MVC.This is not the case.ASP.NET Routing comes under a separate namespace (System.Web.Routing) and assembly (System.Web.Routing.dll).This can be used with WebForms applications as well.But this required some custom coding to develop your RouteHandler as shown in the post below:

In ASP.NET 4.0, added capabilities are provided to make routing fully complete in order to work with WebForms.This is what I will be discussing in this post today.I will use simple webpage with 2 hyperlinks to demonstrate this feature.

For the past few days I faced strange problems while implementing ASP.NET AJAX UpdatePanel in an application running on framework 3.5.The same page was using ASP.NET AjAX ScriptService perfectly fine.On examining the HTML source of the page I found that the markup and <script> tags required for proper functioning of ASP.NET Ajax was not emitted at all.This application was actually migrated from 1.1 to 3.5 using the application migration wizard.While migrating the application the wizard adds the following lines of code web.config

<system.web><xhtmlConformance mode=”Legacy”/>
</system.web>
This was the main culprit.The markup emitted by framework 1.1 is not XHTML compliant.So to maintain compatibility the xhtnmlConformance mode is set to Legacy.The other two values are “Strict” and “Transitional”.ASP.NET AJAX UpdatePanel does not work properly with XHTML Conformance mode legacy.Changing the mode to Strict or Transitional was causing distortion and javascript related issues.In legacy mode the id of the server controls is rendered as UserControlID:ControlID whereas in mode Strict or Transitional it is rendered as UserControlID$ControlID.

So we evaluated the option of setting XHTML conformance mode to Legacy for the existing folders and Transitional or Strict for the folder containing new web pages using the <location> tag in Web.config.This also did not workout as the application uses FrontController pattern for page to page and menu navigation.So all the requests are first send to the frontconroller and then to individual pages using Server.Transfer.As the requests are not directly routed to pages in the new folder XHTML conformance mode was not changed.

So we added another aspx pointing to the same httpHandler and manipulated the location tag as follows: