Junior .NET Core Interview Questions

Razor Views are templates that combine HTML with C# using the Razor syntax to render dynamic HTML responses.

Razor is lightweight, fast, and avoids the heavy view state and page lifecycle of WebForms. Views are usually driven by strongly typed models, enabling clean separation of concerns between UI and logic.

Layouts define a shared page shell (e.g., header, footer, navigation) used across many views.

Partial Views are reusable view fragments for rendering common UI pieces (e.g., a login panel or a list of items).

View Components encapsulate both rendering logic and view; they behave like mini-controllers plus views and are ideal for widgets (menus, dashboards, notifications) that need their own logic and markup.

Tag Helpers let you apply server-side behavior to HTML elements using natural HTML syntax.

Examples include form, input, link, and environment helpers. They integrate tightly with routing, model binding, and validation, improving readability and tooling support (IntelliSense) compared to traditional HTML helpers.

ViewData and ViewBag are used to pass data from controllers to views within the same request.

• ViewData is a Dictionary<string, object>.
• ViewBag is a dynamic wrapper around ViewData.

TempData persists data across a single redirect and is cleared once read. It is backed by cookies or session and is ideal for messages (e.g., success notifications) that survive a redirect.

Anti-forgery protection defends against Cross-Site Request Forgery (CSRF) attacks.

ASP.NET Core generates a pair of correlated tokens: one stored in a cookie and one embedded in the form. On POST, both must be present and valid. This ensures that state-changing requests originate from the legitimate site and user, not from a malicious third-party page.

Static files (CSS, JavaScript, images, etc.) are served by the Static File Middleware, which is usually placed early in the pipeline.

When a request matches a static file in wwwroot (or another configured folder), the middleware serves it directly and short-circuits the pipeline, bypassing MVC and other components. This leads to better performance and avoids unnecessary computation for simple file requests.

Earlier ASP.NET Core versions used WebHost to configure web-specific hosting (Kestrel, IIS integration, MVC, etc.).

The newer Generic Host unifies hosting for all app types (web, background services, workers, gRPC, SignalR) under a single abstraction.

• Generic Host centralizes DI, configuration, and logging.
• It supports non-web workloads and multiple hosted services in the same process.
• For web apps, Generic Host wires in WebHost-like features such as Kestrel and endpoint routing under the hood.

IHostApplicationLifetime (renamed to IHostApplicationLifetime / IHostApplicationLifetime in newer versions) exposes three key notifications:

• ApplicationStarted – Fired when the app is fully started and ready to serve requests.
• ApplicationStopping – Fired when the app begins a graceful shutdown (e.g., SIGTERM in containers).
• ApplicationStopped – Fired when shutdown is complete and cleanup has finished.

These events are used to warm up caches, start or stop background tasks, flush logs, and release resources in cloud and container environments.

The Content Root is the base path for application code, views, and configuration files.

The Web Root (usually wwwroot) is the publicly exposed folder for static files such as CSS, JS, and images.

Separating them ensures that sensitive assets like configuration files, views, and binaries are not accidentally served over HTTP. Only files under Web Root are directly reachable by clients.

• Use – Adds middleware that can process the request and optionally call the next middleware via a next delegate.
• Run – Adds terminal middleware that does not call the next component; it ends the pipeline.
• Map – Branches the pipeline based on the request path, creating sub-pipelines for specific URL segments.

Together, they give fine-grained control over the shape and branching of the request pipeline.

ASP.NET Core supports named environments such as Development, Staging, and Production, typically controlled by the ASPNETCORE_ENVIRONMENT variable.

Environment controls:

• Which configuration files are loaded (e.g., appsettings.Development.json).
• Whether detailed error pages are shown.
• Which services or features are enabled (e.g., runtime compilation only in Development).

Environment-based configuration prevents debug info and dev-only behaviors from leaking into production.

User Secrets are a development-only feature for storing sensitive values (API keys, connection strings) outside the project tree.

• They are not checked into source control.
• They are only used for the Development environment.
• They override configuration from JSON files.

In production, secrets should come from environment variables, Azure Key Vault, or similar secure stores, not from JSON configuration files.

The Options Pattern binds configuration sections to strongly typed classes and injects them via IOptions<T>, IOptionsSnapshot<T>, or IOptionsMonitor<T>.

Benefits include:

• Centralized configuration mapping and validation.
• No magic strings scattered throughout the code.
• Ability to reload or react to config changes.
• Cleaner separation of configuration from business logic.

Razor View Compilation converts .cshtml files into C# classes and compiles them into assemblies.

• Runtime compilation – Views are compiled on first use; flexible but slower for initial requests.
• Precompilation – Views are compiled at build/publish time; improves startup and reduces CPU at runtime.

Production apps typically use precompiled views to improve startup time and performance.

The View Engine is responsible for locating and rendering views from templates.

Razor differs from older engines by:

• Using C# instead of server controls or code-behind pages.
• Eliminating view state and page lifecycle complexity.
• Producing clean HTML with async support.
• Providing strong tooling and compile-time checks.

Tag Helpers operate within the HTML element tree and can apply behavior to all nested content.

Scoped helpers like <environment> wrap child elements to conditionally render sets of tags based on environment, reducing duplication and improving structure.

They help apply consistent behavior (e.g., script loading, validation attributes) across entire sections of the UI.

• ViewData – A Dictionary<string, object> for passing data from controller to view in the same request.
• ViewBag – A dynamic wrapper around ViewData for more convenient syntax.
• TempData – Persists data across one redirect; cleared after it is read.

ViewData/ViewBag are for same-request communication; TempData is designed for redirect scenarios such as Post-Redirect-Get.

Endpoint Routing decouples route matching from endpoint execution.

• UseRouting() runs early, matches the request to an endpoint, and attaches endpoint metadata.
• Middleware such as authentication and authorization can inspect endpoint metadata.
• UseEndpoints() executes the matched endpoint (controller, Razor Page, minimal API).

This improves performance, centralizes routing, and makes it easier to apply policies based on endpoint metadata.

Value Providers are components in the model binding system that know how to fetch data from specific sources:

• Route values
• Query strings
• Form data
• Headers
• Cookies

Model binding queries these providers in order to construct complex models from the incoming HTTP request.

Custom Model Binding is used when default binding cannot map request data to models correctly.

Typical use cases:

• Non-standard data formats.
• Combining multiple values into a single complex object.
• Parsing custom header or route patterns.

Implementing IModelBinder or using custom attributes provides full control over how request data is translated into .NET types.