If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/dotnet-architecture/eShopOnContainers shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

AVOID — Stale and unlicensed — last commit 2y ago

• 12 active contributors
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 66% of recent commits
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live dotnet-architecture/eShopOnContainers repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/dotnet-architecture/eShopOnContainers.

What it runs against: a local clone of dotnet-architecture/eShopOnContainers — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in dotnet-architecture/eShopOnContainers | Confirms the artifact applies here, not a fork | | 2 | Default branch repo_moved exists | Catches branch renames | | 3 | 1 critical file path still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 936 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of dotnet-architecture/eShopOnContainers. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/dotnet-architecture/eShopOnContainers.git
#   cd eShopOnContainers
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of dotnet-architecture/eShopOnContainers and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "dotnet-architecture/eShopOnContainers(\\.git)?\\b" \\
  && ok "origin remote is dotnet-architecture/eShopOnContainers" \\
  || miss "origin remote is not dotnet-architecture/eShopOnContainers (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify repo_moved >/dev/null 2>&1 \\
  && ok "default branch repo_moved exists" \\
  || miss "default branch repo_moved no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 936 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~906d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/dotnet-architecture/eShopOnContainers"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

eShopOnContainers is a reference microservices architecture sample built on .NET 7 demonstrating cross-platform containerized e-commerce workloads. It showcases Docker containerization, Kubernetes orchestration, and distributed system patterns across independently deployable services (catalog, ordering, basket, identity) that communicate via message buses and APIs, running on Linux, Windows, and macOS. Microservices monorepo: src/Services/ contains isolated Catalog.API, Ordering.API, Identity.API, and Basket.API services each with their own DbContext and domain models; src/Web/ holds ASP.NET Core MVC and SPA (JavaScript/TypeScript) frontends; docker-compose.yml orchestrates local multi-container development; kubernetes/ folder contains Helm charts and YAML manifests for AKS deployment.

.NET architects and senior developers learning microservices patterns, container orchestration, and cloud-native design; teams evaluating Azure Kubernetes Services deployment strategies; enterprise .NET shops modernizing monolithic applications into service-oriented architectures.

This repository is now read-only archived as of November 2023—active development has moved to https://github.com/dotnet/eShop. The 'dev' branch contains the final stable code from the original location. It was mature and production-representative when active, but is no longer receiving updates or bug fixes in this location.

Standard open source risks apply.

Nothing—this repository is frozen at the November 2023 archival point. All active development, bug fixes, and feature work has moved to the https://github.com/dotnet/eShop repository. This 'dev' branch preserves the historical codebase for reference only.

git clone https://github.com/dotnet-architecture/eShopOnContainers.git && cd eShopOnContainers && git checkout dev && docker-compose up -d (for local containerized environment) OR dotnet build && dotnet run (for .NET CLI). Requires Docker Desktop, .NET 7 SDK, and 8GB+ RAM for multi-service startup.

Daily commands: Local development: docker-compose -f docker-compose.yml -f docker-compose.override.yml up -d (launches all services + dependencies on localhost). Access web UI at http://localhost:5100. For .NET CLI: dotnet run --project src/Services/Catalog/Catalog.API/Catalog.API.csproj. For Kubernetes: kubectl apply -f kubernetes/ (requires AKS cluster + Helm pre-installed).

• README.md — Explains that this repository has been archived and moved to https://github.com/dotnet/eShop; all contributors must read this to understand the project is no longer active here.

• Microservices (archived reference) (.NET 7, Docker, Kubernetes) — Multiple bounded domain services communicating via APIs in a distributed system architecture
  • Failure mode: Individual service failure is isolated; orchestration platform (AKS) handles restart and recovery

Add API endpoint: edit src/Services/{ServiceName}/{ServiceName}.API/Controllers/{Entity}Controller.cs. Add database entity: modify src/Services/{ServiceName}/{ServiceName}.API/Model/ and add EF migration via dotnet ef migrations add {MigrationName}. Update async messaging: edit event handlers in src/Services/{ServiceName}/{ServiceName}.API/IntegrationEvents/EventHandlers/. Frontend changes: src/Web/WebMVC/ for MVC views or src/Web/WebSPA/ for single-page app code.

• .NET 7 — Cross-platform runtime for microservices running on Linux, Windows, and macOS
• Docker Containers — Containerization for consistent deployment and microservice isolation
• Azure Kubernetes Services — Orchestration and scaling of containerized microservices

