4.1 KiB
Repository Guidelines
Project Structure & Module Organization
The solution LIAM.sln covers all Matrix42 integration projects. Runtime code centers on LiamM42WebApi (service endpoints), LiamWorkflowActivities* (workflow logic and designers), and adapters such as LiamActiveDirectory, LiamExchange, and LiamMsTeams. Shared helpers live in LiamBaseClasses and LiamHelper. The _shared directory pins required third-party binaries; do not modify or rename them. NuGet restore artifacts belong in packages/, and the WinForms tooling LiamTestTeams supports manual verification.
Build, Test, and Development Commands
Run nuget restore LIAM.sln once per clone to hydrate packages. Build locally with msbuild LIAM.sln /p:Configuration=Debug; use Release for deployable artifacts. For a clean rebuild, execute msbuild LIAM.sln /t:Clean,Build /p:Configuration=Debug. Visual Studio can open LIAM.sln, with LiamM42WebApi as the suggested startup project. When self-hosting the API, deploy it to IIS or IIS Express pointing at the project folder.
On WSL/Linux, use the user-local msbuild wrapper that delegates to dotnet msbuild with the local .NET Framework reference assemblies under ~/.local/share/dotnet-framework-reference-assemblies/. The expected verification command there is still msbuild LIAM.sln /p:Configuration=Debug. LiamWorkflowDiagnostics is a WPF diagnostics tool and is intentionally skipped on non-Windows builds; validate that project on Windows with Visual Studio or Windows MSBuild. If you only need to validate the NTFS provider in isolation, msbuild LiamNtfs/LiamNtfs.csproj /p:Configuration=Debug is the fastest targeted check.
Coding Style & Naming Conventions
Follow C# Allman braces with four-space indentation. Maintain PascalCase for classes, members, and constants (e.g., constFragmentNameConfigProviderBase), and camelCase for locals and parameters. Keep using directives sorted and trimmed. New projects should link SharedAssemblyInfo.cs to align assembly metadata. Format via Visual Studio or dotnet format if the SDK is available.
Testing Guidelines
Automated tests are currently absent; regression work relies on targeted manual runs. Use LiamTestTeams to drive Microsoft Teams scenarios and validate API calls. Document manual steps in pull requests until automated coverage is added. When introducing tests, co-locate them with the feature project and add the project to LIAM.sln so CI can call the standard msbuild targets.
Commit & Pull Request Guidelines
History is minimal (initial), so prefer concise, imperative commit subjects and reference tracking IDs when applicable (e.g., Add Graph delta sync for users (LIAM-123)). Squash tooling-only commits before merge. Pull requests should note the impacted integration area, configuration changes, and manual verification evidence (logs, screenshots, or request IDs). Confirm no secrets are included and request review from the owner of each touched module.
Mandatory Workflow Rules
- Before starting any request that requires a code change, the repository must have no open Git changes (
git status --shortmust be empty). - If the working tree is not clean before starting a code change request, stop and clarify with the requester before proceeding.
- After completing a requested code change, always create a Git commit with a concise, fitting, imperative message.
- After completing a requested code change, always push the new commit immediately to the configured remote branch.
- If a
git pushfails, retry the push up to 5 times with a short delay between attempts before reporting the failure. - Use Windows line endings (
CRLF) for all text files in this repository. - Every newly created or modified text file must be written back with Windows line endings (
CRLF).
Security & Configuration Tips
Exclude environment-specific web.config, app.config, and credential artifacts from version control. Treat binaries under _shared as read-only dependencies. When updating external references, confirm compatibility with the target Matrix42 environment and record the expected deployment steps in the PR.***