ASP.NET Interview Questions and Answers

ViewData contains the key, value pairs as dictionary and this is derived from class ViewDataDictionary . In action method we are setting the value for viewdata and in view the value will be fetched by typecasting.

With ASP.NET Core 2 several new features came out: Razor Pages DbContext Pooling with Entity Framework Core 2 Simplified Application Host Configuration Configuration is now part of DI and ready for the time server reaches Startup class Simplified authentication model dotnet new now restore NuGet packages automatically New meta package – Microsoft.AspNetCore.All

This is a general term that conveys a general philosophy, similar to the term REST (Representational State Transfer). Unobtrusive JavaScript doesn’t intermix JavaScript code in your page markup. Eg : Instead of using events like onclick and onsubmit, the unobtrusive JavaScript attaches to elements by their ID or class based on the HTML5 data- attributes.

JavaScript Object Notation (JSON) binding support started from MVC3 onwards via the JsonValueProviderFactory , which allows the action methods to accept and model-bind data in JSON format. This is useful in Ajax scenarios like client templates and data binding that need to post data back to the server.

ActionResult is used to represent the action method result. Below are the subtypes of ActionResult:

ViewResult PartialViewResult RedirectToRouteResult RedirectResult JavascriptResult JSONResult FileResult HTTPStatusCodeResult

After the Init() and before the Page_Load() .

In Server.Transfer page processing transfers from one page to the other page without making a round-trip back to the client's browser. This provides a faster response with a little less overhead on the server. The clients url history list or current url Server does not update in case of Server.Transfer. Response.Redirect is used to redirect the user's browser to another page or site. It performs trip back to the client where the client's browser is redirected to the new page. The user's browser history list is updated to reflect the new address.

ASP.NET has 3 kinds of caching :

1. Output Caching,
2. Fragment Caching,
3. Data Caching.

We can SetNoStore on HttpCachePolicy object exposed by the Response object's Cache property:

Response.Cache.SetNoStore();
Response.Write(DateTime.Now.ToLongTimeString ());

Client-Side Validation: When validation is done on the client browser, then it is known as Client-Side Validation. We use JavaScript to do the Client-Side Validation.

**Server-Side Validation: ** When validation occurs on the server, then it is known as Server-Side Validation.

Server-Side Validation is a secure form of validation. The main advantage of Server-Side Validation is if the user somehow bypasses the Client-Side Validation, we can still catch the problem on server-side.

.NET Core is a runtime. It can execute applications that are built for it. ASP.NET Core is a collection of libraries that form a Framework for building web applications. ASP.NET Core libraries can be used on both .NET Core and the "Full .NET Framework" (what has shipped with windows for many years).

Middleware is actually sequential series of delegates (piece of code), that can either short-circuit or pass on the HTTP request to next delegate. These are known as middleware, a concept well known to people who worked with Node.js. Piece of your middleware can do one of the following: Handle an incoming HTTP request by generating an HTTP response (maybe your authentication or authorization middleware will stop the request early and immediately create response) Process the incoming request, change it and pass it to the next middleware in the pipeline Process the outgoing response, change it and pass it on to next middleware in the pipeline or directly to the ASP.NET Core web server

ViewState is stored in a hidden field on the page at client side. ViewState is transported to the client and back to the server, and is not stored on the server or any other external source.

1. Page_PreInit
2. Page_Init
3. Page_InitComplete
4. Page_PreLoad
5. Page_Load
6. Page_LoadComplete
7. Page_PreRender
8. Render

View state is a kind of hash map (or at least you can think of it that way) that ASP.NET uses to store all the temporary information about a page - like what options are currently chosen in each select box, what values are there in each text box, which panel are open, etc. You can also use it to store any arbitrary information. The entire map is serialized and encoded and kept in a hidden variable (__VIEWSTATE form field) that's posted back to the server whenever you take any action on the page that requires a server round trip. This is how you can access the values on the controls from the server code. If you change any value in the server code, that change is made in the view state and sent back to the browser. Just be careful about how much information you store in the view state, though... it can quickly become bloated and slow to transfer each time to the server and back. It's not encrypted at all. Just base encoded, which easily reversible.

