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/aspnet/Mvc 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.

GO — Healthy across all four use cases

• 13 active contributors
• Distributed ownership (top contributor 37% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 7y ago

_{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 aspnet/Mvc repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/aspnet/Mvc.

What it runs against: a local clone of aspnet/Mvc — 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 aspnet/Mvc | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | Last commit ≤ 2749 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of aspnet/Mvc. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/aspnet/Mvc.git
#   cd Mvc
#
# 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 aspnet/Mvc and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

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

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 2749 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~2719d)"
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/aspnet/Mvc"
  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).

ASP.NET Core MVC is a unified web framework that combines Model-View-Controller routing, RESTful Web API support, and Razor templating into a single coherent system for building server-side dynamic websites and HTTP services. It provides attribute-based routing, model binding, validation filters, and content negotiation across a single request pipeline, replacing the need for separate MVC, Web API, and Web Pages frameworks. Monorepo structure: src/ contains core framework code (routing, model binding, filters, view engines); benchmarkapps/ holds BasicApi and BasicViews sample applications for performance testing; build.cmd/build.sh orchestrate the CI pipeline. Solution files Mvc.sln and Mvc.NoFun.sln split test-free builds from full test suites.

C# developers building server-rendered web applications or REST APIs who need clean separation between controllers, views, and models with built-in dependency injection, validation, and routing. Primarily used by enterprise teams migrating from .NET Framework MVC 5 or building new greenfield ASP.NET Core applications.

This repository is archived and no longer actively developed — the project was moved to aspnet/AspNetCore in 2019. While the code is production-grade (extensive test coverage, CI pipelines via AppVeyor/VSTS), it receives no new commits or active maintenance. Use only for historical reference or understanding ASP.NET Core MVC architecture; depend on the AspNetCore monorepo instead.

This is a dead repository — no active maintenance, no security patches, no bug fixes. Any code pulled from here cannot receive updates. The framework layer itself is stable but coupled to specific ASP.NET Core versions (likely 2.x–3.x era). Merging into the AspNetCore monorepo means breaking changes may have occurred without corresponding updates here.

Nothing — this repo is archived. No active development, PRs, or issues being addressed. The README explicitly directs users to aspnet/AspNetCore for ongoing work.

git clone https://github.com/aspnet/Mvc.git
cd Mvc
./build.sh  # or build.cmd on Windows

Requires .NET SDK matching the archived ASP.NET Core version (likely 2.1–3.1 era). See Directory.Build.props for exact version constraints.

Daily commands: Execute build.sh (Linux/macOS) or build.cmd (Windows) from repo root. Runs full test suite plus builds benchmark apps. To run samples: cd benchmarkapps/BasicApi && dotnet run or cd benchmarkapps/BasicViews && dotnet run. See .vsts-pipelines/builds/ci-public.yml for exact pipeline steps.

• src/Microsoft.AspNetCore.Mvc.Core: Core routing, model binding, filters, and action result infrastructure — the foundation of request handling
• Directory.Build.props: Centralized version, NuGet metadata, and compiler settings for all projects in the monorepo
• .vsts-pipelines/builds/ci-public.yml: Defines the official CI/CD pipeline: build, test, and package steps
• benchmarkapps/BasicApi/Startup.cs: Canonical example of MVC service registration, dependency injection, and request pipeline configuration
• benchmarkapps/BasicViews/Controllers/HomeController.cs: Demonstrates view rendering, model passing, and Razor template consumption in a controller
• build.sh: Entry point for the build system; orchestrates compilation, test execution, and package creation

