Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions .claude/commands/DotnetVersion.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
You are a specialist in .NET projects.

Scan the entire repository and locate all `.csproj` files.

For each file:
1. Find the `<TargetFramework>` or `<TargetFrameworks>` element.
2. Extract the .NET version(s) defined inside it.

Then return a structured JSON output in this format:

{
"projects": [
{
"project_file": "path/to/project.csproj",
"language_version": "netX.X"
}
]
}

Rules:
- If `<TargetFrameworks>` contains multiple values (e.g., `net6.0;net8.0`), return them as an array.
- If no target framework is found, set `"language_version"` to `"unknown"`.
- Do not include any explanation or extra text — return ONLY valid JSON.
54 changes: 54 additions & 0 deletions .claude/commands/MPlan.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
You are a senior .NET engineer specialized in framework version upgrades.

Perform a full scan of this repository and identify all .NET-related projects and components.

Your goal is to plan a **strict framework version migration to .NET 9 only**.
Do NOT propose architectural changes, performance improvements, new features, or code refactoring unless strictly required for compatibility with .NET 9.

Analyze:
- All `.csproj` files and their current target frameworks.
- NuGet package versions and compatibility with .NET 9.
- SDK and runtime dependencies.
- CI/CD configurations and build scripts.
- Docker and deployment configurations.

Then generate a file named `MigrationPlan.md` at the repository root with the following structure:

## 1. Current State
- List of all projects and their current `<TargetFramework>` or `<TargetFrameworks>`.
- Current .NET SDK references and usage.

## 2. Migration Scope
- Explicitly state that this is **a version-only migration**.
- List what is **in scope** and what is **out of scope**.

## 3. Required Changes
Only include changes required to make the solution compile and run on .NET 9:
- TargetFramework updates.
- NuGet package updates (only if incompatible).
- SDK version updates (global.json, pipelines, Docker).
- Build and publish changes.

## 4. Migration Steps
Provide a clear step-by-step incremental plan:
1. Update target frameworks.
2. Update SDK/runtime references.
3. Fix breaking changes strictly required for compilation/runtime.
4. Update pipelines and containers.
5. Run and validate tests.

## 5. Risks & Compatibility Notes
- Known breaking changes from previous .NET versions to .NET 9.
- Potential risks of blocking dependencies.

## 6. Validation
- Build validation steps.
- Basic runtime validation.
- Rollback strategy.

Constraints:
- Do NOT suggest feature improvements.
- Do NOT modify architecture or structure.
- Keep suggestions minimal and strictly necessary.
- All decisions must be based only on project analysis.
- Output ONLY the `MigrationPlan.md` file.
2 changes: 1 addition & 1 deletion .github/workflows/dotnetcore.yml
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,6 @@ jobs:
- name: Setup .NET Core
uses: actions/setup-dotnet@v2
with:
dotnet-version: '6.0.x'
dotnet-version: '9.0.x'
- name: Build with dotnet
run: dotnet build --configuration Release
115 changes: 115 additions & 0 deletions CLAUDE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,115 @@
# CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

## Project Overview

This is an ASP.NET Core 6.0 Web API sample demonstrating RESTful API design with HATEOAS (Hypermedia as the Engine of Application State), API versioning, and Swagger documentation. The API manages a simple Food items resource with full CRUD operations.

## Build and Run Commands

### Build
```bash
dotnet build --configuration Release
```

### Run (Development)
```bash
dotnet run --project SampleWebApiAspNetCore/SampleWebApiAspNetCore.csproj
```

The API runs on `http://localhost:29435` by default.

### Access Swagger UI
Navigate to `http://localhost:29435/swagger` when running in Development mode.

## Architecture