• Repository archived and moved to new location
  • Why: Consolidation under official .NET organization for better maintenance and discoverability
  • Consequence: Old repository is now read-only; all active development and issues must reference the new repo at https://github.com/dotnet/eShop

• This repository is no longer active; it is an archived read-only reference

• Largest file: README.md (12 lines)
• Estimated quality issues: ~0 — No source code to analyze; repository is a read-only archive

RabbitMQ and Redis must be running before API services will start—docker-compose handles this, but manual .NET runs will fail silently on messaging. SQL Server requires sa password matching MSSQL_SA_PASSWORD env var (default 'Pass@word' in docker-compose.override.yml—do not use in production). IdentityServer4 token authority URL must match deployment endpoint or authentication will fail across services. Entity Framework migrations must be applied before first run: dotnet ef database update. The web frontend expects APIs on localhost:5100+ (hardcoded in config)—change appsettings.json ServiceUrls for non-local deployments. Azure deployment requires pre-configured Azure Container Registry, Azure SQL, and service principal with AKS contributor role.

• Microservices Architecture — eShop's entire design is built on the microservices pattern with independently deployable Catalog, Ordering, Basket, and Identity services—understanding service boundaries, communication, and deployment independence is essential
• Event-Driven Architecture with RabbitMQ — Services in eShop communicate asynchronously via RabbitMQ pub/sub integration events (e.g., OrderCreated, PaymentSucceeded) rather than synchronous calls—critical for loose coupling and scaling
• API Gateway Pattern (Ocelot) — eShop uses Ocelot to route external client requests to internal microservices, aggregate responses, and enforce cross-cutting concerns—understanding this pattern prevents client coupling to service topology
• Distributed Transactions with Saga Pattern — The Ordering service implements saga pattern for multi-step workflows (order → payment → inventory) across services without distributed ACID transactions—essential for microservice data consistency
• Container Orchestration with Kubernetes — eShop's kubernetes/ folder demonstrates Helm charts, YAML manifests, and service discovery on AKS—required knowledge for production deployment and horizontal scaling
• Resilience Patterns (Circuit Breaker, Retry) — eShop integrates Polly for fault handling between services—critical for handling transient failures and cascading outages in distributed systems
• Entity Framework Core with DbContext per Service — Each eShop microservice owns its DbContext and database—understanding this bounded context pattern and data isolation is key to microservice data architecture

• dotnet/eShop — The official active continuation of this project post-November 2023; use this for current development and support instead of this archived repo
• aspnet/AspNetCore.Docs — Official Microsoft documentation for ASP.NET Core microservices patterns, Entity Framework, and Kubernetes deployment referenced throughout eShop
• dotnet/aspnetcore — Core ASP.NET framework and runtime this architecture depends on; relevant for understanding dependency injection, configuration, and middleware patterns
• IdentityServer/IdentityServer4 — The OAuth2/OIDC provider library integrated in eShop's Identity service for cross-service authentication and authorization
• OcelotProjets/Ocelot — The API Gateway pattern implementation used in eShop for request routing, rate limiting, and service composition

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create migration guide and archive documentation for the dev branch

Since this repo is now read-only and development has moved to dotnet/eShop, new contributors landing here will be confused. The README mentions old code is in the 'dev' branch but provides no guidance on understanding the archived state or migrating to the new repo. Adding a MIGRATION.md or ARCHIVE.md file with specific examples of what changed, where components moved to, and how to find equivalents in the new repo would significantly improve the contributor experience and reduce duplicate issues.

• [ ] Create ARCHIVE.md documenting the read-only status and timeline
• [ ] Add a 'Migration to dotnet/eShop' section mapping old src/ directories to new repo locations
• [ ] Include specific examples (e.g., 'Catalog microservice moved from src/Services/Catalog to...')
• [ ] Add troubleshooting section for common questions about finding specific features
• [ ] Link from README.md to the new ARCHIVE.md prominently

Add branch protection rules and automated read-only enforcement documentation

