klevze
603af17e56
The repo carried two parallel UIs (WPF + WinUI) sharing Models/Services via
cross-directory Link includes. Now that WinUI is the only frontend, collapse
the structure so the WinUI project IS the repo root instead of a nested
sibling folder:
- Delete the WPF project entirely (App.xaml, MainWindow.xaml, csproj) and its
bin/obj output
- Move AmiReel.WinUI/* up to the repo root (App, MainWindow, MainPage,
DialogHelper, Assets, Package.appxmanifest, app.manifest, Properties,
.github/instructions, AGENTS.md) via git mv, preserving history
- Rename AmiReel.WinUI.csproj -> AmiReel.csproj; regenerate the solution as
AmiReel.slnx (the newer XML solution format) with a single project
- Rename namespace AmigaDB.VideoRenderer.{Models,Services} -> AmiReel.{...}
and AmiReel_WinUI -> AmiReel across all files, including the embedded
ffmpeg/ffprobe resource logical names in the csproj and ToolExtractor
- Models/ and Services/ no longer need the Link-based cross-directory
<Compile Include>; they're picked up by the SDK's default globbing now
that they live under the project directory
- Rename assets/ -> branding/ (source icon art) to avoid a case-insensitive
collision with Assets/ (packaged tile art) once both sit at repo root
- Merge the two .gitignore files into one; track the PublishProfiles pubxml
files instead of ignoring them (no secrets, and they keep publish
reproducible across machines) as branding, gitignore, etc.
- Simplify publish-win-x64.ps1 (drop the -Target Wpf/WinUI switch, there's
only one target now) and rewrite README.md to describe the single-project
layout, build/run/publish commands, and file structure
Verified: dotnet build succeeds for both AmiReel.csproj and AmiReel.slnx, and
the built exe launches and renders identically to before the move.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.0 KiB
3.0 KiB
description, applyTo
| description | applyTo |
|---|---|
| Security requirements for secrets management, input validation, permissions, and secure coding | **/*.cs, **/*.appxmanifest |
Security
These rules apply to every feature and change. They are not optional add-ons.
Rules
- Never hard-code secrets (API keys, passwords, connection strings) — use environment variables, Windows Credential Manager, or Azure Key Vault.
- Validate and sanitize all external input (user input, file content, network responses).
- Use
SecureStringorPasswordVaultfor sensitive data in memory when practical. - Follow the principle of least privilege — request only the permissions the app actually needs in
Package.appxmanifest. - Keep NuGet packages up to date — run
dotnet list package --outdatedregularly. - Enable code signing for published MSIX packages. Use the
winappCLI rather than hand-rollingsigntool:- Generate a development certificate matching the manifest publisher:
winapp cert generate --manifest .\Package.appxmanifest --install. - Inspect a cert before signing:
winapp cert info .\devcert.pfx. - Sign an existing file:
winapp sign .\MyApp.msix --cert .\devcert.pfx. - Build + sign in one step:
winapp pack .\bin\<Platform>\Release\<TFM>\win-<rid> --cert .\devcert.pfx. - Production releases must be signed by a trusted certificate authority -- never ship the development cert.
- Generate a development certificate matching the manifest publisher:
- When using
HttpClient, always validate TLS certificates and use HTTPS. - Never log sensitive data (PII, tokens, passwords).
Anti-patterns
- Storing secrets in
appsettings.jsoncommitted to source control. - Disabling TLS validation for debugging and forgetting to re-enable it.
- Using
Process.Startwith unsanitized user input. - Broad
try { } catch (Exception) { }that swallows errors silently without any logging.
Validation
- Build & register the MSIX package — see Build, Run & Deploy in
.github/agents/Agents.md. - Check for hard-coded secrets: search for
password,apikey,secret,connectionstringin.csfiles.
Verification Checklist
- No secrets are hard-coded
Must Read & Research
Agent Rule: Before any security-related change (auth, input handling, permissions, HTTP), you must fetch and review these references using
fetch_webpage. Apply what you learn.
| # | Reference | When to consult |
|---|---|---|
| 1 | .NET Security Best Practices | Any code handling credentials, tokens, or sensitive data |
| 2 | Secure coding guidelines for .NET | Input validation, exception handling, type safety |
| 3 | MSIX Security | Packaging, signing, or distribution changes |
| 4 | Package.appxmanifest capabilities | Adding or modifying app capabilities/permissions |