**Dependency Injection **comes as a part of ASP.NET Core Framework and everything is built around it. When

you want to use some tool and its services, you usually add the NuGet package and you use one of its extension methods to add the package to the ASP.NET Core’s DI container. You can extend the current DI with a container of your choice (AutoFac, StructureMap, CastleWindsor etc).

Scoped lifetime actually means that within a created “scope” objects will be the same instance. It just so happens that within .Net Core, it wraps a request within a “scope”, but you can actually create scopes manually. For example : Consider:

public void ConfigureServices(IServiceCollection services)
{
  services.AddScoped<IMyScopedService, MyScopedService>();
  var serviceProvider = services.BuildServiceProvider();
  var serviceScopeFactory = serviceProvider.GetRequiredService<IServiceScopeFactory>();
  IMyScopedService scopedOne;
  IMyScopedService scopedTwo;
  using (var scope = serviceScopeFactory.CreateScope())
  {
    scopedOne = scope.ServiceProvider.GetService<IMyScopedService>();
  }
using (var scope = serviceScopeFactory.CreateScope())
{
  scopedTwo = scope.ServiceProvider.GetService<IMyScopedService>();
}
Debug.Assert(scopedOne != scopedTwo);
}

In this example, the two scoped objects aren’t the same because created each object within their own scope.

The options pattern uses classes to provide strongly typed access to groups of related settings. When configuration settings are isolated by scenario into separate classes, the app adheres to two important software engineering principles: The Interface Segregation Principle (ISP) or Encapsulation: Scenarios (classes) that depend on configuration settings depend only on the configuration settings that they use. Separation of Concerns: Settings for different parts of the app aren't dependent or coupled to one another.

Repository Layer gives you additional level of abstraction over data access. Service Layer exposes business logic, which uses repository or a set of repositories as UnitOfWork In ASP.NET MVC + EF + SQL Server, I have this flow of communication: Views <- Controllers -> Service layer -> Repository layer -> EF -> SQL Server Service layer -> Repository layer -> EF This part operates on models. Views <- Controllers -> Service layer This part operates on view models.

You should certainly not use Task.Run / StartNew / LongRunning - that approach has always been wrong. Note that your long-running work may be shut down at any time, and that's normal. If you need a more reliable solution, then you should have a separate background system outside of ASP.NET (e.g., Azure functions / AWS lambdas). Since .NET Core 2.0, the framework provides a new interface named IHostedService helping you to easily implement hosted services. Hosted Services are services/logic that you host within your host/application/microservice. The IHostedService background task execution is coordinated with the lifetime of the application. When you register an IHostedService , .NET will call the StartAsync() and StopAsync() methods of your IHostedService type during application start and stop respectively.

Since .NET Core 2.0, the framework provides a new interface named IHostedService helping you to easily implement hosted services. The basic idea is that you can register multiple background tasks (hosted services) that run in the background while your web host or host is running. Since most background tasks will have similar needs in regard to the cancellation tokens management and other typical operations, there is a convenient abstract base class you can derive from, named BackgroundService (available since .NET Core 2.1). Consider the following simplified code which is polling a database and publishing integration events into the Event Bus when needed. public class GracePeriodManagerService : BackgroundService

{
  private readonly ILogger<GracePeriodManagerService> _logger;
  private readonly OrderingBackgroundSettings _settings;
  private readonly IEventBus _eventBus;
  public GracePeriodManagerService(IOptions<OrderingBackgroundSettings> settings,

  IEventBus eventBus,
  ILogger<GracePeriodManagerService> logger)
  {
    // Constructor's parameters validations...
  }
protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
  _logger.LogDebug($"GracePeriodManagerService is starting.");
  stoppingToken.Register(() =>
  _logger.LogDebug($" GracePeriod background task is stopping."));
  while (!stoppingToken.IsCancellationRequested)
  {
    _logger.LogDebug($"GracePeriod task doing background work.");
    // This eShopOnContainers method is querying a database table
    // and publishing events into the Event Bus (RabbitMQ / ServiceBus)
    CheckConfirmedGracePeriodOrders();
    await Task.Delay(_settings.CheckUpdateTime, stoppingToken);
  }
_logger.LogDebug($"GracePeriod background task is stopping.");
}
.../...
}