Core framework logic lives in src/ subdirectories organized by concern: routing (src/Microsoft.AspNetCore.Mvc.Core/Routing/), model binding (src/Microsoft.AspNetCore.Mvc.Core/ModelBinding/), validation filters. Benchmark apps in benchmarkapps/ demonstrate end-to-end usage. Add tests alongside code in parallel test/ directories (convention: test/Microsoft.AspNetCore.Mvc.Test/*).

Do not use this repo for new projects — it is archived. The .vsts-pipelines/ files reference internal Microsoft build agents (conditions like eq(variables['System.TeamFoundationCollectionUri'], 'https://devops.azure.com/dnceng/')) and will not run on GitHub Actions. Restore by .NET version requires exact alignment with Directory.Build.props (no floating versions). The monorepo merge to AspNetCore means APIs here may differ from current ASP.NET Core docs.

• Action Filters & Filter Pipeline — Filters (IAsyncActionFilter, IAsyncResultFilter, IExceptionFilter) intercept requests/responses; understanding the pipeline order and execution context is essential to implementing cross-cutting concerns like logging, authorization, and error handling in MVC apps
• Model Binding & Custom Binders — The framework automatically converts HTTP request data (query strings, form bodies, route parameters) to strongly-typed C# objects via IModelBinder; custom binders let you handle non-standard input formats (e.g., CSV, XML payloads)
• Attribute Routing vs. Convention Routing — MVC unifies two routing paradigms: [Route(...)] decorators on actions for REST APIs and MapControllerRoute(...) for convention-based URIs; knowing when to use each is critical for designing clean URL schemes and API contracts
• Content Negotiation & Output Formatters — A single action can return JSON, XML, or HTML depending on Accept headers via IOutputFormatter; the framework negotiates the best format, eliminating separate MVC/API controller logic
• Razor Template Engine & View Compilation — Views are C# compiled to classes, not interpreted; understanding Razor syntax, layout pages, and partial views is essential for rendering dynamic HTML without leaving the C# ecosystem
• Dependency Injection Container Integration — ASP.NET Core MVC is built around constructor injection via IServiceProvider; controllers, filters, and views all receive dependencies from the DI container, making testing and loose coupling central to the design
• Data Annotations & Model Validation — The [Required], [Range], [EmailAddress] attributes declaratively validate models; the framework automatically populates ModelState.IsValid, allowing unified validation across MVC views and Web APIs

• aspnet/AspNetCore — The active successor monorepo where MVC, Web API, and Core have merged; this is where to contribute and find current MVC code
• aspnet/AspNetWebStack — Legacy ASP.NET MVC 5, Web API 2, and Web Pages 3 for .NET Framework; points backward to pre-Core MVC architecture
• ivaylokenov/MyTested.AspNetCore.Mvc — Third-party fluent testing framework specifically designed for ASP.NET Core MVC unit tests; commonly used by contributors
• ivaylokenov/AspNet.Mvc.TypedRouting — Community extension for strongly-typed route generation in ASP.NET Core MVC, solving the string-based routing limitation
• dotnet/runtime — Underlying .NET Core runtime and libraries that ASP.NET Core MVC depends on; relevant for deep debugging and understanding corlib behavior

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.

Add comprehensive benchmarking documentation and validation tests for benchmarkapps

The repo contains two benchmark applications (BasicApi and BasicViews) with Lua load test scripts and benchmarks.json configs, but there's no documentation explaining how to run them, interpret results, or validate performance regressions. New contributors could create a benchmarking guide and add validation tests that ensure benchmark scripts execute correctly.

• [ ] Create benchmarkapps/BENCHMARK_GUIDE.md documenting how to run BasicApi and BasicViews benchmarks
• [ ] Add validation that benchmarks.json files are properly formatted and all referenced Lua scripts exist in benchmarkapps/{BasicApi,BasicViews}/
• [ ] Create a CI test (in .vsts-pipelines or .github/workflows) that runs benchmark app startup validation to catch regressions
• [ ] Document expected performance baselines and how to compare results across commits

Migrate archived CI/CD pipelines to GitHub Actions

The repo uses legacy CI systems (.travis.yml, .appveyor.yml, .vsts-pipelines) that are archived. While the project itself is archived, updating to modern GitHub Actions would help future forks and demonstrate current best practices. Add a GitHub Action workflow that validates the build on push/PR.

• [ ] Create .github/workflows/build.yml that restores dependencies and builds Mvc.sln using dotnet CLI
• [ ] Add separate workflow for running unit tests from test projects (likely in src/)
• [ ] Include linting check using .editorconfig rules (via tools like editorconfig-checker)
• [ ] Document in CONTRIBUTING.md which GitHub Actions are required before merge

Add missing test coverage for benchmark app Startup configurations

The benchmarkapps contain Startup.cs files (BasicApi/Startup.cs and BasicViews/Startup.cs) with MVC/Razor/EF configurations, but there are no corresponding unit tests validating their dependency injection and middleware setup. This is valuable for preventing regressions in benchmark app reliability.

• [ ] Create benchmarkapps/BasicApi.Tests/StartupTests.cs to verify DbContext registration, controllers are discoverable, and auth middleware is configured
• [ ] Create benchmarkapps/BasicViews.Tests/StartupTests.cs to verify View discovery, Razor pages registration, and view component registration (Components/CurrentUser.cs)
• [ ] Add integration tests verifying /api/pet and /api/token endpoints work after Startup configuration
• [ ] Add integration tests verifying home page view renders correctly with layout and HTML helpers

• This repo is archived, so no active issues or PRs exist. To contribute to ASP.NET Core MVC, open issues/PRs at aspnet/AspNetCore instead.
• For learning purposes only: review how routing is implemented in src/Microsoft.AspNetCore.Mvc.Core/Routing/ and compare to current ASP.NET Core source to understand what changed during the monorepo merge.
• Verify that all model binder tests in test/Microsoft.AspNetCore.Mvc.Core.Test/ModelBinding/ cover edge cases (null inputs, circular references, custom types); this pattern is still relevant in the monorepo.

This is an archived ASP.NET Core MVC repository with no active maintenance. The primary security concern is the lack of ongoing updates and patches. The codebase contains benchmark applications that could propagate insecure patterns if used as templates. No critical vulnerabilities were identified in the visible file structure, but the archived status and presence of sample applications with database configurations warrant caution. The repository should not be used for new production deployments. If currently in use, migrate to the actively maintained AspNetCore repository immediately.

• Medium · Archived Repository Without Active Maintenance — Repository root - README.md, all project files. This repository is archived and no longer actively maintained. The project has been moved to https://github.com/aspnet/AspNetCore. Using this archived version means no security patches, bug fixes, or updates will be released for vulnerabilities discovered in the future. Fix: Migrate to the active AspNetCore repository. Use the current maintained version instead of this archived codebase for production applications.
• Medium · Benchmark Applications With Potential Security Gaps — benchmarkapps/BasicApi/Startup.cs, benchmarkapps/BasicViews/Startup.cs, benchmarkapps/RazorRendering/Startup.cs. The benchmarkapps directory contains multiple sample applications (BasicApi, BasicViews, RazorRendering) that may be used as reference implementations. These applications include database migrations and startup configurations that could propagate insecure patterns if copied as templates. Fix: Review all Startup.cs files in benchmark applications to ensure they include proper security middleware (HTTPS enforcement, CSRF protection, security headers). Do not use these as production templates without security hardening.
• Low · Lua Benchmark Scripts Without Validation — benchmarkapps/BasicApi/*.lua, benchmarkapps/BasicViews/*.lua. Lua script files (getWithToken.lua, postJsonWithToken.lua, post.lua, postWithToken.lua) are present in benchmark applications. These scripts handle token-based authentication but may contain hardcoded test credentials or unvalidated request patterns. Fix: Review Lua scripts to ensure they do not contain hardcoded credentials. Verify token handling is done securely and scripts are only used for authorized testing environments.
• Low · Database Migration Files Exposure — benchmarkapps/BasicApi/Migrations/*, benchmarkapps/BasicViews/Migrations/*. Multiple Entity Framework Core migration files are present in the repository (.Designer.cs and .cs files in Migrations directories). While migrations themselves are typically not sensitive, their inclusion in source control should follow secure practices. Fix: Ensure migration files do not contain hardcoded connection strings or sensitive data. Use configuration management for database credentials instead of embedding them in code.

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.