Choose a C# learning path based on what you can already build. Each path pairs written lessons with a small task you can finish and check. Beginners can start with a console program; experienced developers can jump to packages, runtime behavior or games.
If you are following an older lesson, keep its language concept separate from its tooling. Use a supported .NET SDK for new console projects, and follow the engine’s own requirements for a game project. Changing your compiler, target framework and dependencies all at once makes migration problems harder to diagnose.
1. Start programming in C#
Start here if: you have not yet created and run your own C# project.
- Create and run your first program. Change the greeting and confirm that your saved change appears in the output.
- Use the C# tutorial contents to work through variables, branches, loops and methods. Follow the concept sequence while checking each lesson’s tooling assumptions.
- Read numerical input with TryParse. Your program should handle letters, a missing value and a value outside the integer range without crashing.
- Choose integer, floating-point or decimal arithmetic deliberately. Predict the answer before running a division expression.
Build: a small number quiz. Ask for a whole number, reject invalid input politely, and use the remainder operator to report even or odd. Test zero, a negative number and a non-number.
Ready to continue when: you can explain where execution begins, change an expression, read an error message and rerun the program. For a visual walkthrough, use the first three C# video lessons.
2. Work with data and nullable values
Start here if: you can write a loop and call a method, but your programs need to store more than one value.
- Create and update lists. Distinguish a list’s count from the valid range of indices.
- Choose defaults with ?? and ??=. Decide whether you want to read a fallback or assign it to the variable.
- Combine parsing and a list to collect several valid inputs. Keep validation at the point where external text becomes application data.
Build: a reading list with a title, an optional note and a completion flag. Decide what a missing note means. Test an empty list, a single item and two items that reference the same mutable object.
Ready to continue when: you can explain the difference between null, an empty string and a missing collection element, and can demonstrate how changing a referenced object affects a list.
3. Add a package without losing control of your project
Start here if: you have a working project and need persistence, logging, validation, testing or measurement.
Use the C# package directory to compare the job each package does, its framework requirements and its limits. A popular package is not automatically necessary: first write down the requirement it would satisfy.
- Choose one capability, such as saving your reading list to a database.
- Record the target framework and pin the package version you tested.
- Run a small example before adding the dependency throughout your application.
- Test the failure case too: missing data, a rejected value or an unavailable dependency.
Build: a persistence experiment that inserts, reads and updates one record. Compare a data mapper with a full object-relational mapper based on the complexity you actually need. The legacy ADO.NET tutorial explains the connection, command and reader concepts; check the provider and framework before copying older setup instructions.
4. Understand runtime behavior and diagnose hangs
Start here if: you already write methods that return tasks or need to decide how to deploy a .NET application.
- Read why blocking on an async operation can deadlock. Identify which code is waiting and which context must execute the continuation.
- Compare JIT and Native AOT deployment, with notes on bflat. Separate build time, startup, memory usage and steady-state throughput.
Build: a cancellable operation with a bounded timeout, then a small publishable command-line application. Keep the first task correct before optimizing its deployment. A change that removes one deadlock pattern does not prove that every lock or resource interaction is safe.
Ready to continue when: you can reproduce a failure with a small example, state which environment it depends on, and verify the fix under that environment. For performance work, retain the workload and raw measurements instead of comparing unrelated numbers.
5. Make a game with C#
Start here if: you are comfortable with variables, conditions and methods and want visible feedback from your code.
Compare Unity, Godot, Stride and MonoGame before choosing an editor or framework. Check the target platform, C# support and export requirements first. A desktop prototype does not prove that a mobile or browser export will work.
- Choose a tiny project: the game guide’s collection game, or two paddles, a ball and a score from the video walkthrough.
- Make movement work before adding artwork. Keep movement speed independent of frame rate using the engine’s timing model.
- Add collision behavior and an explicit restart state.
- Test the intended export target early.
Build: a playable one-screen prototype. The Godot paddle-game session offers a historical walkthrough with current-version caveats. Add scoring and restart behavior yourself, then explain how your game changes state after a missed ball.
6. Modernize an older C# project in small steps
Start with the C# history and migration roadmap to understand when language features appeared. Language syntax, the .NET runtime and a package’s supported frameworks are separate compatibility decisions.
- Build the original application and record the behavior you need to retain.
- Identify its framework, SDK, package versions and platform-specific APIs.
- Change one boundary at a time: tooling, target framework, dependency or language feature.
- Rerun behavioral checks after each step and retain a rollback point.
Build: a migration checklist for one small project. Include a failing-input example, a dependency compatibility check and a deployment smoke test. A newer syntax is useful when it improves the code you maintain; rewriting every line is not a migration requirement.
For a concrete refactoring exercise, convert an if-based validator to C# pattern matching and verify that both forms return the same results.
How to use these paths
Pick one path and finish its small project before adding another framework. Keep your source code and record the SDK or engine version you used. When a lesson and your tools disagree, compare the versions first, reduce the problem to a small example, and consult the linked official documentation.
Paths reviewed on 4 October 2026. Older lessons remain available at their original addresses; their presence in the lesson index does not mean every historical API or tool has been modernized.