Merge pull request #113 from gothinkster/updates-8-x

Updates for 8.x

Author: adamhathcock

.config/dotnet-tools.json

@@ -3,10 +3,11 @@
   "isRoot": true,
   "tools": {
     "csharpier": {
-      "version": "0.28.0",
+      "version": "1.0.3",
       "commands": [
-        "dotnet-csharpier"
-      ]
+        "csharpier"
+      ],
+      "rollForward": false
     }
   }
 }

.dockerignore

@@ -282,4 +282,6 @@ Dockerfile
 
 # .env file contains default environment variables for docker
 .env
-.git/
+.git/
+bin/
+obj/

.github/copilot-csharp-best-practices.md

@@ -0,0 +1,80 @@
+# C# Coding Standards and Best Practices
+
+## Code Style
+
+- **MANDATORY**: Follow the .NET coding conventions as defined by Microsoft.
+- **ALWAYS** use `camelCase` for local variables and method parameters.
+- **ALWAYS** use `PascalCase` for method names, property names, and class names.
+- **MANDATORY**: Ensure that braces are used consistently for all control structures. Example:
+  ```csharp
+  if (x == y)
+  {
+      Foo();
+  }
+  ```
+- **ALWAYS** keep lines of code reasonably short; lines should not exceed 120 characters.
+
+## Naming Conventions
+
+- **MANDATORY**: Use meaningful and descriptive names for classes, methods, and variables.
+- **NEVER** use abbreviated names unless they are well-known (e.g., `Id` for Identifier).
+- **REQUIRED**: Prefix interfaces with the letter `I`.
+- **ALWAYS** name namespaces starting with the company name followed by the project and any sub-folders aligning with the project structure.
+
+## Error Handling
+
+- **MANDATORY**: Use exceptions for abnormal or unexpected program behavior.
+- **ALWAYS** provide helpful error messages when throwing exceptions.
+- **NEVER** use exceptions for normal flow of control.
+- `recommended`: Prefer `try/catch` over returning error codes.
+
+## Documentation
+
+- **REQUIRED**: Every public class and method **MUST** have XML documentation comments for IntelliSense and documentation tools.
+- **MANDATORY**: Document all parameters, exceptions thrown, and return values.
+- `recommended`: Regularly update documentation to reflect changes in the codebase.
+
+## Security
+
+- **MUST** validate all inputs to avoid SQL injections and other common security threats.
+- **ALWAYS** use secure methods and classes provided by the .NET framework where available.
+- `recommended`: Utilize Code Analysis (FxCop) to detect security flaws.
+
+## Performance
+
+- **MANDATORY**: Avoid unnecessary object creation within loops.
+- `recommended`: Utilize lazy loading where appropriate.
+- `recommended`: Employ caching mechanisms to improve responsiveness and performance.
+
+## Source Control
+
+- **MANDATORY**: Check in code frequently to avoid large sets of unshared changes.
+- **REQUIRED**: Include meaningful commit messages with each check-in.
+- **NEVER** check in commented-out code or unnecessary files.
+
+## Testing
+
+- **MANDATORY**: Write unit tests for all new methods and classes.
+- **ALWAYS** run the full test suite before committing your code to the repository.
+- **REQUIRED**: Aim for at least 80% code coverage in tests for all business logic classes.
+
+## API Design
+
+- **MUST** ensure that public APIs are intuitive and well-documented.
+- **ALWAYS** use consistent parameter ordering across similar methods.
+- `recommended`: Avoid breaking changes to public APIs.
+
+## Versioning
+
+- **MANDATORY**: Adhere to semantic versioning rules for all public software releases.
+- **ALWAYS** increment version numbers based on the extent of changes:
+  - **MAJOR** version when you make incompatible API changes,
+  - **MINOR** version when you add functionality in a backward-compatible manner,
+  - **PATCH** version when you make backward-compatible bug fixes.
+
+## Dependability
+
+- `recommended`: Rely on proven .NET libraries and frameworks rather than creating custom implementations.
+- **NEVER** ignore deprecation notices without assessing impact.
+
+This set of rules defines the essential guidelines that **MUST**, **SHOULD**, and **NEVER** be violated in any professional C# project as of 2025. These standards are in place to ensure reliability, security, and maintainability of code.

.github/copilot-csharp-csharp.md

