This guide walks a new (or freshly-imaged) developer from zero to a running MckimCreedPyramid app on their machine, including how to run it under IIS Express without debugging.

Estimated time: 45–60 minutes the first time, mostly waiting on installs and credential setup. Most of the gotchas are credential / NuGet config issues, not code issues.

---

0. Prerequisites

Install these before starting (skip any you already have):

• Visual Studio 2022 — required if you want to run under IIS Express
• During install, check the "ASP.NET and web development" workload (this is what brings IIS Express in)
• .NET SDK 8.0 — the host project targets net8.0
• Git — to clone the repo
• LastPass access to the Shared-Dev vault
• A Telerik account with a Blazor UI subscription, plus your Telerik license key file
• Membership in the Azure DevOps MckimCreedFeeds → MckimCreedNugetFeed feed (ask IT/dev lead if you don't have it yet)

---

1. Clone the repo

git clone https://mckimandcreed@dev.azure.com/mckimandcreed/MckimCreedFeeds/_git/ThePyramid
cd ThePyramid

(Exact URL may vary — check Azure DevOps for the current clone URL.)

---

2. Configure NuGet sources

The Pyramid solution restores packages from four NuGet sources. These live in your user-level config at %APPDATA%\NuGet\NuGet.Config and are not stored in the repo, so each developer machine has to be set up once.

> 💡 If you see a build failure with errors NU1301 (auth) or NU1102/NU1103 (package not found), it's almost always one of these four sources misconfigured.

2a. MckimCreedNugetFeed (Azure DevOps)

This should already be in your %APPDATA%\NuGet\NuGet.Config if you've used any McKim feed before. If not, add it:

dotnet nuget add source `
  https://mckimandcreed.pkgs.visualstudio.com/MckimCreedFeeds/_packaging/MckimCreedNugetFeed/nuget/v3/index.json `
  --name MckimCreedNugetFeed

Authentication is silent via the Azure Artifacts credential provider (uses your signed-in Microsoft account). If you get 404 or Unauthorized from this feed, you need to be granted read access to the feed in Azure DevOps — talk to the dev lead.

2b. nuget.org (public)

The McKim-only user config doesn't always include public nuget.org, but several BCL packages (System.Private.Uri >= 4.3.2, System.ComponentModel.Annotations >= 5.0.0) only resolve there:

dotnet nuget add source https://api.nuget.org/v3/index.json --name nuget.org

2c. Telerik feed

You need a Telerik account with an active Blazor UI subscription. Store your credentials once:

dotnet nuget update source Telerik `
  --username YOUR_TELERIK_EMAIL `
  --password YOUR_TELERIK_PASSWORD_OR_API_KEY `
  --store-password-in-clear-text

> ⚠️ --store-password-in-clear-text is required on Windows because Telerik's feed doesn't support encrypted creds in NuGet.Config. The credentials land in your user-level config, not in the repo.

>

> Prefer a NuGet API key (generated from your Telerik account) over your account password — it's scoped just to the feed and can be revoked without disturbing your account.

2d. Telerik license file (NEW since 2024)

In addition to feed credentials, Telerik UI for Blazor 11.x requires a runtime license activation via a license key file. This is separate from feed authentication — without it, components render with an "unlicensed" watermark.

1. Download your telerik-license.txt from the Telerik portal → Your Account → Manage Subscriptions → Download license key
2. Save it anywhere stable on your machine (e.g. C:\Users\\.telerik\telerik-license.txt)
3. Set the system environment variable TELERIK_LICENSE_PATH to that file path (System Properties → Environment Variables → New)
4. Sign out & back in (or reboot) so apps pick up the new env var

---

3. Build the solution

From the repo root:

dotnet build MckimCreedPyramid.sln

If sources 2a–2c above are right, this should finish in ~30 seconds with 0 Error(s) and a couple thousand nullable-reference warnings (CS8618 / CS8603 — these are noise, not blockers).

Build failure cheat sheet

| Error code | What it usually means | Fix |

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

| NU1301 401 from nuget.telerik.com | Telerik creds missing | 2c above |

| NU1301 404 from mckimandcreed.pkgs.visualstudio.com | No feed permission in Azure DevOps | Ask dev lead for read access |

| NU1102 / NU1103 for System.* packages | Missing nuget.org | 2b above |

| MSB4019 / error MSB1011 Multiple project files | You're invoking the SDK from the repo root with stray legacy .csproj files present | Pass --project MckimCreedPyramid\MckimCreedPyramid.csproj explicitly, or cd MckimCreedPyramid |

---

4. Configure the Azure AD client secret (User Secrets)

The host project (MckimCreedPyramid\MckimCreedPyramid.csproj) uses Microsoft.Identity.Web with a confidential-client OAuth flow, so it needs a real Azure AD client secret at runtime.

The repo's MckimCreedPyramid\appsettings.json contains a placeholder:

"AzureAd": {
  "ClientId": "57290431-1e1c-44f4-8158-2fbab893a053",
  "ClientSecret": "--SET-IN-USER-SECRETS--",
  ...
}

If you launch the app without overriding --SET-IN-USER-SECRETS--, Azure AD rejects the login with:

> MsalServiceException: AADSTS7000215: Invalid client secret provided.

The same client secret value is used in every environment (Development, Test, Production), so you only ever set one value — there's no per-environment secret.

4a. Get the secret value

From LastPass → Shared-Dev → "Pyramid Secret" (the entry name in some older docs is "The Pyramid Client Secret" — both refer to the same value). If you don't have access to the Shared-Dev folder, ask a team member to share it.

> Do not rotate the secret in the Azure portal unless coordinated — every developer's user-secrets and the Azure App Service config on each server have to be updated together.

4b. Confirm (or set up) the ``

User Secrets are keyed by a declared in the host .csproj. For The Pyramid this value is thepyramid-server-dev, and it's normally already committed in MckimCreedPyramid\MckimCreedPyramid.csproj:

<PropertyGroup>
  <UserSecretsId>thepyramid-server-dev</UserSecretsId>
</PropertyGroup>

To confirm it's there:

Select-String -Path MckimCreedPyramid\MckimCreedPyramid.csproj -Pattern "UserSecretsId"

If that returns the line above, you're set — skip to 4c.

If it returns nothing (fresh project layout, or the line got dropped), set it up explicitly with the thepyramid-server-dev id so your secrets land in the same store every other developer and every environment expects:

dotnet user-secrets init --id thepyramid-server-dev --project MckimCreedPyramid\MckimCreedPyramid.csproj

> ⚠️ Always use the literal id thepyramid-server-dev. If you run dotnet user-secrets init without --id, the SDK generates a random GUID instead. Your secret would then be stored under that GUID and the app — which is hard-wired to thepyramid-server-dev — would never read it, so you'd still hit the AADSTS7000215 error even after setting the secret. If you accidentally generated a GUID, open the .csproj and replace it with thepyramid-server-dev.

4c. Set the secret value

With the confirmed as thepyramid-server-dev, set the value:

dotnet user-secrets set "AzureAd:ClientSecret" "<PASTE_VALUE_FROM_LASTPASS>" --project MckimCreedPyramid\MckimCreedPyramid.csproj

> Why --project MckimCreedPyramid\MckimCreedPyramid.csproj and not just --project MckimCreedPyramid? The repo root still has one stray legacy MckimCreedPyramid.csproj left over from the old project layout. It makes the bare folder name ambiguous and can cause "Multiple MSBuild project files found." Always point at the .csproj file directly. If you prefer, cd MckimCreedPyramid first and omit --project.

The secret gets stored locally at:

%APPDATA%\Microsoft\UserSecrets\<UserSecretsId>\secrets.json

…which is outside the repo and never committed. At runtime in Development, ASP.NET Core overlays this file onto appsettings.json automatically.

4d. Test and Production environments

User Secrets is a dev-only mechanism. On Test and Production servers the same value is supplied via Azure App Service → Configuration → Application settings as the env var AzureAd__ClientSecret (double underscore maps to the : config separator). If the secret is rotated, update all locations: LastPass, every developer's local user-secrets, and Azure App Service for each environment.

---

5. Run the app under IIS Express (without debugging)

The host project's MckimCreedPyramid\Properties\launchSettings.json defines two profiles:

| Profile | commandName | Where it works |

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

| https | Project (Kestrel) | All IDEs and dotnet run |

| IIS Express | IISExpress | Visual Studio only |

If you're in Rider, VS Code, or running from the terminal and you pick the IIS Express profile, you'll see:

> "The project doesn't know how to run the profile with name IISExpress and command IISExpress."

That error means the IDE you're in doesn't support IIS Express profiles. For IIS Express specifically, you must use Visual Studio.

5a. Open the solution in Visual Studio

start MckimCreedPyramid.sln

(Or right-click the .sln in Explorer → Open with → Visual Studio 2022.)

5b. Make sure IIS Express is actually installed

It ships with the ASP.NET and web development workload. Confirm with:

Test-Path "C:\Program Files\IIS Express\iisexpress.exe"

If that returns False, open the Visual Studio Installer, click Modify on your VS 2022 install, check the "ASP.NET and web development" workload, and install.

5c. Set the correct startup project

In Solution Explorer:

1. Right-click the MckimCreedPyramid project (the host, not .Client and not PyramidE2E) → Set as Startup Project

5d. Select the IIS Express launch profile

In the toolbar next to the green ▶ run button, click the dropdown and select IIS Express.

The profile binds to:

• http://localhost:43032
• https://localhost:44364

5e. Start without debugging

Press Ctrl + F5 (or Debug menu → Start Without Debugging).

The first time, Windows will pop a UAC prompt and ask to trust the IIS Express SSL cert — accept both. After that, your default browser opens to the IIS Express URL and the app should reach the Microsoft login screen.

5f. Sign in

Use your @mckimcreed.com account. If you get redirected back with the AADSTS7000215 error, your User Secrets step in section 4 didn't take — restart VS so the new secret is read at startup, then retry.

---

6. Common pitfalls (and where to look first)

| Symptom | Likely cause | Where to fix |

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

| Build hangs for minutes then fails with NU1301 | Wrong creds on a private feed, NuGet retry loop | §2 NuGet sources |

| Build fails fast with NU1102 / NU1103 for System.* packages | Missing nuget.org | §2b |

| App starts but Telerik components show "unlicensed" watermark | TELERIK_LICENSE_PATH not set or pointing nowhere | §2d |

| Sign-in fails with AADSTS7000215 (invalid client secret) | User Secrets not set or app didn't restart after setting | §4 |

| The project doesn't know how to run the profile with name IISExpress | Trying to run the IIS Express profile from Rider / VS Code / dotnet run | §5 (use VS, not Rider) |

| Multiple MSBuild project files found when running dotnet … from the repo root | Stray root-level .csproj files are leftovers from the old project layout | Always pass --project MckimCreedPyramid\MckimCreedPyramid.csproj |

---

7. After first-run setup

Once everything above is set up, daily work is just:

git pull
# work, work, work
# F5 / Ctrl+F5 in Visual Studio

You should not need to repeat sections 0–4 unless:

• You re-image your machine (everything)
• The Azure AD secret is rotated (just §4)
• A new private feed is added to the solution (just §2)
• Your Telerik license is renewed (just §2d)

---

Related notes

• See the repo README.md for build profiles (Test, Release) and publish commands
• See Authorization/CLAUDE.md in the repo for how the per-API authorization handlers work
• For the broader project context, see Projects/ThePyramid in this vault