Start a C# Console Project

Table of Contents

1. Challenge

   Step 1: Meet the Cedar Peak onboarding kiosk project

   Cedar Peak Outfitters, an outdoor gear retailer, is standing up a self-serve onboarding kiosk in its break room. New hires will walk up on day one, type their name and hire year, and watch the kiosk print a personalized badge assignment and a welcome script the shift lead reads aloud. You're the newest member of Cedar Peak's small IT team, and this kiosk is your first C# project: an empty console app you'll grow into a working end-to-end tool over the next five steps. Two names get used almost interchangeably by newcomers, and it's worth separating them before you write a line of code. C# is the language: the syntax you type, the keywords like class and static, the rules for what a valid statement looks like. .NET is the platform: the SDK that compiles your C# into an intermediate format, the runtime that executes that format on your machine, and the base class libraries (like System.Console and System.Reflection) that ship with it. When you run dotnet build, the .NET SDK compiles your C# source into a .dll; when you run dotnet run or a task's test, the .NET runtime loads that .dll and executes it. You'll use both the compiler's diagnostics and the runtime's console output throughout this lab, so it helps to know which one is complaining when something goes wrong. Before touching the kiosk code, confirm your editor is wired up to build, run, and debug .NET projects. You'll want: the .NET 9 SDK installed and on your PATH (verify with dotnet --version), an editor with a C# extension enabled for IntelliSense (inline type info, method signatures, and the red-squiggle compiler diagnostics you'll rely on in Step 4), and a terminal open in the project root so you can run dotnet build and a task's test (bash runTest.sh Task_2_1) on demand. None of the tasks ahead require a GUI debugger specifically, but if your editor supports setting breakpoints and inspecting locals, Step 5 will be far more concrete if you use it alongside the exercises. The project you're about to extend is already scaffolded. Your C# source lives under src/, one file per concern: WelcomeHelpers.cs, Conversation.cs, BadgeCalculator.cs, and KioskSession.cs, each holding methods with // TODO markers you'll complete. A .csproj file ties those source files together and tells the SDK how to compile them. When you build, the compiler writes its output — the assembly the .NET runtime actually executes — into bin/ and caches intermediate files in obj/; you never edit those folders by hand, but Step 2 will have you write code that reports on them. Automated tests under tests/ check each finished method as you complete its task, one task's test at a time. With the scenario, the toolchain, and the layout in view, open src/WelcomeHelpers.cs and start building.

   If you get stuck, you can refer to the provided solution code for each task, available in the solution folder.

   info> This lab experience was developed by the Pluralsight team using an internally developed AI tool. All sections were verified by human experts for accuracy prior to publications. However, content may still contain errors or inaccuracies, and we recommend independent verification.
   
   To report a problem or provide feedback, click here. Feedback may be used to improve accuracy in accordance with our Privacy Policy.

2. Challenge

   Step 2: Build the foundational welcome helpers

   Cedar Peak's kiosk starts as a blank console app, and your first job is proving you can point to exactly where your code lives and what it becomes after compiling — a skill you'll use every time a teammate asks "did that even build?" Open src/WelcomeHelpers.cs: it already has a DescribeBuildOutput method with a // TODO. C# resolves a running program's identity through reflection: System.Reflection.Assembly.GetExecutingAssembly() returns the assembly (the compiled .dll) currently executing, and .GetName().Name returns its name as a string. Combining that with the source file path in one interpolated string is the fastest way to answer "where is this build coming from" without hardcoding a filename that drifts out of sync with the project. With the build/output question answered, move to the kiosk's first real data: a name and a hire year. C# is a statically typed language, meaning every variable has a type fixed at compile time — string name = "Jordan"; and int hireYear = 2024; are the typed locals you'll declare next, and the compiler rejects anything that assigns a mismatched value to either. To combine typed values into readable text, C# offers string interpolation: prefixing a string literal with $ lets you embed expressions directly inside { } placeholders, as in $"Hired in {hireYear}", which the compiler expands into the right conversions and concatenation for you. BuildWelcomeBanner in the same file needs exactly this: two typed locals and one interpolated return string.