@@ -0,0 +1,59 @@
+# C# Coding Standards for AI Coding Assistant 'copilot'
+
+## General Principles
+- **MANDATORY**: Adhere to the latest C# language version to ensure code uses the most current features and improvements.
+- **ALWAYS** write code that is clear, understandable, and maintainable.
+- **NEVER** use obsolete or deprecated C# features unless absolutely necessary for maintaining legacy systems.
+
+## Formatting and Style
+- **MUST** follow Microsoft's C# coding conventions regarding naming, layout, and commenting.
+  - Use PascalCase for class names and method names.
+  - Use camelCase for local variables and method arguments.
+  - **REQUIRED**: Place opening braces on a new line for classes, methods, and control statements.
+- **ALWAYS** indent code blocks with four spaces, not tabs.
+- **ALWAYS** use explicit typing over implicit var declarations, except in cases of obvious typing (e.g., instantiation).
+
+## Error Handling
+- **MANDATORY**: Handle all possible exceptions using try, catch, finally blocks where applicable.
+- **NEVER** allow exceptions to go unhandled unless explicitly justified by the application logic.
+- Exceptions **SHOULD** be logged with a detailed error message and, if applicable, stack trace.
+
+## Security Practices
+- **MUST** validate all inputs to prevent injection attacks and ensure data integrity.
+- **REQUIRED**: Utilize secure methods and libraries for handling sensitive data such as passwords, API keys, and personal user information.
+- **NEVER** log sensitive information.
+
+## Performance
+- **USE** async and await for asynchronous programming to improve application responsiveness and scalability.
+- **RECOMMENDED**: Optimize LINQ queries by minimizing data fetching and processing operations.
+- **SHOULD** prefer StringBuilder over string concatenation in loops or during extensive string manipulations.
+
+## Testing
+- **MANDATORY**: Write unit tests for all business logic to ensure code quality and catch regressions early.
+- Unit tests **SHOULD** cover both positive and negative scenarios.
+- **ALWAYS** use a consistent test naming convention that clearly describes the test purpose.
+
+## Code Reviews and Collaboration
+- **MUST** use pull requests for merging code into shared branches and repositories.
+- **ALWAYS** perform thorough code reviews to catch issues early and share knowledge among team members.
+- **REQUIRED**: Follow a defined Git workflow suitable for your team structure (e.g., Git flow, GitHub flow).
+
+## Documentation
+- **REQUIRED**: Document all public classes, methods, properties, and enums.
+- **ALWAYS** update documentation to reflect changes in the logic or implementation.
+- **SHOULD** include inline comments to clarify complex code blocks.
+
+## Dependency Management
+- **MANDATORY**: Keep external dependencies to a minimum to reduce potential security risks and lower the maintenance burden.
+- **ALWAYS** audit dependencies for security vulnerabilities on a regular schedule.
+- When new libraries are added, **SHOULD** assess their stability and support level.
+
+## Continuous Integration/Continuous Deployment
+- **MUST** have CI/CD pipelines in place to automate testing and deployment processes.
+- Deployment scripts **SHOULD** be tested regularly to prevent deployment failures.
+
+## Legacy Code and Migration
+- **ALWAYS** aim to incrementally refactor legacy code as part of ongoing development.
+- When dealing with legacy systems, **SHOULD** plan a clear migration path towards newer technologies or frameworks.
+
+These rules are designed to ensure that the AI coding assistant 'copilot' and its users adhere to the best practices and modern standards prevalent in C# development as of 2025.

.github/copilot-csharp-docker.md

