Evincia
eShop LegacyWebForms — Modernization Readiness Profile
A readiness profile produced with the Evincia diagnostic engine against a public, archived codebase. It describes where modernization risk concentrates and what a modernization effort would have to absorb. eShop LegacyWebForms is the legacy Web Forms reference app inside Microsoft's dotnet-architecture/eShopModernizing sample: legacy by design, a teaching sample built to demonstrate modernization, and read here on those terms.
What leaders should take away
- The highest risk is platform lock-in, not application size.
System.Webreaches beyond the UI into domain and data files.- The existing
ICatalogServiceseam is the viable migration control point. - No test project turns a small app into a high-change-risk migration.
- AI-assisted refactoring would inherit the same missing regression safety.
Check it yourself
Nothing here rests on trust alone. Clone the repository at the pinned commit and check every cited finding against the source. The engine that produced these findings is Evincia's and the run is deterministic -- pinned to the engine commit below -- so the output is fixed and the evidence is inspectable, even though re-running the engine end to end is ours to do. The 0–100 score on top of the findings is senior architect judgment, as the score section below spells out.
| Repository | github.com/dotnet-architecture/eShopModernizing (the eShopLegacyWebForms sub-app) |
|---|---|
| Pinned commit | 63bc9ec · last commit 2023-10-25 · GitHub archived = true |
| License | MIT · attribution preserved: "Copyright (c) .NET Foundation and Contributors" |
| Engine commit | 6b6e4a2 · Roslyn-based; nine automated categories (1–9), three senior architect review categories (10–12) |
| Coverage | Full semantic coverage -- 1 of 1 project loaded with a semantic model, no syntax-only fallback (confidence impact: None) |
Inspect the evidence: git clone the repo and git checkout 63bc9ec, then open the files each finding cites and read them against the source. (Re-running the diagnostic end to end points the Evincia engine, commit 6b6e4a2, at the eShopLegacyWebFormsSolution/eShopLegacyWebForms.sln sub-solution after a NuGet restore -- the engine is ours, so that step stays in-house.) This is one of three legacy sub-apps in the repo; the sibling MVC and N-Tier solutions are out of scope here. Findings paraphrase the source and cite file/project locations; no substantial verbatim code is reproduced.
Executive summary
eShop LegacyWebForms is a single-project ASP.NET Web Forms storefront targeting .NET Framework 4.7.2 -- one solution, one project, one deployable, no test project. The modernization difficulty here is not architectural sprawl. It is the depth of the platform dependency.
The dominant risks are platform-bound and certain. It targets net472 (RULE-001) and depends on System.Web across 27 sites (RULE-002) -- a hosting and request-pipeline rewrite, not a port. The System.Web dependency has leaked beyond the UI into domain and data files (CatalogBrand.cs, CatalogType.cs, CatalogDBInitializer.cs, CatalogItemHiLoGenerator.cs), so the remediation surface is wider than the web project. It carries no automated tests (RULE-012), so any migration proceeds without a regression net, and it is a monolithic single deployable (RULE-013). Data access runs on Entity Framework 6 v6.2.0, which does not run on modern .NET, and there is inline SQL in CatalogItemHiLoGenerator.cs outside the ORM. The dependency baseline is dated: nine deprecated packages, plus log4net 2.0.10 and Newtonsoft.Json 12.0.1 -- both flagged with known security vulnerabilities per NuGet metadata; whether each fix is a patch or a breaking upgrade is resolved during planning (the pinned versions are checkable in the repo's packages.config at the commit above).
The mitigating fact -- and the most important one for sequencing -- is that the application is not structureless. An injected ICatalogService, its CatalogService implementation, and an Autofac module already provide a service seam (with a mock behind the same interface). The data path can move behind that seam rather than being rewritten in place. The one thing that breaks first is the web layer itself: the moment the project is retargeted off System.Web, the pages, master pages, routing, and startup all lose their host at once.
Modernization Readiness Score
The score is the senior architect's synthesis of the engine's signals: the architect assigns the 0-to-100 number from the dimension reads, then labels it with the Red/Yellow/Green band on the canonical Evincia scale (Red 0–49 / Yellow 50–79 / Green 80–100). The engine did not compute it.
Red because a single-project monolithic ASP.NET Web Forms application is classic platform lock-in: the platform dimension is total lock-in, with no in-place upgrade path, and change-safety has no net at all (zero tests, one deployable). Each dimension below is read on a 0–25 scale (higher = more ready); they sum to 32. The reads are architect judgment, not engine-computed values.
| Dimension | Architect read (0–25) | What drives it here |
|---|---|---|
| Platform Obsolescence | Severe · 5/25 | net472 (RULE-001, Pri 25); System.Web across 27 sites incl. domain/data files (RULE-002, Pri 25); the 86-control Web Forms markup surface. The Web Forms rewrite target (Cat 10) is senior architect review. |
| Architectural Coupling | Moderate · 11/25 | EF6 v6.2.0 (Pri 16); inline SQL outside the data layer in the HiLo generator (Pri 20); single project; InProc session and a static container field assume a single process. But an ICatalogService + Autofac seam exists to migrate behind. |
| Dependency Risk | Elevated · 10/25 | Nine deprecated packages (RULE-011, Pri 16); two packages flagged with known security vulnerabilities -- log4net 2.0.10, Newtonsoft.Json 12.0.1 (RULE-027). |
| Change Safety | Severe · 6/25 | No tests (RULE-012, Pri 25); monolithic deployment (RULE-013, Pri 20). |
Risk register — representative critical rows
Presented in the 12-field LMRR schema; only the representative columns are shown here, and the corrected false positives are excluded. Priority is the engine's severity score for each finding -- Probability (1–5) × Impact (1–5), so it runs 1–25 and a higher number is more severe; the rows below are all in the Critical band (Priority 20–25). Every cited rule fired at Full confidence.
| ID | Finding | Category | Priority | Recommended action |
|---|---|---|---|---|
| R-001 | Targets .NET Framework 4.7.2 | Platform Obsolescence | 25 | Decide the target platform first; net472 + Web Forms has no in-place path. |
| R-002 | System.Web saturation across 27 sites (incl. domain/data files) | Platform Obsolescence | 25 | Plan an ASP.NET Core rewrite of the web layer; remediation reaches beyond the UI. |
| R-003 | No test projects in the solution | Change Failure Risk | 25 | Treat a baseline test suite as a migration prerequisite, not a parallel task. |
| R-004 | Inline SQL in non-data-layer code (HiLo generator) | Data Complexity | 20 | Absorb the query into the data layer behind the existing ICatalogService seam. |
| R-005 | Monolithic single deployable | Change Failure Risk | 20 | Big-bang vs strangler-fig; the small size makes either viable, but the seam is what makes it testable. |
Modernization Risk Profile
Illustrative assessment based on observed patterns. These are qualitative risk levels, not measured client scores.
What will break first
- The web layer, the instant the project is retargeted off System.Web. Page code-behinds, master pages, the
ViewSwitchercontrol,Global.asax.csstartup, and the route/bundle config all lose their host the moment net472 and System.Web are removed. Because System.Web also reaches into domain and data files, the breakage is not confined to the UI. This is the hosting and request-pipeline rewrite, not a config change. - Data access, on the first ORM move. EF6 v6.2.0 does not run on modern .NET, and the inline
SELECTin the HiLo generator touches the data path. The mitigation is real: theICatalogServiceseam means the move to EF Core can happen behind the interface rather than across the UI -- but with no tests, the query-behavior changes are silent until something downstream notices. - The catalog under any scale-out, after a naive lift. InProc session state and the static
_containerProviderfield inGlobal.asax.csboth assume a single process. If the modernized app runs across more than one instance, session and container state diverge between nodes -- and with no tests, that failure is among the hardest to detect.
Suggested modernization sequencing
- Lay the safety net. Add a baseline test suite. Even a thin integration layer over the existing app materially reduces regression risk. This is a prerequisite, not a parallel task -- migration without it is a blind migration.
- Clear the dependency baseline. Update the flagged packages (
log4net2.0.10,Newtonsoft.Json12.0.1) to current releases and plan replacement strategies for the nine deprecated packages rather than version bumps. - Decide the platform and the Web Forms rewrite target. Choose the ASP.NET Core surface (MVC, Razor Pages, or Blazor) that replaces System.Web and the runtime move off net472. This is a Migration-Feasibility decision the engine cannot make; it shapes everything downstream.
- Port behind the seam you already have. Move the data path to EF Core behind
ICatalogService, absorb the inline SQL, then port the System.Web surface. The monolith can stay one unit for an app this small; the seam is what makes the port testable. Replace the static container field and InProc session if any scale-out is in scope. - Close the engine's blind spots with senior architect review. A database-trigger inventory (Signal 5.2), the database-first determination (Signal 4.4), and how much business logic lives in the code-behind (Category 11) are hands-on senior architect work the engine cannot do.
Confidence & coverage
This run achieved full semantic coverage: the single project loaded with a semantic model (1 of 1), zero syntax-only fallback, zero skipped projects, and every cited rule fired at Full confidence. Generated .aspx.designer.cs files were correctly excluded; the Web Forms markup, web.config, and classic packages.config were characterized at the signal level and flagged as senior architect review artifacts, not silent omissions. Two caveats bound this profile: it covers only the eShopLegacyWebForms sub-solution, not the sibling apps; and the numbers above are from the original calibration-mode run -- this program requires a confirming engine re-run before publication; it came back clean of the corrected false positives, and engagement-mode with full coverage enforced remains the standard for client-grade use. The corrected findings reflect a source-verified senior architect read.
What we corrected from the first run
This is the part most diagnostic tools never show you. The first engine run produced three findings a source read did not support, and they were removed before this profile -- the same discipline that makes the score worth trusting:
- A false “hardcoded IP address.” The engine read the assembly's
1.0.0.0version string as an embedded network address. It is a version number, not an IP. Removed from the register and from “what breaks first.” - A false “DbContext accessed directly in the UI.” No page code-behind touches
CatalogDBContext; data access goes through an injectedICatalogService, andCatalogServiceowns the context. The Critical-band row was dropped. - An inverted “no service layer / no seams.” The opposite is true, and it is the single most important sequencing fact here:
ICatalogService+CatalogService+ an Autofac module (and a mock behind the same interface) already provide a substitution seam to migrate behind.
The platform read here -- net472, System.Web saturation, no tests, EF6, dated dependencies (two flagged vulnerable) -- is fully source-verified and stands.
What is mechanical, and what is senior architect judgment
The engine emits deterministic raw signals across nine automated risk categories and scores findings on fixed rules (Probability 1–5 × Impact 1–5 = Priority 1–25). Three further categories -- Migration Feasibility, Embedded Business Logic Risk, and Domain Knowledge Risk -- are senior architect review only; the engine produces no findings for them. The 0-to-100 score and the four dimension reads are senior architect judgment, synthesized from the signals. The engine does not compute the number, and this profile does not invent one.
eShop is a clean illustration of that boundary: the engine nailed the mechanical blockers -- platform, System.Web saturation, EF6, the missing test suite, the monolithic deployment -- at full confidence on a single project that loaded with a semantic model. The largest questions belong to the architect: whether the Web Forms layer is rewritten on ASP.NET Core MVC, Razor Pages, or Blazor (Migration Feasibility), and how much logic is entangled in the code-behind (Embedded Business Logic).
Modernization lesson
The size of a legacy application can be misleading. A compact Web Forms app can still be a rewrite when the hosting model, request pipeline, data layer, and test safety net are all bound to the old platform.
Budget and timeline should be sequenced around the first hard blocker: rewrite the System.Web surface, preserve the service seam, and build regression coverage before using automation or AI to accelerate changes.
About this profile
Source: the Evincia diagnostic engine (commit 6b6e4a2), Output A (raw signals) and Output B (narrative). Findings paraphrase the codebase; see the repository at the pinned commit for the original source. Analyzes dotnet-architecture/eShopModernizing under the MIT License; attribution preserved. This is an illustrative readiness profile of a deliberately-legacy Microsoft teaching sample, not an engagement and not a judgment of its maintainers. Part of the Evincia Public Codebase Teardowns program.