Classic mode (the only mode in IIS6 and below) is a mode where IIS only works with ISAPI extensions and ISAPI filters directly. In this mode, ASP.NET is not much different from PHP or other technologies for IIS. This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Integrated mode, on the other hand, is a new mode in IIS7 where IIS pipeline is tightly integrated (i.e. is just the same) as ASP.NET request pipeline. ASP.NET can see every request it wants to and manipulate things along the way. In this mode, ASP.NET HttpModules basically have nearly as much power as an ISAPI filter would have had and ASP.NET HttpHandlers can have nearly equivalent capability as an ISAPI extension could have.

In-Process stores the session in memory on the web server. Out-of-Process Session state management stores data in an external server. The external server may be either a SQL Server or a State Server. All objects stored in session are required to be serializable for Out-of- Process state management.

Fragment Caching: It caches the portion of the page generated by the request. For that, we can create user controls with the below code:

<%@ OutputCache Duration="120" VaryByParam="CategoryID;SelectedID"%>

Yes. We have to include below mvc assembly references in the web forms application to create hybrid application. System.Web.Mvc System.Web.Razor System.ComponentModel.DataAnnotations

Web config file is specific to a web application where as machine config is specific to a machine or server. There can be multiple web config files into an application where as we can have only one machine config file on a server.

Session Cookie - Resides on the client machine for a single session until the user does not log out. Persistent Cookie - Resides on a user's machine for a period specified for its expiry, such as 10 days, one month, and never.

Katana is a fully developed framework made to make a bridge between current ASP.NET frameworks and OWIN specification. Katana is a set of components by Microsoft built using OWIN specifications. Some of these components include Web API, ASP.NET Identity and SignalR. vNext is the successor to Katana (which is why they look so similar) and ASP.NET vNext is now known as ASP.NET 5.

ASP.NET Core is an open-source, cross-platform framework for building cloud-based web apps on Windows, macOS, or Linux. It has higher performance than ASP.NET 4.x and uses .NET Core Runtime and there is no dependency on System.Web . ASP.NET 4.x is a mature framework that provides the services needed to build enterprise-grade, server- based web apps on Windows. You should use .NET Core for your server application when: You have cross-platform needs. You are targeting microservices. You are using Docker containers. You need high performance and scalable systems. You need side by side of .NET versions by application. You should use .NET Framework for your server application when: Your application currently uses .NET Framework (recommendation is to extend instead of migrating) You need to use third-party .NET libraries or NuGet packages not available for .NET Core. You need to use .NET technologies that are not available for .NET Core. You need to use a platform that doesn’t support .NET Core.

HTTP modules intercept incoming requests and inject pre-processing logic in the ASP.Net request processing pipeline. There are two ways in which you can inject logic in the request pipeline of an ASP.NET application - HttpHandlers and HttpModules . An HttpModule is a component that is part of the ASP.NET request processing pipeline and is called on every request that is made to your application. HttpModules can have access to the life cycle events of a request and hence they can be used to modify the response as well.

Windows Services are typically hosted on other infrastructure that isn’t also hosting your website. They can be deployed independently, and don’t have really any tie into your website. But that also comes as a negative. If you are using PAAS on something like Azure or Google Cloud, you would then need a separate VM to host your Windows Service.

WebJobs are similar to hosted services in that they run on the same machine as an Azure Website – thus sharing resources.

WebJobs do have the added benefit of being able to be deployed separately (Hosted services are part of the website) and have additional functionality when it comes to running as a singleton. With Hosted Services, there is an instance running of that hosted service for every deployment of your website which can be an issue if you only want one instance of that “process” running at any time. The one other difference really is that with the WebJobs SDK, you get things like queue/blob triggers right away. Inside a ASP.NET Core Hosted Service, you would need to write all of this manually.

