└── README.md /README.md: -------------------------------------------------------------------------------- 1 | # 100 Must-Know .Net Core Interview Questions in 2025 2 | 3 |
4 |

5 | 6 | web-and-mobile-development 7 | 8 |

9 | 10 | #### You can also find all 100 answers here 👉 [Devinterview.io - .Net Core](https://devinterview.io/questions/web-and-mobile-development/net-core-interview-questions) 11 | 12 |
13 | 14 | ## 1. What is _.NET Core_ and how does it differ from the _.NET Framework_? 15 | 16 | **.NET Core** and **.NET Framework** are both ecosystem variations developed by Microsoft. They share similar libraries, syntax and core components, yet have distinctive characteristics and purposes. 17 | 18 | ### Key Distinctions 19 | 20 | #### Dependency on Operating System 21 | 22 | **.NET Core** is built to fluctuate across operating systems, providing reliability from Windows, macOS, and Linux. 23 | 24 | **.NET Framework's** exclusive residence is on Windows. 25 | 26 | #### Deployment Mechanisms 27 | 28 | For **.NET Framework**, components are distributed through a Global Assembly Cache (GAC). 29 | 30 | In contrast, **.NET Core** utilizes its open-source library format. All essential dependencies are gathered during the runtime of the hosting system. 31 | 32 | #### Stack Structures 33 | 34 | **.NET Core** is modular in design, permitting you to streamline the allocation of resources. This means that resources from .NET Core can be combined with resources from other packages or your code, and any unused resources will be left out of the final deployment. 35 | 36 | **.NET Framework** resources are all-inclusive. Every application constructed within the .NET Framework will use the complete stack of associated resources. 37 | 38 | #### API Accessibility 39 | 40 | **.NET Core** highlights a subset of libraries accessible across all operating systems. This ensures consistent performance among various platforms. 41 | 42 | On the contrary, **.NET Framework** provides in-depth access to exclusive Windows APIs, which might not resonate well with non-Windows platforms. 43 | 44 | 45 | ### Targets and Use-Case Scenarios 46 | 47 | #### .NET Core-Based Projects 48 | 49 | - Cloud-First Deployments: Given its lightweight factor, numerous platforms host applications from **.NET Core**. 50 | - Applications involving containers: **.NET Core** is particularly suitable, bearing its minimalistic resource usage. 51 | - Web-based applications: **.NET Core** is a strong contender due to its inbuilt support for client-server architectures and cloud-based applications. 52 | 53 | #### .NET Framework-Based Projects 54 | 55 | - Long-Running Applications: Applications with consistent and prolonged operational times will significantly benefit from using **.NET Framework**. 56 | - Established Windows-centric applications: **.NET Framework** still reigns as the preferred choice, especially for applications deeply embedded within Windows ecosystems or those leveraging platforms such as Silverlight or WPF. 57 | - Specific APIs: If your application necessitates specialized Windows APIs that aren't accommodated by **.NET Core**, **.NET Framework** remains the ultimate choice. 58 |
59 | 60 | ## 2. Describe the cross-platform capabilities of _.NET Core_. 61 | 62 | **.NET Core** is a framework for developing cross-platform applications. 63 | 64 | ### Key Cross-Platform Features 65 | 66 | - **Libraries**: Provides a consistent set of libraries across operating systems. Developers can use these libraries seamlessly, ensuring that functions work consistently across environments. 67 | 68 | - **Runtime Environment**: .NET Core applications are run using a runtime environment that adapts to the underlying system. The runtime handles critical tasks like memory management and garbage collection. 69 | 70 | - **Cross-Platform Support**: Code written using .NET Core runs on various operating systems without modifications. This allows developers to target a broad range of devices and environments. 71 | 72 | - **Platform-Dependent Code Paths**: In some cases, developers may need to differentiate between OS variants. .NET Core offers mechanisms for handling platform-specific code, enabling conditional execution. 73 | 74 | - **NuGet Packages and Package Management**: .NET Core supports NuGet packages, simplifying the inclusion of third-party libraries. It helps ensure that dependencies are resolved consistently, regardless of the target system. 75 | 76 | - **Code Execution**: .NET Core supports multiple development idioms, including Just-In-Time (JIT) compilation and ahead-of-time (AOT) compilation. These features enable code execution tailored to the system, optimizing performance. 77 |
78 | 79 | ## 3. What are the main components of the _.NET Core architecture_? 80 | 81 | The architecture of the .NET Core platform revolves around modularity, flexibility, and platform independence. 82 | 83 | ### Key Components of .NET Core 84 | 85 | #### Core Features 86 | 87 | - **Framework and BCL**: The BCL (Base Class Library) provides fundamental classes and types, while the Core Framework encompasses core libraries and runtime services. 88 | 89 | - **Garbage Collector**: The GC in .NET Core ensures automatic memory management by alleviating developers from manual memory cleanup, thus minimizing memory leaks and memory management issues. 90 | 91 | - **Just-in-Time (JIT) Compiler**: .NET Core translates Intermediate Language (IL) code into machine code, enabling cross-platform execution. 92 | 93 | - **Multi-level Compilation**: .NET Core employs both on-demand **JIT** compilation and **Ahead-of-Time (AOT)** compilation for specific scenarios. 94 | 95 | - **Portable PDB Format**: This component simplifies debugging across different environments. 96 | 97 | - **Exception Handling and Stack Trace Mechanism**: These built-in mechanisms aid in robust error handling and debugging. 98 | 99 | - **Native Interoperability (P/Invoke)**: .NET Core interacts with native code such as DLLs using the P/Invoke mechanism. 100 | 101 | - **Build and Packaging Tools**: .NET Core's build and packaging mechanisms streamline deployment to various platforms. 102 | 103 | #### Tools and Interfaces 104 | 105 | - **CLI**: The Command-Line Interface offers a powerful, text-based toolset for building, managing, and deploying .NET Core applications. 106 | 107 | - **Global Tooling Management**: This system facilitates the installation and lifecycle management of global .NET Core tools. 108 | 109 | #### Execution Environments 110 | 111 | - **.NET Core Application Host**: This component hosts and manages the execution of .NET Core applications. 112 | 113 | - **Operating System Abstraction**: .NET Core provides a unified set of APIs for interacting with the underlying operating system, ensuring consistency across platforms. 114 | 115 | - **Cross-Platform Compatibility Layer**: This layer simplifies multi-platform development by streamlining interactions between the application and various operating systems. 116 | 117 | #### Libraries and Dependencies 118 | 119 | - **NuGet Package Manager**: The default package manager for .NET Core simplifies the acquisition and management of third-party libraries. 120 | 121 | - **.NET Core-specific NuGet Packages**: These packages are tailored for the .NET Core ecosystem. 122 | 123 | - **.NET Standard Libraries**: These are a consistent set of APIs shared across .NET platforms. 124 | 125 | - **Project References and NuGet Dependency Management**: These tools streamline library dependencies within .NET projects. 126 | 127 | #### Compiler and Build Toolset 128 | 129 | - **.NET Compiler Platform (Roslyn)**: Roslyn serves as the C# and Visual Basic compiler system, providing dynamic code analysis and transformation capabilities. 130 | 131 | - **MSBuild**: This build engine offers comprehensive control over the build process and is notable for its project-file-based build configuration. 132 | 133 | - **NuGet Package Restoration**: The .NET tooling automatically restores **NuGet** packages for a project as part of the build process. 134 | 135 | #### Containers and Microservices 136 | 137 | - **Docker Support**: .NET Core applications can be containerized using Docker for portability and consistency across diverse environments. 138 | 139 | #### Network Integration 140 | 141 | - **HTTP Components**: .NET Core has a range of HTTP-related tools, including an embedded web server, support for SSL, and client-side HTTP capabilities. 142 | 143 | - **WebSocket Support**: The platform supports WebSockets for efficient, bi-directional communication. 144 | 145 | #### Data Persistence and Management 146 | 147 | - **Entity Framework Core**: As the object-relational mapper (ORM) of choice for .NET Core, this component simplifies database interactions. 148 | 149 | - **Data Provider Abstraction**: .NET Core abstracts database providers, allowing applications to work with different databases without extensive modifications. 150 | 151 | - **Data Access and Querying Tools**: It offers various methods for robust data access and querying, such as LINQ and ADO.NET. 152 | 153 | - **In-memory Data Storage**: For transient data storage requirements, .NET Core provides in-memory data storage capabilities. 154 | 155 | - **File I/O and Storage Integration**: The platform includes robust file-handling utilities. 156 | 157 | #### Security and Cryptography 158 | 159 | - **Authentication and Authorization Frameworks**: .NET Core offers features for secure user and service authentication and authorization. 160 | 161 | - **Cryptography Services**: It provides a suite of cryptographic tools for secure data handling. 162 | 163 | - **Code Access Security (CAS)**: This component defends against potential security vulnerabilities by controlling code execution. 164 | 165 | #### Text and Localization 166 | 167 | - **Text Manipulation Utilities**: .NET Core includes a plethora of text-related tools, like string manipulation methods and string encoding controls. 168 | 169 | - **Globalization and Localization Components**: These components aid in the management of region-specific and multilingual applications. 170 | 171 | #### UI and Presentation 172 | 173 | - **Presentation Frameworks**: .NET Core provides frameworks for constructing diverse graphical user interfaces. 174 | 175 | - **ASP.NET Core for Web Applications**: This web framework is tailored for building modern web applications and services. 176 | 177 | - **Blazor for Web Applications**: This innovative web development framework allows for client-side applications with C#. 178 | 179 | - **WPF, WinForms, and Universal Windows Platform (UWP)**: These established frameworks enable desktop and Windows-specific application development. 180 | 181 | - **Gtk# for Cross-Platform Desktop Applications**: This component provides a set of .NET bindings for the GTK+ toolkit. 182 | 183 | - **Mobile-Specific Frameworks**: For mobile application development, .NET Core integrates with Xamarin. 184 |
185 | 186 | ## 4. Explain the _.NET Core CLI_ and its primary functions. 187 | 188 | Let's look at the **.NET Core CLI** and its primary operations: **new**, **build**, **publish**, **run**, **test**. 189 | 190 | ### New 191 | 192 | The **new** command initializes a new .NET project using a specific template. You can choose from project types like console applications, web applications, class libraries, and more. 193 | 194 | ### Build 195 | 196 | With the **build** command, you can compile your source code into an executable format or a library. It also resolves project dependencies and creates an assembly. 197 | 198 | ### Publish 199 | 200 | The **publish** command gathers necessary components for an application, like the .NET Core runtime, and **prepares it for deployment**. This ensures the target machine has the relevant runtime and runtime components. 201 | 202 | ### Run 203 | 204 | The **run** command simplifies the process of executing your application. It does this by **combining building and execution tasks** into a single, more straightforward step. 205 | 206 | ### Test 207 | 208 | Use the **test** command to execute tests in the project. The .NET Core Test Explorer, VS Code, or Continuous Integration (CI) systems like Azure Pipelines or Jenkins can also run these tests. 209 | 210 | ### Simplified Workflow 211 | 212 | These CLI commands simplify the development process. You can transition from creating a new project to building, testing, and running it, all from the command line. These commands save time and make development more efficient. 213 |
214 | 215 | ## 5. How do you create a new _.NET Core project_ using the _CLI_? 216 | 217 | To create a new **.NET Core** project using the command line: 218 | 219 | ### Step 1: Install the .NET Core SDK 220 | 221 | If you haven't already, install the **.NET Core SDK**. This provides the necessary **tools** and **libraries** for developing in .NET. 222 | 223 | ### Step 2: Run the `dotnet new` Command 224 | 225 | Use the `dotnet new` command to **create** a new .NET Core project. This command offers various **project templates**, such as for web APIs, console applications, and more. 226 | 227 | Here is the syntax: 228 | 229 | ```bash 230 | dotnet new [-n ] [-o ] 231 | ``` 232 | 233 | - Substitute **``** with the desired project template like `console`, `webapi`, `mvc`, etc. 234 | - Optionally, set a **``** and an **``**. 235 | 236 | ### Example: Running `dotnet new` to Create a Console App 237 | 238 | Use the following command: 239 | 240 | ```bash 241 | dotnet new console -n MyConsoleApp -o MyConsoleAppDir 242 | ``` 243 | 244 | - **TEMPLATE_NAME**: `console` 245 | - **PROJECT_NAME**: `MyConsoleApp` 246 | - **OUTPUT_DIRECTORY**: `MyConsoleAppDir` 247 | 248 | This will create a new **console application project** with the name `MyConsoleApp` and place it in the `MyConsoleAppDir` folder. 249 |
250 | 251 | ## 6. Discuss the purpose and use of a `csproj` file in a _.NET Core project_. 252 | 253 | The **C# project file** (`*.csproj`) serves as a **configuration manifest** for .NET Core projects, providing a wealth of options for customizing your build process, declaring project dependencies, and adjusting compiler settings. 254 | 255 | The `csproj` file is based on the more general `msbuild` format and has had several iterations as new features are introduced. 256 | 257 | ### Key Elements 258 | 259 | #### Directives for .NET Targeting 260 | 261 | - **Target Framework**: Defines the version and profile of the .NET runtime you're targeting. For multi-platform projects like Xamarin, it can differentiate between platforms. 262 | 263 | - **Type of Output File**: It is usually a .dll or .exe file. 264 | 265 | #### Building and Debugging Configuration 266 | 267 | - **Output Type**: Selects the kind of .NET assembly produced. 268 | - **Debug Symbols Generation**: Decide whether to create debug symbols for better debuggability. 269 | 270 | #### Sources Organization 271 | 272 | - **Source Files**: Provides a list of source files to be included in the project. 273 | 274 | - **Resources**: Offers a way to incorporate non-code files like images or text files. 275 | 276 | #### Compiling Directives 277 | 278 | - **Conditional Compiles**: Conditional symbols can be set to determine which part of the code gets compiled. 279 | 280 | - **Option to Treat Warnings as Errors**: Warnings can be forced to be treated as errors. 281 | 282 | - **Optimizations**: You can control whether the compiler optimizes your code for a fast build or a smaller assembly. 283 | 284 | #### Dependencies Management 285 | 286 | - **Core Assemblies Membership**: The project lists the essential .NET Core assemblies it depends on. 287 | 288 | - **NuGet and Direct Dependencies**: The file signals dependencies through multiple methods, helping the framework to acquire necessary packages. 289 | 290 | - **Framework Assemblies**: It can include or exclude assemblies that are part of the .NET Core library. 291 | 292 | - **Private Library Folder**: It lets you specify a location to search for libraries not on NuGet. 293 | 294 | #### Customization Through Directives 295 | 296 | - **Custom Tasks**: This feature allows you to run custom tasks as part of the build process. 297 | 298 | - **Event-Based Integration**: In some cases, you might want to execute custom actions during specific build events (like "BeforeBuild" or "AfterRebuild"). 299 | 300 | #### Project Settings 301 | 302 | - **Project Type**: It distinguishes between different types of projects like web applications or class libraries. 303 | 304 | - **Default Namespace**: You can set a default namespace for classes created in the project. 305 | 306 | #### Code Analysis and Best Practices 307 | 308 | - **Code Style Rules**: By setting various style rules, you can enforce a consistent coding style in all the projects throughout your solution. 309 | 310 | - **Docs and Localization**: It supports inclusion of documentation and localization files. 311 | 312 | #### Cross-Platform Considerations 313 | 314 | - **Mono and .NET Compact Framework**: It enables developers to target platforms based on Mono or the .NET Compact Framework. 315 | 316 | - **Cross-Platform Execution**: For different platform targets or compatibility modes, the setting ensures the correct execution of the project. 317 | 318 | ### .NET Core SDK Versioning and Evolution 319 | 320 | The `.csproj` underwent significant simplifications in conjunction with the release of .NET Core 3.0, aiming to streamline project file definitions and make them more standardized and modular across project types. 321 | 322 | Through continuous updates and community feedback, the project file remains central to the management and orchestration of .NET Core projects. 323 |
324 | 325 | ## 7. What is the _runtime_ and _SDK_ in _.NET Core_? 326 | 327 | The **.NET Core** framework is a versatile, modular platform for developing cross-platform applications. It delivers its core libraries, tools, and runtime as an integrated package. 328 | 329 | ### Two Essential Components 330 | 331 | 1. **.NET Core Runtime**: This environment is necessary for executing .NET Core applications. It's typically distributed as a single deployable unit, ensuring that applications are self-contained and alleviating the need for separately installed .NET runtimes. 332 | 333 | 2. **.NET Core SDK**: Integrating essential tools like the compiler, NuGet package manager, and MSBuild, the SDK empowers developers to build, test, and publish applications. Its comprehensive suite of libraries and APIs supports development across a range of applications and industries. 334 | 335 | ### Compatibility Considerations 336 | 337 | The version of the .NET Core runtime specifies the advertised **API compatibility level** and **previously introduced feature sets**. 338 | 339 | Developers outline any framework version dependencies in their applications through the use of the `` element in the project file. 340 | 341 | ### Code Example: Project File with Target Framework 342 | 343 | ```xml 344 | 345 | 346 | Exe 347 | netcoreapp3.1 348 | true 349 | 350 | 351 | ``` 352 | 353 | ### Managing Multiple .NET Core Versions 354 | 355 | The .NET Core SDK provides a command-line tool, `dotnet`, which enables you to monitor various installed versions and switch between them seamlessly. Use the `global.json` file in your project to fix the specific SDK version for your project or a range of projects. 356 | 357 | ### Code Example: Global.json 358 | 359 | ```json 360 | { 361 | "sdk": { 362 | "version": "3.1.402" 363 | } 364 | } 365 | ``` 366 |
367 | 368 | ## 8. How would you manage different versions of the _.NET Core SDK_ on the same machine? 369 | 370 | You can use **`global.json`** files and specify the version of the .NET SDK you wish to target within a project. When you run `.net build` or `.net run` in a directory that contains a global.json file, the SDK version specified in that file takes precedence over any other installed versions. 371 | 372 | Here is a code snippet showing how to write a `global.json` file: 373 | 374 | ```json 375 | { 376 | "sdk": { 377 | "version": "2.1.402" 378 | } 379 | } 380 | ``` 381 |
382 | 383 | ## 9. What is the purpose of the `global.json` file? 384 | 385 | The `global.json` file in a .NET Core project defines the version of the SDK used and allows for **multi-project management**. 386 | 387 | It also assists with: 388 | 389 | - **Managing SDK Versions**: By setting the `sdk` field to a specific version, you ensure consistent behavior across development environments and CI/CD pipelines. Additionally, the `allowPrerelease` flag gives you control over using preview versions. 390 | 391 | - **Setting Default Paths for Global Packages and Tools**: The `packageManagement` and `tools` fields can be helpful in specifying directory paths for global tools and packages. This can simplify configuration on new machines or during deployment. For instance, you can use it to set up the same configuration across machines of your team. 392 | 393 | - **Coordinating Multi-Project Solutions**: A `global.json` file helps manage **consistent SDK versions and ensures that inter-related projects within a solution are either using the same version or compatible ones. This coordination is essential for projects that *depend* on each other, especially in a CI/CD environment. 394 | 395 | ### Global SDK vs. Local SDK 396 | 397 | The SDK version specified in the `global.json` usually supersedes the locally installed SDK version unless the local version is explicitly pinned, or there's a higher priority, such as in a project-specific `global.json` file. 398 | 399 | **When shared**, the `global.json` settings apply to all projects within its directory and those in subdirectories unless they have their own `global.json` files, which would then take precedence. 400 | 401 | **If you're pushing software to production**, always account for SDK versions and set up your CI/CD pipelines accordingly. For consistency and to guard against unintended version updates, you should generally specify the SDK versions in your build configurations, rather than relying solely on the local environment of the build agent or developer machines. 402 |
403 | 404 | ## 10. Can you explain the _Directory Structure_ of a typical _.NET Core project_? 405 | 406 | The directory structure of a typical .NET Core project is designed to keep code organized and manageable. 407 | 408 | ### Key Directories 409 | 410 | - **src**: Contains the core application and all of its modules. 411 | 412 | - **tests**: Houses unit, integration, or end-to-end test projects. 413 | 414 | - **docs**: For documentation files. 415 | 416 | - **artifacts**: Not always present, but used for build outputs (e.g., binaries). 417 | 418 | - **build**: For build-related scripts or files. 419 | 420 | - **.github**: GitHub-specific files like workflows or issue templates. 421 | 422 | - **.vscode**: Configurations specific to Visual Studio Code. 423 | 424 | ### Core Files 425 | 426 | - **global.json**: Might specify the version of the .NET SDK to use. 427 | 428 | - **.gitignore**: Lists files and folders to exclude from version control. 429 | 430 | - **.editorconfig**: Gives project-wide text editor settings. 431 | 432 | - **.wslconfig**: This is an optional file which you can create to configure the Windows Subsystem for Linux 433 | 434 | - **Dockerfile**: If the project uses Docker, this defines the container. 435 | 436 | - **Makefile**: Optional file used to automate tasks on Unix-based systems. 437 | 438 | ### Build-Related Files 439 | 440 | - **.editorconfig**: Provides consistent coding styles for multiple developers working across various editors and IDEs. 441 | 442 | - **global.json**: Helps specify the SDK version used for the project. 443 | 444 | - **MyApp.sln**: Solution file associated with Visual Studio, listing project dependencies and configurations. 445 | 446 | - **nuget.config**: Configures NuGet package sources. 447 | 448 | - **local-mira-tool.manifest**: Specifies the version targeted by Mira, a cross-platform CLI. 449 | 450 | ### Dynamic/Generated Files 451 | 452 | - **appsettings.json**: JSON configuration file translated to `Configuration` objects. 453 | 454 | - **appsettings.Development.json**: App-specific data for the Development environment. 455 | 456 | - **appsettings.Production.json**: Environment-specific data for the Production environment. 457 | 458 | - **MyApp.deps.json**: Dependency details. 459 | 460 | - **MyApp.runtimeconfig.json**: Runtime-related information like shared frameworks and native libraries. 461 | 462 | ### Version Control 463 | 464 | - **.git**: Git repository. 465 | 466 | - **.gitattributes**: Used to customize how versions of files should be handled. 467 | 468 | - **.gitignore**: Lists files and folders to be excluded from version control. 469 |
470 | 471 | ## 11. How do you add and manage _NuGet packages_ in a _.NET Core project_? 472 | 473 | Working with **NuGet** in a **.NET Core** project is seamless, thanks to Visual Studio and the dotnet CLI. Whether you're a fan of the GUI or prefer command-line superiority, you can manage NuGet packages without breaking a sweat. 474 | 475 | ### Using NuGet Package Manager UI 476 | 477 | 1. **Locate NuGet Package Manager**: 478 | - In Visual Studio, access it via `Project > Manage NuGet Packages...`. 479 | 480 | 2. **Browse for Packages**: 481 | - Look for packages in the NuGet.org online repository under the "Browse" tab. 482 | 483 | 3. **Install Packages**: 484 | - Click "Install" for the desired package. 485 | 486 | 4. **Verify Installations**: 487 | - Check the "Installed" tab to see the installed packages. 488 | 489 | #### Useful Tips 490 | 491 | - **Version Management**: Click on the installed package to see other available versions. 492 | 493 | - **Updating Packages**: Navigate to the "Updates" tab to see which packages have newer versions. 494 | 495 | - **Uninstalling**: Use the "Installed" tab to remove packages. 496 | 497 | ### Managing Packages via .NET CLI 498 | 499 | Use the `dotnet add package` and `dotnet remove package` commands. 500 | 501 | #### Syntax 502 | 503 | - **Add Package**: 504 | ```bash 505 | dotnet add package PackageName 506 | ``` 507 | - **Remove Package**: 508 | ```bash 509 | dotnet remove package PackageName 510 | ``` 511 | 512 | - **Update Package**: 513 | ```bash 514 | dotnet add package PackageName --version 1.2.3 515 | ``` 516 | 517 | 518 | #### Using Private Feeds 519 | 520 | - **Configuring**: In `nuget.config`, define the source, or use `-s`/`--source` in the CLI. E.g.: 521 | ```bash 522 | dotnet add package CompanyPackage --source https://NuGetServer.com/nuget/MyPrivateFeed/ 523 | ``` 524 | 525 | **Authentication**: For authenticated feeds, use `.config` files or `-k`/`--api-key` along with the command. 526 | 527 | 528 | ### Using NuGet.Config 529 | 530 | - **Creating**: Use the `new` command to create a config file in your solution folder: 531 | ```bash 532 | dotnet new nugetconfig 533 | ``` 534 | 535 | - **Configuring Sources**: With the `add source` command: 536 | ```bash 537 | dotnet nuget add source https://AnotherFeed.com/v3/index.json --name AnotherFeed 538 | ``` 539 | 540 | And to remove a source: 541 | ```bash 542 | dotnet nuget remove source AnotherFeed 543 | ``` 544 | 545 | - **Setting Default Push Source**: Utilize the `push` command: 546 | ```bash 547 | dotnet nuget push -t API_KEY MyPackage.1.0.0.nupkg 548 | ``` 549 | Use the `-s`/`--source` switch to specify the desired push source. 550 | 551 | ### Docker and NuGet 552 | 553 | To use a cache layer when adding packages in a Docker container, first retrieve and add the `.csproj` file to the container before executing the `dotnet restore` command. This approach speeds up the build process. 554 | 555 | #### Dockerfile Example 556 | 557 | ```Dockerfile 558 | # Copy .csproj and nuget.config and restore as distinct layers 559 | COPY nuget.config ./ 560 | COPY Orcha.csproj ./ 561 | RUN dotnet restore 562 | ``` 563 |
564 | 565 | ## 12. Explain the role of the _NuGet package manager_. 566 | 567 | The **NuGet Package Manager** simplifies the process of integrating external libraries and components into your project. It's a core element in the Microsoft toolchain and is closely integrated with .NET Core, Visual Studio, and Visual Studio Code. 568 | 569 | ### Key NuGet Package Manager Capabilities 570 | 571 | 1. **Package Management**: NuGet serves as a centralized repository for .NET packages, where developers can easily search, discover, and install packages. 572 | 573 | 2. **Dependency Management**: NuGet tracks and resolves dependencies between packages, ensuring that all required components are downloaded and installed. 574 | 575 | 3. **Version Control**: Different versions of the same package are maintained, giving developers flexibility in choosing the most suitable one for their project. 576 | 577 | 4. **Project Scopes**: NuGet allows you to define packages at various levels such as the global package store, the project-local store, or as a package reference within a project file. 578 | 579 | 5. **Commands via CLI**: Besides GUI integration, NuGet supports a powerful command-line interface for streamlined package management. 580 | 581 | 6. **Publishing Packages**: It facilitates package creators in distributing their libraries to the global NuGet repository for wider consumption. 582 | 583 | 7. **Extensibility**: NuGet allows for easy management of third-party tools and integrations, beyond just code libraries. 584 | 585 | ### NuGet in Action: A Simple Example 586 | 587 | Here is what you should do: 588 | 589 | - In Visual Studio, open a .NET Core project. 590 | - Right-click on the project in the Solution Explorer and choose "Manage NuGet Packages". 591 | - Click on "Browse" and search for "Newtonsoft.Json", a commonly used JSON parsing library. 592 | - Click "Install" to add the package to your project. 593 | 594 | This will modify your project file, adding a `` to `Newtonsoft.Json` and any of its dependencies. 595 |
596 | 597 | ## 13. Describe the process of _publishing a .NET Core application_. 598 | 599 | When publishing a **.NET Core application**, you compile it and its dependencies for deployment. .NET Core supports various publishing methods and configurations to cater to your specific requirements. 600 | 601 | ### Various Publishing Methods 602 | 603 | 1. **Framework-Dependent**: Publishes the app without the .NET Core runtime. It indicates which version to use on the target system. The app will only run on systems with matching or newer .NET Core runtimes. 604 | 605 | 2. **Self-Contained**: Packages the app with the .NET Core runtime, allowing it to run on systems without an existing .NET Core installation. 606 | 607 | 3. **Portable**: Typically suitable for use-cases like USB flash or external drives. 608 | 609 | 4. **Ready-To-Run**: Optimizes the app startup time by pre-compiling specific libraries to native code. RTR has the added benefit of being useful for promoting cross-gen and unification common. Thus, **RTR Is the default for these modes vs traditional JIT**. 610 | 611 | ### Publishing Commands 612 | 613 | The Dotnet Command Line produces build artifacts onto the file system. 614 | 615 | - **dotnet build** compiles the app. 616 | - **dotnet publish** copies necessary files to a target path, to make it ready for deployment. 617 | 618 | ### Project Files for Publishing 619 | 620 | The following configuration settings can be specified in your project file to influence the publish process: 621 | 622 | - **PublishWithAspNetCoreTargetManifest**: For web apps, this setting specifies whether the app should be published with or without an AspNetCore target manifest. 623 | 624 | - **PublishTrimmed**: When set to 'true', minimizes the number of assemblies included in the published output based on necessary. This improves performance & size. 625 | 626 | 627 | 628 | An example DOTNET CLI command for publishing a self-contained app would look like this: 629 | 630 | ```sh 631 | dotnet publish -c Release --self-contained --runtime linux-x64 632 | ``` 633 | 634 | And for ready-to-run (RTR), it would be: 635 | 636 | ```sh 637 | dotnet publish -c Release --runtime linux-x64 --self-contained false --output rtr/path 638 | ``` 639 | 640 | When the **Ready-To-Run** is specified, the `--self-contained` and `--output` are disabled. 641 | 642 | For deploying to Linux or Windows in **framework-dependent** mode: 643 | 644 | 645 | 646 | ```sh 647 | dotnet publish -c Release --runtime linux-x64 648 | ``` 649 | 650 | ```sh 651 | dotnet publish -c Release --runtime win-x64 652 | ``` 653 | 654 | ### Repositories, NuGet & Web 655 | 656 | 657 | 658 | - **Repository**: Useful for sharing the project's source code publicly. Code hosting platforms such as GitHub, GitLab or Bitbucket support repository management. 659 | 660 | - **NuGet Package**: Ideal for publishing libraries as it simplifies their consumption. Once you've published a library to NuGet, others can include it as a dependency in their projects. 661 | 662 | - **Web Host**: For web applications and services, hosting them with a web server is essential. When you deploy to a web server, ensure your web.config file is correctly configured for its needs. Additionally, when using Kestrel, ensure it's accessible through a proxy server. 663 |
664 | 665 | ## 14. What is a _.NET Standard_ and how does it relate to _.NET Core_? 666 | 667 | **.NET Standard** serves as a formalized set of APIs, ensuring cross-compatibility among different .NET implementations. Essentially, it is a standardized interface that abstracts from the underlying platform. 668 | 669 | ### Motivation for .NET Standard 670 | 671 | Before .NET Standard, developers had to detect and account for the specific platform they were targeting, such as UWP or different versions of .NET Framework. This diversity resulted in interoperability challenges. 672 | 673 | By establishing a standardized target across .NET implementations, **.NET Standard** simplifies multi-platform development, making it more cohesive and intuitive. 674 | 675 | ### Evolution of Development Platforms 676 | 677 | While '.NET Core' and '.NET Framework' cater to specific use cases, **.NET Standard** essentially aims for cross-compatibility. As of 2020, Microsoft advocated for using '.NET Core' for newer projects. 678 | 679 | Here is the overview: 680 | 681 | - **.NET Framework**: It's a mature, all-in-one development platform for Windows-based applications. 682 | - **.NET Core**: A streamlined, open-source platform shattering Windows allegiance, targeting both Windows and non-Windows systems. 683 | - **.NET 5**: A unification of ".NET Core" and ".NET Framework". 684 | - **.NET 6 **: The next leap, evolving further from ".NET 5". 685 | 686 | Given this diverse landscape, **.NET Standard** acts as an umbrella platform with defined capabilities and APIs, ensuring consistent behavior across different .NET implementations. 687 |
688 | 689 | ## 15. How do you create a _class library_ in _.NET Core_? 690 | 691 | To create a **Class Library** in .NET Core, you can use either Visual Studio or the `dotnet` command-line interface. 692 | 693 | ### Using Visual Studio 694 | 695 | - Open Visual Studio. 696 | - Select "Create a new project". 697 | - Choose the "Class Library" template under the "C#" or appropriate language heading. 698 | - Specify the project name and location. 699 | - Click "Create". 700 | 701 | ### Using the .NET CLI 702 | 703 | 1. **Create the Project**: Open a terminal and navigate to the desired directory. Run the following command: 704 | 705 | ```bash 706 | dotnet new classlib -n MyLibrary 707 | ``` 708 | 709 | Replace `MyLibrary` with your preferred project name. 710 | 711 | The above command will generate a `.csproj` file, which is the project file for the class library. 712 | 713 | 2. **Configure the Project Reference**: 714 | 715 | You can either manually add the reference or use the `dotnet add reference` command. Manually, you would do this editing the `.csproj` file: 716 | 717 | ```xml 718 | 719 | 720 | 721 | ``` 722 | 723 | Using the command line: 724 | 725 | ```bash 726 | dotnet add reference ..\Path\To\AnotherProject.csproj 727 | ``` 728 | 729 | This connects your class library to your other projects or external libraries. 730 | 731 | ### Visual Studio Code 732 | 733 | You can create a class library in Visual Studio Code using the .NET CLI. Here is how: 734 | 735 | 1. **Initialize the Project Folder**: 736 | 737 | Open the terminal in the desired directory and run: 738 | 739 | ```bash 740 | dotnet new sln -n MySolution 741 | ``` 742 | 743 | Replace `MySolution` with your preferred name. 744 | 745 | 2. **Create the Library Project**: 746 | 747 | Run the following commands in the terminal: 748 | 749 | ```bash 750 | dotnet new classlib -n MyLibrary -o MyLibrary 751 | ``` 752 | 753 | This creates a new directory named `MyLibrary` and initializes it as a class library. 754 | 755 | 3. **Add the Library to the Solution**: 756 | 757 | To include the library in the solution, run: 758 | 759 | ```bash 760 | dotnet sln add MyLibrary/MyLibrary.csproj 761 | ``` 762 | 763 | 4. **Link to Other Projects or Libraries**: 764 | 765 | You can **add a project reference**: 766 | 767 | ```bash 768 | dotnet add reference ..\Path\To\AnotherProject.csproj 769 | ``` 770 | 771 | Or **add a package reference**: 772 | 773 | ```bash 774 | dotnet add package MyPackage 775 | ``` 776 | 777 | 5. **Build the Solution**: 778 | 779 | To ensure everything is linked up correctly, build the solution with: 780 | 781 | ```bash 782 | dotnet build 783 | ``` 784 | 785 | The class library and any linked projects should build without errors. 786 |
787 | 788 | 789 | 790 | #### Explore all 100 answers here 👉 [Devinterview.io - .Net Core](https://devinterview.io/questions/web-and-mobile-development/net-core-interview-questions) 791 | 792 |
793 | 794 | 795 | web-and-mobile-development 796 | 797 |

798 | 799 | --------------------------------------------------------------------------------