Add NetEvolve.HealthChecks.Azure.IotHub package

.github/copilot-instructions.md

@@ -1,51 +1,12 @@
-# Instructions for GitHub and VisualStudio Copilot
+---
+applyTo: '**/*.*'
+description: 'This file contains instructions for AI coding assistants, redirecting to the primary instruction set in AGENTS.md.'
+---
 
-## General
+# Copilot Instructions
 
-* Make only high confidence suggestions when reviewing code changes.
-* Always use the latest version C#, currently C# 13 features.
-* Never change `global.json` unless explicitly asked to.
-* Never change `Directory.Build.props` unless explicitly asked to.
-* Never change `Directory.Build.targets` unless explicitly asked to.
-* Never change `Directory.Packages.props` unless explicitly asked to.
+## Reference
 
-## Code Style
-
-* Use `var` when the type is obvious from the right side of the assignment.
-* Use `Argument.ThrowIfNull(x)` instead of `if (x == null) throw new ArgumentNullException(nameof(x))`, when nuget package `NetEvolve.Arguments` is referenced.
-* Use `ArgumentNullException.ThrowIfNull(x)` instead of `if (x == null) throw new ArgumentNullException(nameof(x))`, when nuget package `NetEvolve.Arguments` is not referenced.
-
-## Formatting
-
-* Apply code-formatting style defined in `.editorconfig`.
-* Prefer file-scoped namespace declarations and single-line using directives.
-* Insert a newline before the opening curly brace of any code block (e.g., after `if`, `for`, `while`, `foreach`, `using`, `try`, etc.).
-* Ensure that the final return statement of a method is on its own line.
-* Use pattern matching and switch expressions wherever possible.
-* Use `nameof` instead of string literals when referring to member names.
-* Ensure that XML doc comments are created for any public APIs. When applicable, include `<inheritdoc />` for derived members.
-
-### Arrays and Collections
-
-* Prefer `Enumerable.Empty<T>()` or `Array.Empty<T>()` over `null` returns.
-
-## Nullable Reference Types
-
-* Declare variables non-nullable, and check for `null` at entry points.
-* Always use `is null` or `is not null` instead of `== null` or `!= null`.
-* Trust the C# null annotations and don't add null checks when the type system says a value cannot be null.
-* Apply `NotNullAttribute` and other nullable attributes for any public APIs.
-
-## Testing
-
-* We prefer to use [TUnit](https://github.com/thomhurst/TUnit) with [Microsoft.Testing.Platform](https://learn.microsoft.com/dotnet/core/testing/microsoft-testing-platform-intro).
-* If TUnit is not available, we use [XUnit](https://xunit.net/).
-* Do not emit "Act", "Arrange" or "Assert" comments.
-* We do not use any mocking framework at the moment.
-* Copy existing style in nearby files for test method names and capitalization.
-
-### Running tests
-
-1. Build from the root with `dotnet build <solutionfile>`.
-2. If that produces errors, fix those errors and build again. Repeat until the build is successful.
-3. To then run tests, use a command similar to this `dotnet test <solutionfile>` (using the path to whatever projects are applicable to the change).
+* MUST follow all instructions defined in the root-level document [`AGENTS.md`](../AGENTS.md).
+* MUST treat [`AGENTS.md`](../AGENTS.md) as the authoritative source for all AI assistant guidelines.
+* MUST apply all directives from [`AGENTS.md`](../AGENTS.md) when implementing code, reviewing code, suggesting improvements, debugging issues, or providing any form of technical assistance.

.github/instructions/blazor.instructions.md

@@ -0,0 +1,86 @@
+---
+applyTo: '**/*.razor, **/*.razor.cs, **/*.razor.css'
+
+description: 'This file contains instructions for Blazor development.
+  It includes guidelines for component development, performance optimization, and following Blazor coding standards.
+  Ensure to follow the practices outlined in this file to maintain code quality and consistency.'
+---
+
+# Blazor Development Instructions
+
+## General
+
+* MUST write idiomatic and efficient Blazor and C# code.
+* MUST follow .NET and Blazor conventions and best practices.
+* MUST use Razor Components appropriately for component-based UI development.
+* MUST use the latest version C#, currently C# 13 features like record types, pattern matching, and global usings.
+* MUST use async/await where applicable to ensure non-blocking UI operations.
+
+## Code Style and Structure
+
+* MUST prefer inline functions for smaller components but separate complex logic into code-behind or service classes.
+* MUST structure Blazor components and services following Separation of Concerns principles.
+* MUST follow PascalCase for component names, method names, and public members.
+* MUST use camelCase for private fields and local variables.
+* MUST prefix interface names with "I" (e.g., `IUserService`).
+
+## Component Lifecycle and Data Binding
+
+* MUST utilize Blazor's built-in features for component lifecycle (e.g., `OnInitializedAsync`, `OnParametersSetAsync`).
+* MUST use data binding effectively with `@bind` directive.
+* MUST leverage Dependency Injection for services in Blazor components.
+* MUST use `EventCallbacks` for handling user interactions efficiently, passing only minimal data when triggering events.
+
+## Performance Optimization
+
+* MUST optimize Razor components by reducing unnecessary renders and using `StateHasChanged()` efficiently.
+* MUST minimize the component render tree by avoiding re-renders unless necessary, using `ShouldRender()` where appropriate.
+* MUST use asynchronous methods (`async`/`await`) for API calls or UI actions that could block the main thread.
+* MUST utilize Blazor server-side or WebAssembly optimally based on the project requirements.
+
+## Error Handling and Validation
+
+* MUST implement proper error handling for Blazor pages and API calls using try-catch blocks.
+* MUST use logging for error tracking in the backend and consider capturing UI-level errors in Blazor with tools like `ErrorBoundary`.
+* MUST implement validation using FluentValidation or DataAnnotations in forms.
+* MUST provide proper user feedback in the UI for error conditions.
+
+## Caching Strategies
+
+* MUST implement in-memory caching for frequently used data, especially for Blazor Server apps using `IMemoryCache`.
+* MUST utilize `localStorage` or `sessionStorage` to cache application state between user sessions for Blazor WebAssembly.
+* MUST consider Distributed Cache strategies (like Redis or SQL Server Cache) for larger applications that need shared state.
+* MUST cache API calls by storing responses to avoid redundant calls when data is unlikely to change.
+
+## State Management
+
+* MUST use Blazor's built-in Cascading Parameters and EventCallbacks for basic state sharing across components.
+* MUST implement advanced state management solutions using libraries like Fluxor or BlazorState when the application grows in complexity.
+* MUST use Blazored.LocalStorage or Blazored.SessionStorage for client-side state persistence in Blazor WebAssembly.
+* MUST use Scoped Services and the StateContainer pattern for server-side Blazor to manage state within user sessions.
+
+## API Integration
+
+* MUST use `HttpClient` or other appropriate services to communicate with external APIs or backend services.
+* MUST implement comprehensive error handling for API calls and provide meaningful user feedback.
+* MUST use HTTPS for all web communication and ensure proper CORS policies are implemented.
+
+## Security and Authentication
+
+* MUST implement Authentication and Authorization in Blazor applications where necessary using ASP.NET Identity or JWT tokens.
+* MUST ensure proper security measures are in place for API authentication and data protection.
+* MUST validate all user inputs and implement proper authorization checks.
+
+## Testing and Debugging
+
+* MUST perform all unit testing and integration testing using Visual Studio Enterprise.
+* MUST test Blazor components and services using TUnit (preferred) or xUnit/NUnit/MSTest.
+* MUST use appropriate mocking frameworks for testing dependencies.
+* MUST debug Blazor UI issues using browser developer tools and Visual Studio's debugging tools.
+* MUST use Visual Studio's diagnostics tools for performance profiling and optimization.
+
+## Documentation
+
+* MUST use Swagger/OpenAPI for API documentation for backend API services.
+* MUST ensure XML documentation for models and API methods to enhance Swagger documentation.
+* MUST document complex component logic and business rules for maintainability.

.github/instructions/csharp.instructions.md

@@ -0,0 +1,66 @@
+---
+applyTo: '**/*.cs'
+
+description: 'This file contains instructions for C# development.
+  It includes guidelines for using GitHub Copilot, managing dependencies, and following coding standards.
+  Ensure to follow the practices outlined in this file to maintain code quality and consistency.'
+---
+
+# C# Development Instructions
+
+## General
+
+* The project MUST use the latest version C#, currently C# 13 features.
+* MUST follow standard C# coding conventions (naming, indentation, spacing).
+* MUST implement robust error handling with try-catch blocks and meaningful messages.
+* MUST write unit tests for all critical functionalities.
+* MUST always review AI-generated code for correctness, security, and performance.
+
+## Code Style
+
+Follow these C# coding conventions for consistency across the project.
+
+* MUST use `var` when the type is obvious from the right side of the assignment.
+* MUST use `Argument.ThrowIfNull(x)` instead of `if (x == null) throw new ArgumentNullException(nameof(x))`, when nuget package `NetEvolve.Arguments` is referenced.
+* MUST use `ArgumentNullException.ThrowIfNull(x)` instead of `if (x == null) throw new ArgumentNullException(nameof(x))`, when nuget package `NetEvolve.Arguments` is not referenced.
+
+## Formatting
+
+Apply code-formatting style defined in `.editorconfig`.
+
+* MUST prefer file-scoped namespace declarations and single-line using directives.
+* MUST insert a newline before the opening curly brace of any code block (e.g., after `if`, `for`, `while`, `foreach`, `using`, `try`, etc.).
+* MUST ensure that the final return statement of a method is on its own line.
+* MUST use pattern matching and switch expressions wherever possible.
+* MUST use `nameof` instead of string literals when referring to member names.
+* MUST ensure that XML doc comments are created for any public APIs. When applicable, include `<inheritdoc />` for derived members.
+
+## Arrays and Collections
+
+* MUST prefer `Enumerable.Empty<T>()` or `Array.Empty<T>()` over `null` returns.
+
+## Nullable Reference Types
+
+Declare variables non-nullable, and check for `null` at entry points.
+
+* MUST always use `is null` or `is not null` instead of `== null` or `!= null`.
+* MUST trust the C# null annotations and don't add null checks when the type system says a value cannot be null.
+* MUST apply `NotNullAttribute` and other nullable attributes for any public APIs.
+
+## Testing
+
+* MUST prefer to use [TUnit](https://github.com/thomhurst/TUnit) with [Microsoft.Testing.Platform](https://learn.microsoft.com/dotnet/core/testing/microsoft-testing-platform-intro).
+* If TUnit is not available, MUST use [XUnit](https://xunit.net/).
+* MUST NOT emit `Act`, `Arrange` or `Assert` comments.
+* MUST NOT use any mocking framework at the moment.
+* MUST copy existing style in nearby files for test method names and capitalization.
+
+## Build and test AI-generated code
+
+1. Build from the root with `dotnet build <solutionfile>.slnx`.
+2. If that produces errors, fix those errors and build again. Repeat until the build is successful.
+3. Run tests with `dotnet test <solutionfile>.slnx`.
+4. If tests fail, analyze the failures and fix the code. Do not ignore failing tests.
+5. Verify that all new code has appropriate test coverage.
+6. Run a final build to ensure everything compiles successfully after all changes.
+

.github/instructions/tsql.instructions.md

@@ -0,0 +1,114 @@
+---
+applyTo: '**/*.sql'
+
+description: 'This file contains instructions for T-SQL development.
+  It includes guidelines for database schema design, query optimization, and following SQL coding standards.
+  Ensure to follow the practices outlined in this file to maintain code quality and consistency.'
+---
+
+# T-SQL Development Instructions
+
+## General
+
+* MUST follow standard T-SQL coding conventions for naming, indentation, and spacing.
+* MUST implement robust error handling with TRY-CATCH blocks and meaningful error messages.
+* MUST always review AI-generated SQL code for correctness, security, and performance.
+* MUST parameterize all queries to prevent SQL injection attacks.
+* MUST consider performance, maintainability, and business impact when designing database solutions.
+
+## Database Schema Design
+
+Follow these database design principles for consistency across the project.
+
+* MUST use singular form for all table names (e.g., `Customer`, not `Customers`).
+* MUST use singular form for all column names (e.g., `Name`, not `Names`).
+* MUST include a primary key column named `Id` in all tables.
+* MUST include a `CreatedAt` column to store the creation timestamp in all tables.
+* MUST include an `UpdatedAt` column to store the last update timestamp in all tables.
+
+## Constraints and Relationships
+
+* MUST define primary key constraints on all tables.
+* MUST provide explicit names for all foreign key constraints.
+* MUST define foreign key constraints inline with column definitions.
+* MUST use `ON DELETE CASCADE` option for foreign key constraints where appropriate.
+* MUST use `ON UPDATE CASCADE` option for foreign key constraints where appropriate.
+* MUST ensure foreign key constraints reference the primary key of the parent table.
+
+## Code Style
+
+Follow these T-SQL coding conventions for consistency across the project.
+
+* MUST use UPPERCASE for SQL keywords (`SELECT`, `FROM`, `WHERE`, `INSERT`, `UPDATE`, `DELETE`).
+* MUST use consistent indentation (4 spaces) for nested queries and conditional statements.
+* MUST qualify column names with table name or alias when using multiple tables.
+* MUST organize query clauses consistently: `SELECT`, `FROM`, `JOIN`, `WHERE`, `GROUP BY`, `HAVING`, `ORDER BY`.
+* MUST break long queries into multiple lines for improved readability.
+* MUST quote identifiers (schema names, table names, column names and alias names) with square brackets `[]` when necessary to avoid conflicts with reserved keywords.
+* MUST use meaningful table aliases (e.g., `cust` for Customer, `ord` for Order) instead of single letters.
+* MUST align commas consistently (either leading or trailing, but be consistent within the project).
+* MUST use proper spacing around operators (`=`, `<>`, `>`, `<`, etc.).
+
+## Query Structure and Performance
+
+* MUST use explicit column names in `SELECT` statements instead of `SELECT *`.
+* MUST limit the use of subqueries when `JOIN` operations can be used instead.
+* MUST include `TOP` or `OFFSET`/`FETCH` clauses to restrict result sets when appropriate.
+* MUST avoid using functions on indexed columns in `WHERE` clauses.
+* MUST use appropriate indexing strategies for frequently queried columns.
+* MUST use `EXISTS` instead of `IN` when checking for existence with subqueries.
+* MUST use `UNION ALL` instead of `UNION` when duplicates are acceptable for better performance.
+* MUST consider query execution plans and optimize based on actual performance metrics.
+* MUST use Common Table Expressions (CTEs) for complex queries to improve readability.
+* MUST implement pagination using `OFFSET` and `FETCH NEXT` for modern T-SQL versions.
+
+## Stored Procedures
+
+### Naming Conventions
+
+* MUST prefix stored procedure names with `usp_` (e.g., `usp_GetCustomerOrders`).
+* MUST use PascalCase for stored procedure names.
+* MUST use descriptive names that clearly indicate the procedure's purpose.
+* MUST use plural nouns when returning multiple records (e.g., `usp_GetProducts`).
+* MUST use singular nouns when returning a single record (e.g., `usp_GetProduct`).
+* MUST include the entity name in the procedure name for clarity (e.g., `usp_CreateCustomer`, `usp_UpdateOrder`).
+
+### Parameter Handling
+
+* MUST prefix all parameters with `@` symbol.
+* MUST use camelCase for parameter names (e.g., `@customerId`, `@orderDate`).
+* MUST provide default values for optional parameters.
+* MUST validate parameter values before processing.
+* MUST document all parameters with descriptive comments.
+* MUST arrange parameters consistently (required parameters first, optional parameters later).
+
+### Structure and Documentation
+
+* MUST include a header comment block with procedure description, parameter details, and return values.
+* MUST return standardized error codes and meaningful error messages.
+* MUST return result sets with consistent column ordering.
+* MUST use `OUTPUT` parameters for returning status information when appropriate.
+* MUST prefix temporary tables with `tmp_` (e.g., `tmp_CustomerData`).
+
+## Security Best Practices
+
+* MUST parameterize all dynamic queries to prevent SQL injection vulnerabilities.
+* MUST use prepared statements when executing dynamic SQL.
+* MUST avoid embedding credentials or sensitive information in SQL scripts.
+* MUST implement proper error handling without exposing internal system details.
+* MUST minimize the use of dynamic SQL within stored procedures.
+
+## Transaction Management
+
+* MUST explicitly begin and commit transactions using `BEGIN TRANSACTION` and `COMMIT`.
+* MUST use appropriate isolation levels based on business requirements.
+* MUST avoid long-running transactions that could cause table locking issues.
+* MUST use batch processing techniques for large data operations.
+* MUST include `SET NOCOUNT ON` in stored procedures that modify data.
+* MUST implement proper rollback logic in error handling scenarios.
+
+## Comments and Documentation
+
+* MUST include comments to explain complex business logic and query operations.
+* MUST document any non-obvious performance optimizations or workarounds.
+* MUST provide examples of expected input parameters and result sets in procedure headers.