Starting with ASP.NET Core 3.0: IHost : The host is the component that hosts and runs your application and its services. This is a generalization of the previous IWebHost but fullfills basically the same task: It starts configured hosted services and makes sure that your app is running and working. IHostBuilder : The host builder constructs the host and configures various services. This is the generalization of the previous IWebHostBuilder but also basically does the same just for generic IHost . It configures the host before the application starts. There is the Host.CreateDefaultBuilder method that will set up a host with various defaults, e.g. configuration using appsettings.json and logging. IHostedService : A hosted service is a central component that the host hosts. The most common example would be the ASP.NET Core server, which is implemented as a hosted service on top of the generic host. You can also write your own hosted services, or add third-party services that allow you to nicely add things to your application. The generic host introduced with ASP.NET Core 3.0 and .NET Core 3.0 basically replaces the previous IWebHost and IWebHostBuilder. It follows the very same architecture and idea but is simply reduced to non-web tasks so that it can work with a number of different purposes. ASP.NET Core then just builds on top of this generic host.

Transient they are created every time per code request they will use more memory & Resources and can have a negative impact on performance a new instance is provided every time a service instance is requested whether it is in the scope of the same HTTP request or across different HTTP requests, use this for the lightweight service with little or no state if you're only doing computation, for instance, that can be transient scoped because you're not exhausting anything by having multiple copies use a transient scope unless you have a good, explicit reason to make it a singleton. That would be the reasons like maintaining state, utilizing limited resources efficiently Scoped a better option when you want to maintain the state within a request, It is equivalent to a singleton in the current scope in MVC it creates one instance for each HTTP request, but it uses the same instance in the other calls within the same web request normally we will use this for SQL connection, which means it will create and dispose the SQL connection per request Singleton memory leaks in these services will build up over time, also memory efficient as they are created once reused everywhere, use you when need to maintain an application-wide state, singletons are best when you're utilizing limited resources, like sockets and connections. If you end up having to create a new socket every time the service is injected (transient), then you'll quickly run out of sockets and then performance really will be impacted

If something needs to persist past one particular operation, then transient won't work, because you'll have no state, because it will essentially start over each time it's injected Application configuration or parameters, Logging Service caching of data is some of the examples where you can use singletons.

The system.web section is for configuring IIS 6.0, while the system.webserver version is used to configure IIS 7.0. IIS 7.0 includes a new ASP.NET pipeline and some configuration differences, hence the extra config sections. The former is for Classic Mode. The latter is for Integrated Pipeline Mode (available in IIS7+).

In the simplest terms, an ASP.NET HttpHandler is a class that implements the System.Web.IHttpHandler interface. ASP.NET HTTPHandlers are responsible for intercepting requests made to your ASP.NET web application server. They run as processes in response to a request made to the ASP.NET Site. The most common handler is an ASP.NET page handler that processes .aspx files. When users request an .aspx file, the request is processed by the page through the page handler. ASP.NET offers a few default HTTP handlers:

Page Handler (.aspx): handles Web pages
User Control Handler (.ascx): handles Web user control pages
Web Service Handler (.asmx): handles Web service pages
Trace Handler (trace.axd): handles trace functionality

Classic mode (the only mode in IIS6 and below) is a mode where IIS only works with ISAPI extensions and ISAPI filters directly. In this mode, ASP.NET is not much different from PHP or other technologies for IIS. This separation of the IIS and ASP.NET request-processing models results in duplication of some processing steps, such as authentication and authorization. Integrated mode, on the other hand, is a new mode in IIS7 where IIS pipeline is tightly integrated (i.e. is just the same) as ASP.NET request pipeline. ASP.NET can see every request it wants to and manipulate things along the way. In this mode, ASP.NET HttpModules basically have nearly as much power as an ISAPI filter

