Dotnet Interview Questions (recently asked in a dotnet interview on 26-Mar-2020)
RenderPartial() returns void and the output will be written directly to the output stream, where as the Partial() method returns MvcHtmlString which can be assigned to a variable and manipulate if it required. when there is a need to assign output to a variable for manipulating it, then use Partial() else use RenderPartial().
Therefore, in theory, RenderPartial() should give you better performance.
Encapsulation is a protective shield that prevents the data from being accessed by the code outside this shield.
Technically in encapsulation, the variables or data of a class are hidden from any other class and can be accessed only through any member function of own class in which they are declared. As in encapsulation, the data in a class is hidden from other classes, so it is also known as data-hiding. Encapsulation can be achieved by: Declaring all the variables in the class as private and using C# Properties in the class to set and get the values of variables.
Technically in encapsulation, the variables or data of a class are hidden from any other class and can be accessed only through any member function of own class in which they are declared. As in encapsulation, the data in a class is hidden from other classes, so it is also known as data-hiding. Encapsulation can be achieved by: Declaring all the variables in the class as private and using C# Properties in the class to set and get the values of variables.
Single - It returns a single specific element from a collection of elements if element match found. An exception is thrown, if none or more than one match found for that element in the collection.
SingleOrDefault - It returns a single specific element from a collection of elements if element match found. An exception is thrown, if more than one match found for that element in the collection. A default value is returned, if no match is found for that element in the collection.
First - It returns first specific element from a collection of elements if one or more than one match found for that element. An exception is thrown, if no match is found for that element in the collection.
FirstOrDefault - It returns first specific element from a collection of elements if one or more than one match found for that element. A default value is returned, if no match is found for that element in the collection.
SingleOrDefault - It returns a single specific element from a collection of elements if element match found. An exception is thrown, if more than one match found for that element in the collection. A default value is returned, if no match is found for that element in the collection.
First - It returns first specific element from a collection of elements if one or more than one match found for that element. An exception is thrown, if no match is found for that element in the collection.
FirstOrDefault - It returns first specific element from a collection of elements if one or more than one match found for that element. A default value is returned, if no match is found for that element in the collection.
Temp data persist the value for next request depending on following conditions -
Condition 1 (Not read):- If you set a “TempData” inside your action and if you do not read it in your view then “TempData” will be persisted for the next request.
Condition 2 ( Normal Read) :- If you read the “TempData” normally like the below code it will not persist for the next request.
Condition 3 (Read and Keep) :- If you read the “TempData” and call the “Keep” method it will be persisted.
Condition 4 ( Peek and Read) :- If you read “TempData” by using the “Peek” method it will persist for the next request.
Condition 1 (Not read):- If you set a “TempData” inside your action and if you do not read it in your view then “TempData” will be persisted for the next request.
Condition 2 ( Normal Read) :- If you read the “TempData” normally like the below code it will not persist for the next request.
Condition 3 (Read and Keep) :- If you read the “TempData” and call the “Keep” method it will be persisted.
Condition 4 ( Peek and Read) :- If you read “TempData” by using the “Peek” method it will persist for the next request.
ConfigureServices is used to add services to our application. We can use services via integrated DI once we add them inside of ConfigureServices. Services added to DI can be utilised within our application.
Configure method is used to set up middlewares, routing rules. We manage HTTP request pipeline inside of Configure method. Inside of Configure method, we write code that will process every request and eventually make a response.
Configure method is used to set up middlewares, routing rules. We manage HTTP request pipeline inside of Configure method. Inside of Configure method, we write code that will process every request and eventually make a response.
app.Run is a terminal middleware and end the request.
app.Use will pass the request to next middleware.
Middleware are executed in the same order in which they are added. The difference is, middleware defined using app.Use may call next middleware component in the pipeline. On the other hand, middlware defined using app.Run will never call subsequent middleware.
ex. public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
app.Use(async (context, next) =>
{
await context.Response.WriteAsync("
await next();
});
app.Run(async context => {
await context.Response.WriteAsync("
});
app.Use(async (context, next) =>
{
await context.Response.WriteAsync("
await next();
});
}
OUTPUT: Inside middleware defined using app.Use
Inside middleware defined using app.Run
app.Use will pass the request to next middleware.
Middleware are executed in the same order in which they are added. The difference is, middleware defined using app.Use may call next middleware component in the pipeline. On the other hand, middlware defined using app.Run will never call subsequent middleware.
ex. public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
app.Use(async (context, next) =>
{
await context.Response.WriteAsync("
Inside middleware defined using app.Use
");await next();
});
app.Run(async context => {
await context.Response.WriteAsync("
Inside middleware defined using app.Run
");});
app.Use(async (context, next) =>
{
await context.Response.WriteAsync("
Another Middleware defined using app.Use
");await next();
});
}
OUTPUT: Inside middleware defined using app.Use
Inside middleware defined using app.Run
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
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.
Reference: https://stackoverflow.com/questions/35639205/what-is-kestrel-vs-iis-express
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
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.
Reference: https://stackoverflow.com/questions/35639205/what-is-kestrel-vs-iis-express
In computer science terms, a Task is a future or a promise. (Some people use those two terms synomymously, some use them differently, nobody can agree on a precise definition.) Basically, a Task
"promises" to return you a T, but not right now honey, I'm kinda busy, why don't you come back later?
A Thread is a way of fulfilling that promise. But not every Task needs a brand-new Thread. (In fact, creating a thread is often undesirable, because doing so is much more expensive than re-using an existing thread from the threadpool. More on that in a moment.) If the value you are waiting for comes from the filesystem or a database or the network, then there is no need for a thread to sit around and wait for the data when it can be servicing other requests. Instead, the Task might register a callback to receive the value(s) when they're ready.
In particular, the Task does not say why it is that it takes such a long time to return the value. It might be that it takes a long time to compute, or it might that it takes a long time to fetch. Only in the former case would you use a Thread to run a Task. (In .NET, threads are freaking expensive, so you generally want to avoid them as much as possible and really only use them if you want to run multiple heavy computations on multiple CPUs. For example, in Windows, a thread weighs 12 KiByte (I think), in Linux, a thread weighs as little as 4 KiByte, in Erlang/BEAM even just 400 Byte.
Reference: https://stackoverflow.com/questions/4130194/what-is-the-difference-between-task-and-thread
A Thread is a way of fulfilling that promise. But not every Task needs a brand-new Thread. (In fact, creating a thread is often undesirable, because doing so is much more expensive than re-using an existing thread from the threadpool. More on that in a moment.) If the value you are waiting for comes from the filesystem or a database or the network, then there is no need for a thread to sit around and wait for the data when it can be servicing other requests. Instead, the Task might register a callback to receive the value(s) when they're ready.
In particular, the Task does not say why it is that it takes such a long time to return the value. It might be that it takes a long time to compute, or it might that it takes a long time to fetch. Only in the former case would you use a Thread to run a Task. (In .NET, threads are freaking expensive, so you generally want to avoid them as much as possible and really only use them if you want to run multiple heavy computations on multiple CPUs. For example, in Windows, a thread weighs 12 KiByte (I think), in Linux, a thread weighs as little as 4 KiByte, in Erlang/BEAM even just 400 Byte.
Reference: https://stackoverflow.com/questions/4130194/what-is-the-difference-between-task-and-thread
Nice articel, This article help me very well. Thank you. Also please check my article on my site Flox Blog.
ReplyDelete