4.0 KiB
Repository Guidelines
Project Structure & Module Organization
BusinessMgr.sln contains the SaBusinessMgrCoreWebControl administration app and SaBusinessMgrCoreWebPortal user portal. Shared code is divided among SaBusMgrStandardBase, SaBusMgrStandardDbas, SaBusMgrCoreProcs, and SaBusMgrCoreWeb. Tests live in SaBusMgrTest_Control and SaBusMgrTest_Portal. Web-project assets are under Views, Localisation, and wwwroot.
The solution also requires the sibling ..\..\Common-VS\Workspace projects. Preserve this relative layout when cloning or configuring a build agent.
Build, Test, and Development Commands
Run commands from the repository root:
dotnet restore BusinessMgr.sln
dotnet build BusinessMgr.sln --configuration Debug
dotnet test BusinessMgr.sln --configuration Debug
dotnet run --project SaBusinessMgrCoreWebControl
dotnet run --project SaBusinessMgrCoreWebPortal
Use --configuration Release for release validation. After code changes, run dotnet build BusinessMgr.sln where practical and report validation that could not be completed. Both launch profiles default to ports 5000/5001; override ports to run them together.
Coding Style & Naming Conventions
Match existing C# conventions: tabs, braces on new lines, top-of-file using directives, PascalCase public members, and established Sbm/Sacs prefixes. Tests use descriptive names such as Test_Application_ControlDatabase. No repository-wide formatter is configured, so follow nearby code. Target the framework versions declared in project files. Do not upgrade frameworks or NuGet packages unless explicitly requested.
Processes derived from SaProcess_Base must actively poll IsInterrupted during long-running loops and before expensive or blocking stages, then exit promptly when cancellation is requested.
Use Windows CRLF line endings for C# source, Visual Studio project files, configuration files, PowerShell or command scripts, and general documentation. Use LF for web assets and files commonly consumed by Unix tooling, including SVG, HTML, CSS, JavaScript, shell scripts, and YAML. Follow .gitattributes as the authoritative policy and preserve the configured ending when editing files.
Testing Guidelines
Tests use MSTest with Moq and coverlet. Add [TestClass] and [TestMethod] attributes and place tests in the project matching the affected application. Run the relevant test project after a change, and run the full solution tests when the change crosses project boundaries. Several tests access configured databases and are integration-oriented; verify machine configuration and test data before assuming failures are isolated unit-test regressions.
Change Discipline
Do not edit generated files or build output under bin, obj, or TestResults. Change source inputs instead. Before implementing a significant architectural change, describe the proposed design, affected projects, compatibility implications, and migration approach, then wait for agreement.
Conversation Tracking
Read docs/topics.md and docs/component-reviews.md before starting repository review or follow-up work. Update them when a conversation identifies, starts, completes, or reprioritises work, or when a component is reviewed. Follow the tracking conventions in docs/README.md and use ISO YYYY-MM-DD dates.
Commit & Pull Request Guidelines
Recent commits use concise subjects, usually prefixed with a release version, such as 3.0.2.1 Vehicle Classes. Keep commits focused and use an imperative or clear feature/fix summary. Pull requests should describe scope, affected projects, configuration or database implications, and build/test results. Link relevant issues and include screenshots for changes to Razor views or portal/control styling.
Security & Configuration
Do not commit credentials or machine secrets. Runtime startup requires appsettings.machine.{ComputerName}.json; keep environment-specific values local and document any new required keys in the pull request.