The repo states it's read-only but there's no documented enforcement mechanism or contribution policy for contributors who attempt PRs. Adding GitHub branch protection configuration (or documenting why it wasn't applied) and a CONTRIBUTING.md that explicitly states this is archived would prevent wasted effort by contributors submitting PRs and create clarity about the maintenance status.

• [ ] Create CONTRIBUTING.md with a prominent 'This repository is archived' notice at the top
• [ ] Document why PRs cannot be accepted and redirect to dotnet/eShop
• [ ] Add instructions for opening issues vs. archived repo limitations
• [ ] Document the GitHub Settings (branch protection, auto-lock, etc.) that enforce read-only state
• [ ] Include a 'For maintainers' section on how to manage the archived state

Create a comprehensive index/inventory document of microservices in the dev branch

While the repo is archived, the 'dev' branch still contains valuable reference code. However, there's no clear inventory of what microservices exist, their ports, dependencies, or key files. Creating a detailed ARCHITECTURE.md or SERVICES_INVENTORY.md that documents each microservice (Catalog, Ordering, Identity, Basket, etc.) with their locations in src/Services/, key entry points, and technology stack would help researchers and engineers understand the old architecture without having to manually explore the codebase.

• [ ] Document each microservice in src/Services/ with name, purpose, and port
• [ ] Add technology stack per service (ASP.NET Core, EF Core, etc.)
• [ ] Create a dependency graph showing inter-service communication patterns
• [ ] List key files per service (Program.cs, Startup.cs, DbContext, Controllers)
• [ ] Include Docker compose configuration references for local development reference

• Add Swagger/OpenAPI documentation to Ordering.API and Basket.API (both lack /swagger endpoints)—similar to Catalog.API's Swashbuckle setup in Startup.cs
• Implement retry + circuit-breaker tests for HttpClient calls in src/Web/WebMVC/ using Polly—currently no unit tests for resilience policy behavior
• Document Kubernetes ingress setup in README—kubernetes/ folder has YAML but deployment instructions for Azure Application Gateway routing are missing

The eShopOnContainers repository presents significant security concerns due to its archived status with no active maintenance or security updates as of November 2023. Critical dependency information was not provided for analysis, preventing thorough vulnerability assessment. The multi-microservice architecture with Docker/Kubernetes deployment introduces inherent complexity. Insufficient configuration files prevent evaluation of secrets management, container security, and network policies. This codebase should not be used for production without substantial security review and migration to the actively maintained dotnet/eShop repository. For any continued use, comprehensive security scanning and hardening is essential.

• High · Archived Repository with Outdated Dependencies — Repository root / README.md. The repository is marked as read-only archive as of November 2023 with active development moved to https://github.com/dotnet/eShop. This means security patches and updates are no longer being applied to this codebase. Dependencies may contain known vulnerabilities that will never be patched in this repository. Fix: Migrate to the actively maintained repository at https://github.com/dotnet/eShop. Do not use this archived version for production deployments.
• High · Insufficient Dependency Information for Analysis — Project dependencies (not provided). No package dependency files (project.csproj, packages.config, package-lock.json, etc.) were provided for analysis. This prevents identification of outdated or vulnerable NuGet packages and third-party dependencies that may be used throughout the microservices. Fix: Provide complete dependency manifests and run security scanning tools such as: dotnet list package --vulnerable, OWASP Dependency-Check, or Snyk to identify known vulnerabilities in all dependencies.
• Medium · Missing Security Configuration Details — Docker configuration and security settings (not provided). No Docker configuration files (Dockerfile, docker-compose.yml) or security configuration files (.env, appsettings.json) were provided. This prevents analysis of potential hardcoded secrets, insecure defaults, exposed ports, or missing security headers. Fix: Provide Docker and configuration files for security review. Ensure: 1) No hardcoded credentials in configs, 2) Use secrets management (Docker Secrets, Azure Key Vault), 3) Non-root containers, 4) Security headers configured, 5) Only necessary ports exposed.
• Medium · Microservices Architecture Complexity — Microservices architecture (src/). As a multi-microservice application with container deployment, the attack surface is significantly larger. Without visible security configurations, potential risks include: inter-service communication vulnerabilities, missing API authentication/authorization, and container network isolation issues. Fix: Implement: 1) Service-to-service authentication (mTLS/OAuth), 2) Network policies in Kubernetes, 3) API rate limiting, 4) Input validation on all service boundaries, 5) Security scanning in CI/CD pipeline.
• Medium · Lack of Observable Security Artifacts — Security policies and configurations (not found). No evidence of security-related files such as: SECURITY.md, vulnerability disclosure policy, security test configurations, SAST/DAST configurations, or container scanning policies. Fix: Implement: 1) SECURITY.md with vulnerability reporting process, 2) Automated security scanning in CI/CD, 3) Container image scanning, 4) SAST tools (SonarQube, Roslyn analyzers), 5) Regular dependency updates.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.