C# Learning Roadmap: 24 Weeks from Basics to ASP.NET Core

Beginners often jump from syntax tutorials straight into web APIs, then discover that collections, LINQ, asynchronous code, tests and dependency injection are still weak. Build StudyTracker through one ordered 24-week sequence instead of producing disconnected exercises. The PHP learning roadmap carries a similarly named tracker through forms, PDO and Laravel. C# practice should instead prove LINQ traces, cancellable repositories, dependency-injection lifetimes and ASP.NET Core request contracts. If loops and methods still need repair, start with a prerequisite from Coding & Skill Development Courses.

Set a 10-hour weekly rhythm and a recovery rule

The study model is 24 weeks × 10 hours = 240 planned hours. Schedule 90-minute build sessions on Monday, Wednesday and Friday, a four-hour Saturday integration block, and a 90-minute Sunday review. That is 90 + 90 + 90 + 240 + 90 = 600 minutes. Give each weekday session one small concept and one test; use Saturday to integrate and Sunday to diagnose.

Before week 1, write a console program without copying. It must accept 24, 36, 30 and 60, print total 150 and average 37.5, and reject 0, -12 and abc. If parsing, loops or methods need repeated lookup, begin at phase 1. Move one missed weekday session to Sunday. If the Saturday integration block is lost, repeat the milestone week instead of borrowing time from the next phase.

Weeks 1-4: make C# basics executable, not familiar

Cover types, variables, operators, conditionals, loops, methods, arrays, lists, exceptions and input validation. Build StudyTracker as a console app. Store 24, 36, 30, 60 in List<int>, then calculate total = 150, count = 4 and average = 37.5. Filtering for values of at least 35 must print 36 and 60.

Before moving on, verify three cases. Empty input prints a clear message instead of dividing by zero. Zero and negative minutes are refused. int.TryParse("abc", out value) takes the invalid-input path. Explain each method in one sentence without reading its code. Use Classic Programs in C, Java and Python only for language-neutral prompts, then reimplement one in C# without copying another language's syntax.

Weeks 5-8: model the domain with modern C# and OOP

Replace integers with record StudySession(int Id, string Topic, int Minutes, bool Completed). Seed (1, "C# Basics", 24, true), (2, "LINQ", 36, true), (3, "Async", 30, false) and (4, "C# Basics", 60, true). Use nullable annotations deliberately and reject a blank topic at the boundary.

Learn classes, interfaces, encapsulation, composition, records, generics and pattern matching. Use inheritance only for a genuine subtype. Create IStudySessionRepository and make StudySummaryService depend on it, but do not give every class an interface merely to resemble enterprise code. Review the underlying object-oriented ideas. Leave this phase only when you can explain why a session is a value-like record while repository behaviour sits behind an interface.

Weeks 9-12: learn collections and LINQ by checking results manually

Study List<T>, Dictionary<TKey,TValue>, delegates, lambdas, and deferred versus immediate LINQ execution. Run each query on the four seeded sessions and check it by hand. Where(s => s.Completed) keeps IDs 1, 2 and 4. Their sum is 24 + 36 + 60 = 120, and their average is 120 / 3 = 40. Grouping completed minutes gives C# Basics = 84 and LINQ = 36; Async is excluded because its only row is incomplete.

Then call ToList() before changing the source and predict how deferred enumeration would differ. Handle an empty completed set without calling Average() blindly. The phase deliverable is a summary command whose printed values match the manual calculation exactly.

Weeks 13-15: make asynchronous data access cancellable and observable

Learn Task, async, await, exceptions, cancellation, and file or HTTP I/O. Change the contract to Task<IReadOnlyList<StudySession>> LoadAsync(CancellationToken cancellationToken) and store the same four records in JSON. Pass the supplied token through every asynchronous operation instead of creating and ignoring another one.

Trace success: load 4 sessions, keep the 3 completed rows, and return total 120 and average 40. Trace cancellation separately. Cancellation before the read finishes must remain cancellation, not become an empty list. Avoid .Result and .Wait() merely to make asynchronous code look synchronous, and do not add async when nothing is awaited. Exit with a command that reports completion, cancellation and a genuine load failure distinctly.

Weeks 16-18: put tests and dependency injection before the web layer

Separate calculation from I/O. Unit-test StudySummaryService with a fake IStudySessionRepository returning the four seeded sessions. Assert CompletedSessions = 3, TotalMinutes = 120 and AverageMinutes = 40. For an empty list, return counts and totals of 0, with an average representation you chose deliberately rather than an accidental exception.

Add boundary tests: blank topic is invalid, Minutes = 0 is invalid, and a cancelled repository call stays cancelled. Name tests by behaviour, arrange only needed data, act once and assert visible outcomes. Inject dependencies through constructors and choose service lifetimes from actual state and use. Do not hide dependencies behind a service locator. The gate is a green suite plus one paragraph explaining what is isolated and why.

Weeks 19-22: expose the rules through a small ASP.NET Core API

C# is the language, .NET supplies its runtime and libraries, and ASP.NET Core is the web framework used here. Start with only GET /api/sessions, GET /api/summary?completed=true and POST /api/sessions. Before any POST, the seeded summary is {"completedSessions":3,"totalMinutes":120,"averageMinutes":40}.

Now send {"topic":"Testing","minutes":48,"completed":true}. The endpoint validates it, the injected service calls the repository, and the response is 201 with ID 5 and location /api/sessions/5. The next summary is {"completedSessions":4,"totalMinutes":168,"averageMinutes":42}: 120 + 48 = 168, then 168 / 4 = 42. The same request shape with "minutes":0 returns 400 and leaves totals unchanged.

Integration-test the successful POST, invalid minutes and summary transition. Keep handlers thin, with validation and summary rules testable outside HTTP. Once it works, compare the same GET and POST flow with the Node.js, Express.js & MongoDB course, an optional route in another backend stack, not a C# course.

Weeks 23-24: harden one portfolio project and choose the next track

Use the last 20 planned hours for error handling, logging, configuration, integration tests and a concise README. Document setup, all three routes, the successful POST, the 400 case and the summary change from 120 to 168 minutes. Remove secrets and prove the project runs from a clean checkout.

Choose persistence if data modelling is the weak point, or add a small client if the API contract is already reliable. Add only one scoped extension, preserve the validation and summary tests, and reproduce it from a clean checkout. Authentication and deployment can wait until the chosen extension passes.

The short version

Follow the phases in order and move only after working code, tests and a short README. If life interrupts the 10-hour rhythm, stretch the schedule rather than compressing the learning. The useful result is not finishing in exactly 24 weeks. It is one small system whose calculations, asynchronous behaviour, tests and HTTP responses you can explain and prove.