@@ -0,0 +1,48 @@
+# C# Project Rules: Docker Integration
+
+## General Docker Practices
+
+- **MANDATORY**: All Dockerfiles **MUST** be located in the root of the project repository.
+- **MANDATORY**: Docker images **MUST** be built using official .NET base images from Docker Hub unless a specific need dictates otherwise.
+
+## Dockerfile Configuration
+
+- **REQUIRED**: The base image in the Dockerfile **MUST** match the .NET version used in the project.
+- **ALWAYS** use multi-stage builds to reduce the size of the final Docker image.
+  - The `build-env` for compiling the application.
+  - The `runtime-env` for the execution environment.
+- **NEVER** leave API keys, secrets, or other sensitive data in the Docker image.
+- **MANDATORY**: Docker build context **SHOULD** be kept as small as possible by properly setting `.dockerignore` files.
+- Environment variables **SHOULD** be used for application configurations that vary between environments (e.g., Development, Testing, Production).
+
+## Docker Compose Configurations
+
+- **REQUIRED**: Use Docker Compose for managing multi-container Docker applications.
+- **ALWAYS** define service dependencies explicitly in `docker-compose.yml`.
+- **MANDATORY**: Version of Docker Compose file **MUST** align with the latest supported Docker Engine and Compose specifications as of 2025.
+
+## CI/CD Integrations
+
+- **REQUIRED**: Integrate Docker builds into your CI/CD pipeline.
+- **MANDATORY**: Pull requests **MUST NOT** be merged unless the Docker image builds successfully.
+- **ALWAYS** tag Docker images with both a unique build tag and the `latest` tag in CI pipelines for easier rollback and deployment.
+
+## Security Best Practices
+
+- **MANDATORY**: Use Docker’s built-in security features such as `--cap-drop=all` and `readonly` filesystem where appropriate.
+- **MANDATORY**: Update the Docker images regularly to include the latest security patches for the base images and dependencies.
+- **ALWAYS** scan Docker images for vulnerabilities during CI/CD before pushing to a registry.
+- **REQUIRED**: Use private Docker registries for internal or sensitive projects.
+
+## Performance Optimizations
+
+- **MANDATORY**: Minimize the number of layers in Docker images where feasible by consolidating commands.
+- Images **SHOULD** leverage Docker cache layers by ordering Dockerfile instructions from least to most frequently changed.
+- **REQUIRED**: Performance critical settings, like CPU and memory limits, **MUST** be configured explicitly in Docker Compose configurations or Kubernetes deployment specs. 
+
+## Versioning and Tagging
+
+- **MANDATORY**: Docker images **MUST** be versioned appropriately using semantic versioning principles.
+- **ALWAYS** use explicit version tags rather than relying on mutable tags like `latest` for production deployments.
+
+By following these rules, the Docker integration for C# projects will adhere to modern standards and best practices as of 2025, ensuring efficiency, security, and maintainability.

.github/copilot-csharp-polyglot.md

@@ -0,0 +1,30 @@
+# C# Polyglot Coding Rules
+
+## General Practices
+- **ALWAYS** use clear and descriptive variable names in English, as C# is most commonly written and maintained in English.
+- **MANDATORY**: Maintain consistent code style and conventions across different languages used in the project to ensure readability and maintainability.
+- Code documentation **MUST** be in English to support international teams and contributors.
+
+## Handling Language Interoperability
+- **REQUIRED**: Ensure that all external libraries used for cross-language functionality are compatible with .NET standards.
+- **ALWAYS** encapsulate language-specific logic within boundary classes or namespaces.
+
+## Error Handling
+- **MANDATORY**: Handle all cross-language operation errors gracefully, ensuring the errors are logged and user-friendly messages are displayed.
+- **ALWAYS** use try-catch blocks around code that calls into different programming languages.
+
+## Security
+- **NEVER** expose direct interfaces of one language to another without appropriate security checks.
+- **MUST** validate all inputs when data crosses language boundaries to prevent injection attacks.
+
+## Performance
+- **MANDATORY**: Optimize inter-language calls to minimize performance overhead.
+- **RECOMMENDED**: Profile and monitor performance when implementing cross-language functionality to identify bottlenecks.
+
+## Testing
+- Integration tests **MUST** cover all polyglot components to ensure they work seamlessly together.
+- **REQUIRED**: Use mock objects and services to simulate interactions between different languages during unit testing.
+
+## Continuous Integration
+- **MANDATORY**: Set up CI pipelines to build and test across all targeted languages.
+- Code reviews **SHOULD** focus on the integration points between different languages to catch potential issues early.

.github/copilot-csharp-security.md

