Quality guidelines for samples

[bart-vmware]

Please keep the following guidelines in mind when creating/updating samples:

• Start from the standard .NET 8 project templates, add comments for Steeltoe/sample-specific changes.
  • Suffix project names with "Web" for web-based clients, suffix with "Api" for APIs and microservices (especially when multiple apps interact).
  • Don't delete parts from the standard project templates that aren't strictly needed for the sample. The goal is for readers to recognize the boilerplate code. Removing parts raises the question of whether the sample is incompatible with the boilerplate.
• Consider adding non-web-based projects, such as WorkerService/Desktop/Blazor, where it makes sense.
• Enable nullable reference types and prefer modern C# syntax, such as records and primary constructors.
• All samples should have the Steeltoe.Samples.[AppName] code namespace prefix, in subdirectory [AppName] (do not repeat the category, such as Connectors/Management/Discovery, etc.)
• In manifest.yml, the app name should end with "-sample", the service name should start with sample, so any running orphaned instances in Cloud Foundry are easy to recognize.
• Consider adding integration tests, if feasible, and add status badges to /README.md.
• Consider adding random-route: true to manifest files, if possible.
• Run code-cleanup (you can sync style settings from Steeltoe using /tools/sync-DotSettings/sync-DotSettings.ps1).
• Don't forget to describe how to use the sample and what to expect from it in a README.md.

Bonus points:

• Use modern features, such as minimal APIs

[bart-vmware]

Pending alignments:

• Connector and Discovery samples don't use the Steeltoe.Samples namespace prefix, app/service name in manifest.yml doesn't follow naming guidelines.
• Security samples don't use the project name suffixes, Update Security:RedisDataProtectionKeyStore sample to .NET 8 #333.