### Project Structure
- **Controllers/**: API endpoints organized by version (v1/, v2/)
- **Repositories/**: Data access layer with `IFoodRepository` interface and `FoodSqlRepository` implementation
- **Services/**: Business logic services (e.g., `ISeedDataService` for test data)
- **Entities/**: Database entities (e.g., `FoodEntity`)
- **Dtos/**: Data Transfer Objects (`FoodDto`, `FoodCreateDto`, `FoodUpdateDto`)
- **Models/**: Domain models (e.g., `QueryParameters`, `LinkDto`)
- **MappingProfiles/**: AutoMapper configuration (e.g., `FoodMappings`)
- **Helpers/**: Extension methods for cross-cutting concerns

### Key Architectural Patterns

**Dependency Injection**: Services are registered in `Program.cs`:
- `IFoodRepository` → `FoodSqlRepository` (Scoped)
- `ISeedDataService` → `SeedDataService` (Singleton)
- AutoMapper with `FoodMappings` profile

**Repository Pattern**: Data access is abstracted through `IFoodRepository` interface. The implementation uses Entity Framework Core with an in-memory database (`UseInMemoryDatabase("FoodDatabase")`).

**API Versioning**: Configured via `VersioningExtension.AddVersioning()`:
- URL segment versioning: `/api/v1/foods`, `/api/v2/foods`
- Header versioning: `x-api-version` header
- Media type versioning: `x-api-version` in Accept/Content-Type
- Default version: 1.0
- Controllers use `[ApiVersion("1.0")]` or `[ApiVersion("2.0")]` attributes
- Routes use `[Route("api/v{version:apiVersion}/[controller]")]`

**HATEOAS Implementation**:
- v1 FoodsController includes hypermedia links in responses
- `ExpandSingleFoodItem()` adds `links` array to each resource
- `CreateLinksForCollection()` provides navigation links (self, first, last, next, previous)
- Links use named routes (e.g., `nameof(GetSingleFood)`)
- The `LinkDto` model represents hypermedia links
- `DynamicExtensions.ToDynamic()` converts DTOs to expandable objects for adding links

**Pagination**: Handled via `QueryParameters` model:
- `Page`: Current page number (default: 1)
- `PageCount`: Items per page (max: 50, default: 50)
- `OrderBy`: Sort field (default: "Name")
- Pagination metadata returned in `X-Pagination` response header
- Dynamic sorting via `System.Linq.Dynamic.Core` library

**Filtering**: QueryParameters supports text search via `Query` property. The repository searches both `Name` and `Calories` fields.

**AutoMapper**: Maps between Entities and DTOs:
- `FoodEntity` ↔ `FoodDto` / `FoodCreateDto` / `FoodUpdateDto`
- Configuration in `MappingProfiles/FoodMappings.cs`

**JSON Patch**: PATCH endpoint (`PartiallyUpdateFood`) uses `JsonPatchDocument<FoodUpdateDto>` from `Microsoft.AspNetCore.JsonPatch` for partial updates.

**CORS**: Configured via `CorsExtension.AddCustomCors("AllowAllOrigins")` - allows all origins in this sample.

**Seed Data**: In Development mode, `SeedDataExtension.SeedData()` populates the in-memory database with test food items.

### Response Patterns

**v1 API responses** include:
- `value`: Array of resources or single resource with embedded HATEOAS links
- `links`: Array of `LinkDto` objects for navigation

**Pagination metadata** (in `X-Pagination` header):
```json
{
"totalCount": 20,
"pageSize": 10,
"currentPage": 1,
"totalPages": 2
}
```

## Key Dependencies

- **Microsoft.EntityFrameworkCore.InMemory**: In-memory database provider
- **AutoMapper**: Object-to-object mapping
- **Microsoft.AspNetCore.Mvc.Versioning**: API versioning
- **Swashbuckle.AspNetCore**: Swagger/OpenAPI generation
- **Microsoft.AspNetCore.Mvc.NewtonsoftJson**: JSON PATCH support
- **System.Linq.Dynamic.Core**: Dynamic LINQ for runtime query construction

## Development Notes

**Configuration**: Settings in `appsettings.json` and `appsettings.Development.json`.

**Exception Handling**: Production mode uses `ExceptionExtension.AddProductionExceptionHandling()` for centralized error handling.

**Swagger Configuration**: `ConfigureSwaggerOptions` class implements `IConfigureOptions<SwaggerGenOptions>` to configure Swagger per API version.

**Routing**: Lowercase URLs enforced via `AddRouting(options => options.LowercaseUrls = true)`.
Loading
Loading