would have had and ASP.NET HttpHandlers can have nearly equivalent capability as an ISAPI extension could have.

The Page.Validate() method is used to force all the validation controls to run and to perform validation.

ASP.NET Core on .NET Core is cross-platform ASP.NET Core. It can run on Windows, Mac, and Linux (including Docker). The server doesn't need .NET Core installed - the dependencies can be bundled with the application. ASP.NET Core ships entirely as NuGet packages. This allows you to optimize your app to include only the necessary NuGet packages. In fact, ASP.NET Core 2.x apps targeting .NET Core only require a single NuGet package. The benefits of a smaller app surface area include tighter security, reduced servicing, and improved performance. It is not required to install .Net framework to run asp.net core with .net core application. An ASP.NET Core application with .net core is a console app that creates a web server in its Main method. It uses Kestrel web server to run the application. ASP.NET Core on .NET Framework is ASP.NET Core on the "full" or "desktop" .NET Framework (e.g. .NET Framework 4.6.2). These applications can only run on Windows, but everything else about ASP.NET Core behaves the same way. It also supports Aspx, WPF, WCF and WebServices.

Yes. This might surprise many, but ASP.NET Core works with .NET framework and this is officially supported by Microsoft. ASP.NET Core works with: .NET Core framework .NET framework

The .NET Generic Host is a feature which sets up some convenient patterns for an application including those for dependency injection (DI), logging, and configuration. It was originally named Web Host and intended for Web scenarios like ASP.NET Core applications but has since been generalized (hence the rename to Generic Host) to support other scenarios, such as Windows services, Linux daemon services, or even a console app. A host is an object that encapsulates an app’s resources, such as:

Dependency injection (DI)
Logging
Configuration
IHostedService implementations

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 separate different apps which require different levels of security.

A postback originates from the client browser. Usually one of the controls on the page will be manipulated by the user (a button clicked or dropdown changed, etc), and this control will initiate a postback. The state of this control, plus all other controls on the page (known as the View State) is Posted Back to the web server.

View State is the method to preserve the Value of the Page and Controls between round trips. It is a Page-Level State Management technique. View State is turned on by default and normally serializes the data in every control on the page regardless of whether it is actually used during a post-back. A web application is stateless. That means that a new instance of a page is created every time when we make a request to the server to get the page and after the round trip our page has been lost immediately

ASP.NET, at its most basic level, provides a means for you to provide general HTML markup combined with server side "controls" within the event-driven programming model that can be leveraged with VB, C#, and so on. You define the page(s) of a site, drop in the controls, and provide the programmatic plumbing to make it all work. ASP.NET MVC is an application framework based on the Model-View-Controller architectural pattern. This is what might be considered a "canned" framework for a specific way of implementing a web site, with a page acting as the "controller" and dispatching requests to the appropriate pages in the application. The idea is to "partition" the various elements of the application, eg business rules, presentation rules, and so on. Think of the former as the "blank slate" for implementing a site architecture you've designed more or less from the ground up. MVC provides a mechanism for designing a site around a pre-determined "pattern" of application access, if that makes sense. There's more technical detail to it than that, to be sure, but that's the nickel tour for the purposes of the question.

Everything starts from Program.cs public static void Main(string[] args)

