Brief description of what this article covers.

Step-by-Step Instructions

1. First step

1. Second step

Additional Notes

Any additional information or tips.

Visual Studio & .NET — First-Timer Companion

A companion to Pyramid Setup. That guide is the what to type. This one is the what it means — written for someone brand new to Visual Studio, .NET, C#, and Blazor.

Read this alongside the setup walkthrough. Where the setup guide says "run this command," come back here to understand why.

---

Part 1 — Where do the setup commands need to run?

A frequent first-day confusion. The commands in the setup guide fall into two buckets:

Bucket A — "run from anywhere" (global, once per machine)

dotnet nuget add source ...
dotnet nuget update source ...

Why anywhere? These write to your user-level NuGet config at %APPDATA%\NuGet\NuGet.Config. That file belongs to your Windows user account, not to any project or folder. So it doesn't matter what directory you're sitting in — the change is global and only needs to happen once per machine. Steps 2a–2c of the setup guide are all in this bucket.

There are two levels of NuGet config. The user-level one above applies to everything you build. A solution-level nuget.config can also sit in a repo to pin sources for just that project. The Pyramid uses the user-level one, which is why each developer configures their machine once instead of it "just working" after cloning.

Bucket B — "location matters" (tied to a specific project)

dotnet build MckimCreedPyramid.sln                              # run from repo root
dotnet user-secrets set ... --project MckimCreedPyramid\MckimCreedPyramid.csproj
dotnet run --project MckimCreedPyramid\MckimCreedPyramid.csproj

Why does location matter here? These act on a specific project or solution. dotnet build needs to find the .sln; user-secrets needs to know which project's secret store to write to.

Why the explicit --project ...\MckimCreedPyramid.csproj flag? There's a leftover legacy .csproj at the repo root from an older project layout. If you point at the bare folder name, the SDK finds two candidate project files and errors with "Multiple MSBuild project files found." Pointing at the .csproj file removes the ambiguity. (Alternatively, cd MckimCreedPyramid first and drop the flag.)

Rule of thumb: nuget add/update source → anywhere. Anything that builds, runs, or stores secrets for a project → location matters, so point at the file.

---

Part 2 — Finish-the-setup checklist

Picking up from NuGet configuration, here's the remaining path with the reasoning behind each step.

| Step | What | Why it matters |

|---|---|---|

