ASP.Net Core Interview Questions and Answers - Part 02
Are you preparing for the .Net Core Interview? If yes, then you are at the right place. This is the ASP.Net Core Interview Questions and Answers article series. Here we will see the Top 150+ .Net Core Interview Questions with Answers.
Please visit our YouTube Channel for Interviews and other videos by below link:
Please read the complete Design Pattern, C#, MVC, WebAPI, and .Net Framework Interview Questions and Answers article series here.
Introduction
This is the 2nd part of the .Net Core Interview Questions and Answers article series. Each part contains ten .Net Core Interview Questions. Please read all the .Net Interview Questions list here.
I will highly recommend to please read the previous parts over here before continuing the current part:
ASP.Net Core Interview Questions and Answers - Part 02
Q013. What is the difference between .NET Framework and .NET Core?
.Net Core and the.Net Framework have a subset-superset relationship. .Net Core is named "Core" as it contains the core features from the .Net Framework, for both the runtime and framework libraries.
.Net Core is a free, open-source, cross-platform, high-performance framework for building modern, cloud-based, Internet-connected applications. On the other hand, .NET Framework is a Windows-only version of .NET for building any type of app that runs on Windows.
The first version .Net Core 1.0 was released in June 2016 and the last version of the .Net Core is 3.1 which was released in Dec 2019. While the first version of .Net Framework (.NET 1.0) is released in 2001.
- The .Net Core is completely open-source while in the .Net Framework only a Few components are open-source.
- The .Net core is cross-platform compatible while the .Net Framework is only Windows compatible.
- The .Net core does not support desktop application development while the .Net Framework supports web and desktop application development.
- The .Net core supports microservices development very well while the .Net Framework does not support microservices development.
- The .Net Core is lightweight and fast compared to the .Net Framework.
Q014. What is the difference between .NET Core and .Net 5?
The .NET 5 is also a free, cross-platform, open-source developer platform for building many different types of applications like .Net Core.
.NET 5 was the next major release of .NET Core after 3.1. Microsoft named this new release .NET 5 instead of .NET Core 4 for two reasons:
- Microsoft skipped version numbers 4.x to avoid confusion with .NET Framework 4.x.
- Microsoft dropped the word "Core" from the name to emphasize that this is the main implementation of .NET going forward. .NET 5 supports more types of apps and more platforms than .NET Core or .NET Framework.
However, ASP.NET Core 5.0 is based on .NET 5 but retains the name "Core" to avoid confusing it with ASP.NET MVC 5. Likewise, Entity Framework Core 5.0 retains the name "Core" to avoid confusing it with Entity Framework 5 and 6.
So the .Net 5 has all the features of .Net Core. But .NET 5 includes the following new features and improvements compared to .NET Core 3.1:
- System.Text.Json new features
- Single file apps
- App trimming
- Tooling support for dump debugging
- C#, F#, and VB updates
- Performance Improvements(Garbage Collection, System.Text.Json, System.Text.RegularExpressions, Async ValueTask pooling)
Q015. What is CoreFx in .Net?
.NET Core is a modular runtime and library implementation that includes a subset of the .NET Framework. The NET Core consists of a set of libraries, called “CoreFX”, and a small, optimized runtime, called “CoreCLR”.
The .NET Core Libraries (CoreFX) is the reimplementation of the class libraries for .NET Core. CoreFX is a platform-neutral code that is shared across all platforms.
Platform-neutral code can be implemented as a single portable assembly that is used on all platforms. CoreFX is the foundational class library for .NET Core. It includes types for collections, file systems, console, JSON, XML, async, and many others.
Q016. What is CoreCLR?
The CoreCLR is the .NET execution engine in .NET Core, performing functions such as garbage collection and compilation to machine code. Core CLR is the Common Language Runtime for .NET 5 (and .NET Core) and later versions.
The CLR implementation for .NET 5 and later versions (also known as the Core CLR) is built from the same code base as the .NET Framework CLR. Originally, the Core CLR was the runtime of Silverlight and was designed to run on multiple platforms, specifically Windows and OS X. It's still a cross-platform runtime, now including support for many Linux distributions.
In contrast to the CLR, CoreRT is not a virtual machine, which means it doesn't include the facilities to generate and run code on-the-fly because it doesn't include a JIT.
It does, however, include the GC and the ability for Run-Time Type Identification (RTTI) and reflection. However, its type system is designed so that metadata for reflection isn't required. Not requiring metadata enables having an AOT toolchain that can link away superfluous metadata and (more importantly) identify code that the app doesn't use.
Q017. What is .NET Native? What are the advantages of .Net Native?
The .Net Native is a compiler tool chain that produces native code Ahead-of-Time (AOT) compilation, as opposed to just-in-time (JIT).
.NET Native is a precompilation technology for building and deploying UWP apps (Universal Windows Platform). UWP (Universal Windows Platform) is the application framework supported by .NET Native. .NET Native is included with Visual Studio 2015 and later versions. It automatically compiles the release version of UWP apps that are written in managed code (C# or Visual Basic) to native code.
In .Net Native applications, compilation happens on the developer's machine similar to the way a C++ compiler and linker work. It removes unused code and spends more time optimizing it. It extracts code from libraries and merges them into the executable. The result is a single module that represents the entire app. .NET Native involves more than a compilation to native code. It transforms the way that .NET Framework apps are built and executed.
Typically, .NET apps are compiled to intermediate language (IL). At run time, the just-in-time (JIT) compiler translates the IL to native code. In contrast, .NET Native compiles UWP apps directly to native code.
Advantages of .Net Native:
- Faster execution times for the majority of apps and scenarios. Usually, performance will be superior to code that is first compiled to IL and then compiled to native code by the JIT compiler.
- Faster startup times for the majority of apps and scenarios.
- Optimized app memory usage.
- Low deployment and update costs.
- You can continue to program in C# or VB.
- You can continue to take advantage of the resources provided by .NET Framework, including its class library, automatic memory management and garbage collection, and exception handling.
Q018. What is UWP (Universal Windows Platform) App in .Net?
UWP is an implementation of .NET that is used for building touch-enabled Windows applications and software for the Internet of Things (IoT). It's designed to unify the different types of devices that you may want to target, including PCs, tablets, phones, and even the Xbox.
UWP provides many services, such as a centralized app store, an execution environment (AppContainer), and a set of Windows APIs to use instead of Win32 (WinRT). Apps can be written in C++, C#, Visual Basic, and JavaScript. When using C# and Visual Basic, the .NET APIs are provided by .NET 5 (and .NET Core) and later versions.
UWP apps will be able to use libraries you have created in .net core as long as you target the .netstandard1.6 (or higher) framework moniker. UWP is only for the Windows ecosystem.
Q019. What is TFM (Target Framework Moniker) in .Net Core?
TFM is a standardized token format for specifying the target framework of a .NET app or library. Target frameworks are typically referenced by a short name, such as net462. Long-form TFMs (such as .NETFramework, Version=4.6.2) exist but are not generally used to specify a target framework.
When you target a framework in an app or library, you're specifying the set of APIs that you'd like to make available to the app or library. You specify the target framework in your project file using a target framework moniker (TFM).
An app or library can target a version of .NET Standard. .NET Standard versions represent standardized sets of APIs across all .NET implementations.
For example, a library can target .NET Standard 1.6 and gain access to APIs that function across .NET Core and .NET Framework using the same codebase. An app or library can also target a specific .NET implementation to gain access to implementation-specific APIs.
For some target frameworks, such as .NET Framework, the APIs are defined by the assemblies that the framework installs on a system and may include application framework APIs (for example, ASP.NET).
For package-based target frameworks (for example, .NET 5+, .NET Core, and .NET Standard), the APIs are defined by the NuGet packages included in the app or library.
Q020. What is NuGet? What are the advantages of the inclusion of NuGet Packages in .Net Core?
NuGet is an essential tool for any modern development platform which provides a mechanism through which developers can create, share, and consume useful code. NuGet is a Package Management System for Visual Studio. It makes it easy to add, update and remove external libraries in our application.
For .NET and .NET Core, the Microsoft-supported mechanism for sharing code is NuGet, which defines how packages for .NET are created, hosted, and consumed, and provides the tools for each of those roles.
NuGet is a package manager for the .NET ecosystem and is the primary way developers discover and acquire .NET open-source libraries. NuGet.org, a free service provided by Microsoft for hosting NuGet packages, is the primary host for public NuGet packages. A NuGet package (*.nupkg) is a zip file that contains .NET assemblies and associated metadata.
A NuGet package is a single ZIP file with the .nupkg extension that contains compiled code (DLLs), other files related to that code, and a descriptive manifest that includes information like the package's version number.
Because NuGet supports private hosts alongside the public nuget.org host, you can use NuGet packages to share code that's exclusive to an organization or a workgroup.
What does NuGet do for us?
- NuGet provides the central nuget.org repository with support for private hosting.
- NuGet provides the tools developers need for creating, publishing, and consuming packages.
- Most importantly, NuGet maintains a reference list of packages used in a project and the ability to restore and update those packages from that list.
- Most notably, NuGet manages a package cache and a global packages folder to shortcut installation and reinstallation. The cache avoids downloading a package that's already been installed on the machine.
- Within an individual project, NuGet manages the overall dependency graph, which again includes resolving multiple references to different versions of the same package.
- Beyond that, NuGet maintains all the specifications related to how packages are structured (including localization and debug symbols) and how they are referenced.
The inclusion of Nuget Packages in .Net Core will make the applications to be optimized as we need to include only those packages that we need.
Q021. What is the difference between Implicit and Explicit Compilation? What are the advantages and disadvantages of both?
Explicit Compilation:
Explicit compilation converts the higher-level programming language into object code prior to program execution. Ahead of time (AOT) compilers are designed to ensure that, the CPU can understand every line in the code before any interaction takes place.
Ahead of time (AOT) compiler delivers faster start-up time, especially in large applications where much code executes on startup. But it requires more disk space and more memory/virtual address space to keep both the IL and pre-compiled images. In this case, the JIT Compiler has to do a lot of disk I/O actions, which are quite expensive.
Impilicit Compilation:
The implicit compilation is a two-step process:
- The first step is converting the source code to an intermediate language (IL) by a language-specific compiler.
- The second step is converting the IL to machine instructions.
The main difference with the explicit compilers is that only executed fragments of IL code are compiled into machine instructions, at runtime. The .NET framework calls this compiler the JIT (Just-In-Time) compiler.
The JIT compiler is part of the Common Language Runtime (CLR). The CLR manages the execution of all .NET applications. In addition to JIT compilation at runtime, the CLR is also responsible for garbage collection, type safety, and for exception handling.
JIT can generate faster code because it targets the current platform of execution. AOT compilation must target the lowest common denominator among all possible execution platforms. JIT can profile the application while it runs, and dynamically re-compile the code to deliver better performance in the hot path (the most used functions).
You can use tiered compilation in .Net to configure .NET compilation explicitly. The tiered compilation is used to configure whether the just-in-time (JIT) compiler uses tiered compilation or not.
In .NET Core 3.0 and later, the tiered compilation is enabled by default. But in .NET Core 2.1 and 2.2, the tiered compilation is disabled by default.
.NET 6 standardizes on the prefix DOTNET_ instead of COMPlus_ for environment variables that configure .NET run-time behavior. However, the COMPlus_ prefix will continue to work. If you're using a previous version of the .NET runtime, you should still use the COMPlus_ prefix for environment variables.
runtimeconfig.json file:
Q022. What is MSBuild and how does it work with .NET Core?
The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio. This engine, also known as MSBuild, provides an XML schema for a project file that controls how the build platform processes and builds software.
Visual Studio uses MSBuild, but MSBuild doesn't depend on Visual Studio, MSBuild can run without Visual Studio. By invoking msbuild.exe on your project or solution file, you can orchestrate and build products in environments where Visual Studio isn't installed.
Visual Studio uses MSBuild to load and build managed projects. The project files in Visual Studio (.csproj, .vbproj, .vcxproj, and others) contain MSBuild XML code that executes when you build a project by using the IDE.
Visual Studio projects import all the necessary settings and build processes to do typical development work, but you can extend or modify them from within Visual Studio or by using an XML editor.
.NET Core applications are typically built using MSBuild or dotnet.exe. While dotnet build is considerably simpler to use than MSBuild, it uses MSBuild behind the scenes. MSBuild and dotnet.exe don't require Visual Studio to be installed. Starting with Visual Studio 2022, when you build in Visual Studio, the 64-bit version of MSBuild is used.
To run MSBuild at a command prompt, pass a project file to MSBuild.exe, together with the appropriate command-line options.
MSBuild.exe MyProj.proj -property:Configuration=Debug
Another method for building is by using the dotnet.exe CLI tool:
dotnet.exe build MyProject.csproj --configuration Release
To Be Continued Part-03...
Recommended Articles
Thanks for visiting this page. Please follow and join us on LinkedIn, Facebook, Telegram, Quora, YouTube, Twitter, Pinterest, Tumbler, and VK for regular updates.
Posts
No comments:
Post a Comment
Please do not enter any HTML. JavaScript or spam link in the comment box.