Appearance
Are you an LLM? You can read better optimized documentation at /reference/dependencies.md for this page in Markdown format
Project dependencies
This document provides a detailed breakdown of the NuGet packages and project dependencies that form the foundation of TheExampleApp. Understanding these components, their versions, and their roles is crucial for maintaining and extending the application. For a higher-level view of the application's structure, please refer to the Application Overview.
NuGet packages
The application and its associated test suites are organized into multiple projects within the solution, as defined in TheExampleApp.sln. Each project manages its own set of dependencies via its .csproj file. This section details the key packages used across the solution.
To restore all dependencies, run the following command from the solution's root directory:
bash
dotnet restore TheExampleApp.sln1
Core framework
The application is built on the .NET Core 2.1 framework, which provides the fundamental runtime and libraries for the backend.
The core application project, TheExampleApp.csproj, specifies the target framework and the primary ASP.NET Core metapackage.
xml
<!-- TheExampleApp/TheExampleApp.csproj -->
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<!-- The application targets .NET Core 2.1 -->
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<!-- This metapackage bundles the entire ASP.NET Core framework,
including MVC, Kestrel, logging, and configuration. -->
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.1.5" />
...
</ItemGroup>
...
</Project>1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
netcoreapp2.1: This is the target framework moniker (TFM). All code is compiled against the .NET Core 2.1 SDK.Microsoft.AspNetCore.All(v2.1.5): This is a framework-dependent metapackage that references all supported packages by the ASP.NET Core and Entity Framework Core teams. While convenient, it means the application may reference libraries it doesn't explicitly use (e.g., SQL Server drivers). This is a key characteristic of the 2.x metapackage approach. For a list of required SDKs and tools, see the Prerequisites documentation.
Contentful
The application operates on a headless architecture, sourcing all of its display content from Contentful. The integration is managed by the official Contentful SDK for ASP.NET Core.
xml
<!-- TheExampleApp/TheExampleApp.csproj -->
<ItemGroup>
...
<!-- The primary SDK for fetching content from the Contentful Delivery API. -->
<PackageReference Include="contentful.aspnetcore">
<Version>3.3.6</Version>
</PackageReference>
...
</ItemGroup>1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
contentful.aspnetcore(v3.3.6): This package provides the core services for interacting with the Contentful API. Its responsibilities include:- Client creation and configuration via dependency injection.
- Fetching entries, assets, and content types.
- Mapping Contentful content models to strongly-typed C# POCOs.
- Handling API authentication and request serialization.
The SDK is configured in Startup.cs using credentials and space information from the application's configuration. For details on the required configuration keys, refer to the Configuration Reference.
Utilities
Several utility libraries are included to handle common tasks like data processing and rendering.
Markdown Processing
Content fields from Contentful are often authored in Markdown. The Markdig library is used to parse this Markdown into HTML for server-side rendering within Razor views.
xml
<!-- TheExampleApp/TheExampleApp.csproj -->
<ItemGroup>
...
<!-- A fast, powerful, and CommonMark-compliant Markdown processor for .NET. -->
<PackageReference Include="Markdig">
<Version>0.15.4</Version>
</PackageReference>
...
</ItemGroup>1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
Markdig(v0.15.4): This library is highly performant and extensible. It is typically invoked within a view model or a dedicated service to transform a raw Markdown string into an HTML string before it is rendered by Razor.
JSON Serialization
While not directly referenced in TheExampleApp.csproj, Newtonsoft.Json is a critical transitive dependency brought in by Microsoft.AspNetCore.All and contentful.aspnetcore. It is the default JSON serializer for ASP.NET Core 2.1 and is used for:
- Serializing and deserializing API requests/responses.
- Processing JSON-based configuration files.
- Handling the JSON payloads from the Contentful API.
Note: Developers should be aware that this project relies on
Newtonsoft.Json. This is in contrast to modern .NET applications which default toSystem.Text.Json. Any custom JSON serialization logic must use theNewtonsoft.JsonAPIs.
Development tools
The project includes tools to aid in development, primarily for code scaffolding and Razor compilation. These are development-time dependencies and are not deployed with the application.
xml
<!-- TheExampleApp/TheExampleApp.csproj -->
<ItemGroup>
...
<!-- Provides the Razor language services and compilation infrastructure. -->
<PackageReference Include="Microsoft.AspNetCore.Razor.Language" Version="2.1.2" />
<!-- Provides design-time functionality for scaffolding in Visual Studio. -->
<PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Design">
<Version>2.1.5</Version>
</PackageReference>
</ItemGroup>
<ItemGroup>
<!-- Enables the 'dotnet aspnet-codegenerator' CLI tool. -->
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
Microsoft.AspNetCore.Razor.Language(v2.1.2): This package provides the Razor language services and compilation infrastructure, enabling design-time support for Razor views.Microsoft.VisualStudio.Web.CodeGeneration.Design(v2.1.5): This package enables the scaffolding engine used by Visual Studio to create new controllers, views, and other items.DotNetCliToolReference: This entry registers thedotnet aspnet-codegeneratorcommand-line tool, allowing for scaffolding from the terminal.
Testing
The solution employs a multi-layered testing strategy, with dedicated projects for unit, integration, and end-to-end (E2E) tests. For a comprehensive guide on the testing philosophy and execution, see the Testing Overview.
Unit Tests (TheExampleApp.Tests)
Unit tests focus on isolating and testing individual components in memory.
xml
<!-- TheExampleApp.Tests/TheExampleApp.Tests.csproj -->
<ItemGroup>
<!-- The core test SDK. -->
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.5.0" />
<!-- A popular mocking framework for creating test doubles. -->
<PackageReference Include="Moq" Version="4.7.145" />
<!-- The xUnit testing framework. -->
<PackageReference Include="xunit" Version="2.3.1" />
<!-- The test runner for Visual Studio. -->
<PackageReference Include="xunit.runner.visualstudio" Version="2.3.1" />
</ItemGroup>1
2
3
4
5
6
7
8
9
10
11
2
3
4
5
6
7
8
9
10
11
xunit: The core testing framework used for defining and running tests.Moq: Used to create mock objects for dependencies (e.g., mocking the Contentful client) to ensure tests are isolated.
Integration Tests (TheExampleApp.IntegrationTests)
Integration tests verify the interactions between components by running the application in-memory.
xml
<!-- TheExampleApp.IntegrationTests/TheExampleApp.IntegrationTests.csproj -->
<ItemGroup>
<!-- Provides an in-memory test server for ASP.NET Core applications. -->
<PackageReference Include="Microsoft.AspNetCore.TestHost" Version="2.0.1" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.5.0" />
<PackageReference Include="xunit" Version="2.3.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.3.1" />
</ItemGroup>
<ItemGroup>
<!-- References the main application to test its components. -->
<ProjectReference Include="..\TheExampleApp\TheExampleApp.csproj" />
</ItemGroup>1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
Microsoft.AspNetCore.TestHost: This is the key package for integration testing. It allows the entire application pipeline (middleware, routing, controllers, filters) to be hosted in-memory, enabling tests to make HTTP requests to the application without needing to deploy it to a real web server.- Project Reference: The integration test project references the main
TheExampleAppproject, allowing it to test the application's components and configuration in an integrated manner.
End-to-End Tests (TheExampleApp.E2eTests)
E2E tests validate the application from the user's perspective by automating a real web browser.
xml
<!-- TheExampleApp.E2eTests/TheExampleApp.E2eTests.csproj -->
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.5.0" />
<!-- The .NET bindings for the Selenium WebDriver browser automation framework. -->
<PackageReference Include="Selenium.WebDriver" Version="3.7.0" />
<PackageReference Include="xunit" Version="2.3.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.3.1" />
</ItemGroup>
<ItemGroup>
<!-- Ensures the Chrome driver is available at runtime. -->
<None Update="chromedriver">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
<None Update="chromedriver.exe">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
</ItemGroup>1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Selenium.WebDriver(v3.7.0): Provides the APIs to control a web browser programmatically.- Chrome Driver: The project includes both
chromedriver(for Linux/macOS) andchromedriver.exe(for Windows), configured to be copied to the output directory. This indicates that the E2E tests are designed to run against the Google Chrome browser across different platforms. The test runner will expect the appropriate executable to be available in its path.