| 2a–2c NuGet sources | Add the four package feeds | The solution pulls packages from Azure DevOps (McKim's private feed), public nuget.org, and Telerik. Miss one and the build fails with a specific NU#### code (see the cheat sheet in the setup guide). |

| 2d Telerik license file | Save telerik-license.txt, set TELERIK_LICENSE_PATH, reboot | Feed credentials let you download Telerik; the license file lets it run without a watermark. They're two separate things. The env var is only read at process start, so apps won't see it until you sign out/in or reboot — easy to forget. |

| 3 Build | dotnet build MckimCreedPyramid.sln from repo root | A green build proves all four feeds are wired up correctly. Thousands of CS8618/CS8603 nullable warnings are normal noise — not errors. |

| 4 Client secret | LastPass "Pyramid Secret" → user-secrets | The app logs in via Azure AD as a confidential client, which needs a real secret at runtime. The repo only ships a placeholder. Without it: AADSTS7000215: Invalid client secret. |

| 5 Run in IIS Express | Visual Studio, Ctrl+F5 | First run pops a UAC prompt + asks to trust the IIS Express SSL cert — accept both. |

Gating access items — confirm these early. Two prerequisites are granted by people, not commands: Azure DevOps feed membership (MckimCreedFeeds → MckimCreedNugetFeed) and an active Telerik Blazor subscription. If either is missing she'll be blocked at build time, so verify them before she starts typing.

Why User Secrets at all? (the client-secret "why")

The secret never belongs in source control. ASP.NET Core's User Secrets stores it outside the repo at %APPDATA%\Microsoft\UserSecrets\\secrets.json and overlays it onto appsettings.json automatically when running in Development. On Test/Production servers the same value is supplied as the env var AzureAd__ClientSecret (the double underscore maps to the : config separator). The (thepyramid-server-dev) is the key that ties your local store to what the app expects — if it's a random GUID instead, the app reads nothing and you still get AADSTS7000215.

---

Part 3 — How Visual Studio actually works (the mental model)

Solution → Projects → Files

• A solution (.sln) is the whole workspace.
• It contains one or more projects (.csproj), each compiling to its own .dll or .exe.
• The Pyramid has several projects. The three to know:
• MckimCreedPyramid — the server host. ⭐ This is the startup project.
• MckimCreedPyramid.Client — the Blazor front-end (runs in the browser).
• PyramidE2E — end-to-end tests.
• Solution Explorer (right-hand panel) is your map of all of it.

#1 new-dev mistake: running with the wrong startup project. Right-click MckimCreedPyramid → Set as Startup Project. The project name shown in bold in Solution Explorer is the current startup project.

Running the app: the ▶ button and launch profiles

• The green ▶ button runs the startup project using the selected launch profile — the dropdown right next to it.
• Why are there two profiles?

| Profile | What it is | Where it works |

|---|---|---|

| https | Kestrel — .NET's own built-in web server | Everywhere: VS, VS Code, Rider, dotnet run |

| IIS Express | Microsoft's lightweight local web server | Visual Studio only |

Both serve the same app; they're just different local web servers. Our setup guide uses IIS Express (binds to https://localhost:44364). If you ever pick the IIS Express profile in VS Code or Rider you'll get "doesn't know how to run the profile with name IISExpress" — that's expected; IIS Express needs Visual Studio.

F5 vs Ctrl+F5 — know the difference

• F5 = Start with debugging. Breakpoints work. Slightly slower. This is your everyday mode once you're writing code.
• Ctrl+F5 = Start without debugging. Faster, no breakpoints. The setup guide uses this for the first run just to confirm the app boots.

---

Part 4 — Debugging (the highest-value skill to learn first)

Debugging will teach her an unfamiliar codebase faster than reading it ever will. The core loop:

1. Set a breakpoint — click in the left margin next to a line of code. A red dot appears.
2. Run with F5. Execution pauses at that line, before it runs.
3. Step through:

• F10 — Step Over: run the current line, move to the next.
• F11 — Step Into: dive inside a method call to watch what it does.
• F5 — Continue: resume until the next breakpoint.

1. Inspect state:

• Hover any variable to see its current value.
• The Locals window shows all in-scope variables; Watch lets you pin specific ones.
• The Call Stack window shows the chain of calls that got you here — invaluable for "how did execution even reach this line?"

Tell her: when something behaves unexpectedly, the instinct should be "set a breakpoint and watch it run," not "stare harder at the code."

---

Part 5 — Blazor orientation (so it's less mysterious)

• Blazor = C# for web UI instead of JavaScript. UI files are .razor (HTML-like markup mixed with C#).
• The Pyramid is a Blazor Web App split across server (MckimCreedPyramid) and client (.Client). A given page's code can live on either side depending on how it's rendered.
• This split is genuinely confusing at first. Reassure her she doesn't need to understand why a file lives in the server vs. the client project until a task actually requires it. Early on, just follow where the code is.

---

Part 6 — The daily loop (once setup is done)

After the one-time setup, normal work is just:

git pull
# make changes
# F5 (with debugging) or Ctrl+F5 (without) in Visual Studio

She won't repeat the setup steps unless:

• She re-images her machine → everything.
• The Azure AD secret is rotated → just the client-secret step.
• A new private feed is added → just the NuGet step.
• Her Telerik license is renewed → just the license-file step.

---

First-day order of operations (suggested)

1. Verify access first (Azure DevOps feed + Telerik subscription) — these are people-granted and block everything.
2. Run the NuGet commands one at a time, reading each result — the NU#### error code tells you exactly which feed is wrong (cheat sheet in Pyramid Setup §3).
3. Telerik license file → reboot.
4. Build → expect green with warnings.
5. Client secret from LastPass.
6. Open the solution, set the startup project, Ctrl+F5.
7. Once it boots, switch her to F5 + breakpoints and walk her through stepping through one request — that's the real "aha" moment.

---

Related notes

• Pyramid Setup — the step-by-step command walkthrough this companion explains.
• Repo README.md — build profiles and publish commands.
• Repo Authorization/CLAUDE.md — how per-API authorization handlers work.