3. Challenge

   Step 3: Exchange text with the new hire at the console

   The kiosk so far only returns strings for a caller to inspect; a real kiosk has to ask the new hire something and wait for an answer. System.Console gives you that: Console.Write(text) prints without a trailing newline (so the cursor stays on the prompt line), and Console.ReadLine() blocks until the user types a line and presses Enter, returning it as a string. Open src/Conversation.cs: PromptForName already has the shape of a prompt-and-read helper, missing only the calls that make it interactive. A hire year needs to be more than text — the badge math in Step 4 needs a real number to add and multiply. Console.ReadLine() always returns a string, so turning "2024" into the int 2024 needs an explicit conversion. int.TryParse(text, out var year) does exactly that: it attempts the conversion and returns true or false instead of throwing, writing the parsed value into year on success — so a mistyped hire year can't crash the kiosk mid-session, it just falls back to 0 and keeps the flow going. PromptForHireYear needs the same prompt-and-read shape as PromptForName, plus that parse step. With both prompts working in isolation, RunIntroduction ties them together into the transcript a new hire actually sees: ask for a name, ask for a year, then greet them. Console.WriteLine(text) is the printing counterpart to Console.Write — it appends a newline, which is what you want for a banner that should occupy its own line rather than run into whatever comes next. Reuse WelcomeHelpers.BuildWelcomeBanner from Step 2 here instead of rebuilding the greeting text, since that helper is already tested and correct.

4. Challenge

   Step 4: Build without running and repair compiler diagnostics

   So far every file compiled cleanly the moment you opened it. src/BadgeCalculator.cs carries real syntax defects, on purpose, so you can practice the workflow you'll use whenever code doesn't compile. Each broken method keeps its defective code commented out below its TODO, so the rest of the project kept building while you worked on earlier steps. Uncomment a method's code, delete its placeholder throw, and run dotnet build; the compiler prints one message per problem, each naming a file, a line and column, and an error code like CS1002 or CS0161. That location is exact — resist the urge to reread the whole file first, and look at the flagged line before anything else. ComputeBadgeNumber is the first broken method: its formula is correct, but a statement is missing the token that ends it. Fix one diagnostic and the compiler often reveals the next one underneath it — run dotnet build again after each fix to confirm. FormatBadgeLabel has a different kind of defect: an interpolated string (one starting with $") that opens a { } placeholder but never closes it. The compiler treats everything after an unmatched { as still being inside the expression, which produces a message about an unterminated string or missing } rather than a missing ;. Recognizing which punctuation the message is pointing at — a brace versus a semicolon — is most of what makes compiler diagnostics fast to read. The last defect in this file doesn't stop the compiler with a punctuation complaint — it's a logic gap the compiler still catches. IsHireYearValid returns bool, but its only return sits inside an if block; if that condition is false, execution falls off the end of the method with nothing to return. The compiler reports this as error CS0161: not all code paths return a value, and the fix is always the same shape: add a return for the path the if doesn't cover. This diagnostic is one you'll see constantly once methods have more than one branch, so it's worth fixing here deliberately rather than by trial and error.

5. Challenge

   Step 5: Run the kiosk and inspect state at a breakpoint

   Every helper you've built — prompts, banner, badge math — has been tested in isolation. src/KioskSession.cs is where they become the actual kiosk: one method that runs a full onboarding session from first prompt to printed badge. RunSession already calls out to the other three files by name; your job is filling in the sequence of calls and prints in the right order, using a fixed sequence number of 1 since a single session always issues the first badge of its run. A debugger's locals pane doesn't add anything you don't already have — it just shows you the values already sitting in memory at whatever line you paused on. If you set a breakpoint on the badge-assignment line inside a running kiosk session, you'd see the same five values side by side: the name and hire year just read from the console, the sequence number assigned to this hire, and the badge number and label computed from them. CaptureLocalsSnapshot makes that snapshot explicit and testable: given the same inputs a paused session would have, return exactly those five values as a tuple, computed the same way RunSession computes them. A kiosk that only ever onboards one person per run isn't very useful in a break room with a line forming. RunOnboardingQueue is the final piece: process several hires in a single call, giving each one the next sequence number so badge numbers don't collide, and printing each hire's full banner-and-badge block before moving to the next. This is the same logic RunSession already runs once, just looped — and it's the version of the kiosk that mirrors how Cedar Peak will actually run it on day one.

6. Challenge

   Step 6: Run the application

   Every task is done, and each one was graded the moment you completed it. What you have not done yet is watch the whole application run at once -- which is the only place the pieces you wrote separately become a single working program.

   Start the application

   Open the Terminal tab and run:

   dotnet run --project src/Lab.csproj
   

   The program runs in the terminal and prints its output there. Every behaviour it shows is code you wrote in the previous steps, so read the output against what each task asked for -- that is the whole lab, working as one program. ### Run the checks yourself

   The lab ran each task's test for you as you went, but they are ordinary tests and you can rerun any of them whenever you like, one task at a time:

   bash runTest.sh Task_2_1
   

   Swap in the number of the task you want to check. Each failure names the task it belongs to, so the output tells you which step to go back to rather than which line to stare at. Two things worth trying before you finish: break something on purpose and watch the matching check fail, then put it back. Knowing what a failure looks like is worth as much as knowing what a pass looks like, and it costs you nothing here.

   When you are done, everything you wrote is still in the editor tabs -- the lab is yours to keep reading.