{
  BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.Build();

CreateDefaultBuilder extension method will create a default configuration which will look first into appsettings.json files then will look for Environment variables and at the end, it will use command line arguments. This part will also set up default logger sources (debug and console) and load the settings for logging from appsettings.json. After the CreateDefaultBuilder finishes, then Startup class is executed. First, the constructor code is executed. After that, services are added to DI container via AddServices method that lives in Startup class. After that, an order of middleware that will handle every incoming request is set up.

Logging is built-in and you get access to structured logs from the ASP.NET Core host itself to your application. With tools like Serilog, you can extend your logging easily and save your logs to file, Azure, Amazon or any other output provider. You can configure verbosity and log levels via configuration (appsettings.json by default), and you can configure log levels by different categories.

ASP.NET Core is a brand new cross-platform web framework built with .NET Core framework. It is not an update to existing ASP.NET framework. It is a complete rewrite of the ASP.NET framework. It works with both .NET Core and .NET Framework. Main characterestics of ASP.NET Core: DI Container which is quite simple and built-in. You can extend it with other popular DI containers Built-in and extensible structured logging. You can redirect output to as many sources as you want (file,

Azure, AWS, console)

Extensible strongly typed configuration, which can also be used to reload at run-time Kestrel – new, cross-platform and super fast web server which can stand alone without IIS, Nginx or Apache New, fully async pipeline. It is easily configured via middleware ASP.NET All meta package which improves development speed, and enables you to reference all Microsoft packages for ASP.NET Core and it will deploy only those that are being used by your code There is no web.config. We now use appsettings.json file in combination with other sources of configuration (command line args, environment variables, etc.)

There is no _Global._asax – We have Startup.cs which is used to set up Middleware and services for DI Container.

When we click submit button on a web page, the page post the data to the same page. The technique in which we post the data to different pages is called Cross Page posting. This can be achieved by setting POSTBACKURL property of the button that causes the postback. Findcontrol method of PreviousPage can be used to get the posted values on the page to which the page has been posted.

When we click submit button on a web page, the page post the data to the same page. The technique in which we post the data to different pages is called Cross Page posting. This can be achieved by setting POSTBACKURL property of the button that causes the postback. Findcontrol method of PreviousPage can be used to get the posted values on the page to which the page has been posted.

MVC is almost ALWAYS the better solution. There is why: The page lifecylce is simpler and more efficient There is no such thing as controls besides html controls. You don't need to debug your output to see what ASP .Net is generating. ViewModels give you immense power and obviate the need to do manual control binding and it eliminates many errors relating to binding. You can have multiple forms on a page. This was a serious limitation of WebForms. The web is stateless and MVC matches the architecture of the web more closely. Webforms introduces state and the bugs you have with it by introducing the ViewState. The ViewState is automatic and works in the background, so it doesn't always behave the way you want it to. Web applications need to work with ajax these days. It's not acceptable to have full page loads any more. MVC makes ajax so so much better, easier and more efficient with JQuery. Because you can have multiple forms on a page, and because the architecture is driven by calls to urls, you can do funky things like ajax load a different form, like an edit form into your current page using JQuery. Once you realise what this lets you do you can do amazing things easily. ASP.Net WebForms is not only an abstraction over html, it is an extremely complex one. Sometimes you would get a weird bug and struggle with it for much longer than need be. In many cases you could actually see what it was doing wrong but you are unable to do anything about it. You end up doing weird workarounds.

WebForms does not make a good technology for designers. Designers often like working with html directly. In MVC it's a view, in WebForms it's half a day of work. As the web platform is evolving fast WebForms wont keep up. It's not aware of new tags or features of HTML5, it will still render the same stuff unless you get (often) expensive 3rd party controls or wait for Microsoft to issue an update. Controls in WebForms limit you in so many ways. In MVC you can just grab a JQuery library and integrate it into your templates.

ASP.NET Core Razor Pages is the modern equivalent to "Classic ASP.NET Web Forms." Razor Pages is a new aspect of ASP.NET Core MVC that makes coding page-focused scenarios easier and more productive.

OWIN is a specification on how web servers and web applications should be built in order to decouple them and allow movement of ASP.NET applications to environments which were not supported before. Prior to OWIN, when building ASP.NET application, you were inherently bound to IIS due to the heavy dependency on System.Web assembly. OWIN itself does not have any tools, libraries or anything else. It is just a specification.

If you deploy your WebHost on IIS or a regular Azure App Service, your host can be shut down because of app pool recycles. But if you are deploying your host as a container into an orchestrator like Kubernetes, you can control the assured number of live instances of your host. In addition, you could consider other approaches in the cloud especially made for these scenarios, like Azure Functions. Finally, if you need the service to be running all the time and are deploying on a Windows Server you could use a Windows Service.