@@ -0,0 +1,46 @@
+# Security Rules for C# Projects
+
+## General Security Practices
+- **MANDATORY** : Always validate and sanitize all user inputs to prevent SQL injections, cross-site scripting (XSS), and other injection attacks.
+- **MUST** : Employ strong, up-to-date cryptographic practices for data encryption, signing, and hashing.
+- **ALWAYS** : Ensure that error messages do not reveal details about the backend system, such as file paths or component versions.
+
+## Authentication and Session Management
+- **MUST** : Implement secure authentication mechanisms like OAuth, OpenID Connect, or SAML.
+- **ALWAYS** : Use HTTPS and secure cookies (HttpOnly, Secure attributes) for session management.
+- **MANDATORY** : Implement multi-factor authentication for accessing sensitive data or operations.
+
+## Authorization
+- **MUST** : Enforce the Principle of Least Privilege (PoLP) throughout the application.
+- **ALWAYS** : Use role-based access control (RBAC) or attribute-based access control (ABAC) to manage user permissions.
+
+## Data Protection
+- **MANDATORY** : Encrypt sensitive data both at rest and in transit using industry-standard protocols and algorithms.
+- **MUST** : Properly manage and rotate keys and secrets using a secure vault solutions like Azure Key Vault or AWS Secrets Manager.
+
+## Code Security
+- **NEVER** : Leave debug code or secrets (API keys, passwords) in the version control system.
+- **MANDATORY** : Use static code analysis tools to automatically detect and rectify security vulnerabilities in the codebase.
+- **ALWAYS** : Perform regular code reviews with a focus on security implications and vulnerabilities.
+
+## External Dependencies
+- **REQUIRED** : Regularly update and patch all third-party libraries and frameworks to protect against known vulnerabilities.
+- **ALWAYS** : Vet external libraries for security vulnerabilities before including them in the project.
+
+## Logging and Monitoring
+- **ALWAYS** : Implement logging and monitoring to detect and respond to security breaches or irregular activity.
+- **NEVER** : Log sensitive data like passwords or personal identification information.
+
+## Network Security
+- **MUST** : Protect all network communications with TLS.
+- **ALWAYS** : Implement strong network isolation and segmentation strategies to limit the blast radius in case of a network intrusion.
+
+## Incident Response
+- **REQUIRED** : Have an incident response plan that includes immediate actions, reporting to stakeholders, and remedial steps.
+- **MANDATORY** : Conduct regular security drills to ensure that all team members know their roles in case of a security incident.
+
+## Compliance
+- **ALWAYS** : Adhere to relevant industry security standards and regulations, such as GDPR, PCI DSS, or HIPAA, depending on the project scope.
+- **MANDATORY** : Undergo regular security audits and compliance checks to maintain system integrity and trust.
+
+By following these rules, C# projects can mitigate security risks and protect user data effectively.

.github/copilot-csharp-testing.md

@@ -0,0 +1,59 @@
+# C# Project Testing Guidelines
+
+## General Principles
+
+- **MANDATORY**: Use a recognized testing framework such as NUnit, xUnit, or MSTest for unit testing.
+- **ALWAYS** ensure each test case is independent and can be run in any order.
+- **REQUIRED**: Maintain a clean separation of test logic from production code.
+- **MUST** configure Continuous Integration (CI) to run tests automatically upon code pushes or pull requests.
+
+## Writing Tests
+
+### Structure
+
+- **MANDATORY**: Structure tests logically using [Arrange-Act-Assert (AAA)](https://www.typemock.com/unit-test-patterns-for-net) pattern.
+- **MUST** name test methods clearly to reflect the behavior being tested.
+
+### Assertions
+
+- **MUST** use assertive statements that make the test purpose clear.
+- **REQUIRED**: Employ fluent assertions for more readable tests.
+
+### Code Coverage
+
+- **MANDATORY**: Aim for at least 80% code coverage to ensure most of the code is scrutinized by tests.
+- **RECOMMENDED**: Use tools such as Coverlet or Visual Studio Coverage tools to measure test coverage.
+
+## Test Isolation
+
+- **ALWAYS** use mocks and stubs to isolate the unit of work and avoid external dependencies in unit tests.
+- **MANDATORY**: Employ frameworks like Moq, NSubstitute, or FakeItEasy for mocking.
+
+## Test Data
+
+- **MUST** handle test data carefully, ensuring no leakage between tests.
+- **ALWAYS** prefer the use of in-memory databases like EF Core InMemory provider for integration testing.
+
+## Performance
+
+- **RECOMMENDED**: Regularly review and optimize the performance of test suites.
+- **SHOULD** avoid long-running tests in the primary test suite to keep the CI process efficient.
+
+## Security
+
+- **NEVER** use real data in testing environments to avoid risks of sensitive data exposure.
+- **ALWAYS** ensure tests validate input sanitation and adheres to security best practices.
+
+## Documentation
+
+- **REQUIRED**: Document the testing strategy and major choices in a TESTPLAN.md file.
+- Tests **SHOULD** include inline comments where necessary to explain complex logic or decisions.
+
+## Error Handling
+
+- **MANDATORY**: Tests **MUST** assert appropriate error handling in the application code and never ignore exceptions unless explicitly testing exception handling scenarios.
+
+## Maintenance
+
+- **NEVER** allow failing tests to accumulate or remain unfixed.
+- **SHOULD** regularly review and refactor tests to improve clarity and maintainability.

.gitignore

@@ -286,4 +286,5 @@ tools
 
 # sqlite database
 *.db-shm
-*.db-wal
+*.db-wal
+*.db

.rules4rc

@@ -0,0 +1,5 @@
+[settings]
+language = c#
+tags = best-practices,c#,docker,security,testing
+tools = copilot
+