This document describes the centralized build system that manages compilation, packaging, and distribution for all ThingsGateway plugins. The build system provides consistent configuration across 10+ plugin projects through MSBuild property files, enabling independent versioning, multi-framework targeting, comprehensive code analysis, and automated NuGet package generation.
For details on individual plugin project structures, see Project Structure and Conditional Dependencies. For runtime plugin loading and lifecycle management, see Plugin Base Classes and Lifecycle Management.
The build system uses MSBuild's Directory.Build.props mechanism to apply shared configuration to all plugin projects in the repository. This centralized approach ensures consistency while allowing individual plugins to maintain independent release cycles.
Sources: Directory.Build.props1-56
The build system maintains three independent version streams to enable flexible component releases while ensuring compatibility between the plugin ecosystem and the core platform.
| Version Variable | Value | Purpose | Usage |
|---|---|---|---|
FoundationVersion | 12.5.5 | ThingsGateway.Foundation package version | Referenced by data collection plugins (OpcUa, Modbus, S7, etc.) |
GatewayVersion | 12.5.4 | ThingsGateway.Gateway.Application package version | Referenced by business logic plugins (Kafka, MQTT Server, SqlDB, etc.) |
PluginVersion | 12.5.6 | Plugin package version | Applied to all plugin NuGet packages as $(Version) |
The version variables are defined in Directory.Build.props18-22 and consumed by conditional dependency resolution logic (see Project Structure and Conditional Dependencies).
Sources: Directory.Build.props18-22
The build system supports six target frameworks to ensure compatibility across different deployment scenarios, from legacy Windows systems to modern cloud-native environments.
| Framework | Version | Purpose | Platform Support |
|---|---|---|---|
net8.0 | 8.0.25 | Primary target for current production deployments | Cross-platform (Windows, Linux, macOS) |
net10.0 | 10.0.5 | Next-generation .NET support | Cross-platform (Visual Studio 18.0+ or MSBuild 18.0+) |
net6.0 | - | Long-term support compatibility | Cross-platform |
net462 | - | Legacy .NET Framework support | Windows only |
netstandard2.0 | - | Maximum library compatibility | Cross-platform |
netstandard2.1 | - | Enhanced standard library features | Cross-platform |
The net10.0 framework is conditionally included based on tooling version:
Condition="'$(VisualStudioVersion)' >= '18.0' OR $([MSBuild]::VersionGreaterThanOrEquals('$(MSBuildVersion)','18.0'))"
This prevents build failures on older development environments while enabling cutting-edge features for developers with updated tooling.
For legacy frameworks (net462, netstandard2.0), package pruning is disabled to ensure correct restoration under .NET 10 SDK:
RestoreEnablePackagePruning = False when TargetFramework is net462 or netstandard2.0
Sources: Directory.Build.props3-9 Directory.Build.props28-29
The build system enables comprehensive static code analysis across all plugin projects to enforce quality standards and catch potential issues early.
All code analysis modes are set to All, enabling the most rigorous checks:
| Analysis Mode | Setting | Purpose |
|---|---|---|
AnalysisModeDocumentation | All | XML documentation completeness |
AnalysisModeInteroperability | All | Platform invoke and COM interop safety |
AnalysisModeMaintainability | All | Code complexity and maintainability |
AnalysisModePerformance | All | Performance best practices |
AnalysisModeSingleFile | All | Single-file application compatibility |
AnalysisModeReliability | All | Runtime reliability and correctness |
AnalysisModeSecurity | All | Security vulnerabilities and best practices |
Configured in Directory.Build.props38-45
The build system strategically suppresses 80+ warning codes to reduce noise from known false positives while maintaining strict analysis for genuine issues. The suppressed warnings fall into several categories:
Complete list defined in Directory.Build.props14-17
Sources: Directory.Build.props36-46 Directory.Build.props14-17
| Property | Value | Effect |
|---|---|---|
LangVersion | preview | Enables experimental C# language features |
ImplicitUsings | enable | Automatic using directives for common namespaces |
Nullable | enable | Nullable reference types enabled project-wide |
| Property | Value | Purpose |
|---|---|---|
SatelliteResourceLanguages | zh-Hans;en-US | Limit embedded resource cultures to Chinese and English |
InvariantGlobalization | false | Enable full globalization support (do not use invariant mode) |
The InvariantGlobalization setting is explicitly set to false to support localized industrial protocols and user interfaces across different regions.
Sources: Directory.Build.props25-32
All plugin projects automatically generate NuGet packages during the build process. The packages are output to a centralized location for local testing and distribution.
For detailed package metadata configuration, see NuGet Package Configuration and Distribution.
Sources: Directory.Build.props21-22 Directory.Build.props48-50
The build system implements intelligent dependency resolution that adapts based on whether plugins are being developed in a monorepo environment or as standalone packages.
| Mode | When Used | Advantages | Dependency Mechanism |
|---|---|---|---|
| Monorepo | Developing all components together | Immediate source changes, debugging across boundaries | Direct project references to ../../../ThingsGateway/... |
| Standalone | Plugin-only development or package consumption | Faster build times, smaller repository clone | NuGet package references with explicit versions |
This pattern is implemented in individual plugin .csproj files using MSBuild conditionals, which are detailed in Project Structure and Conditional Dependencies.
Sources: Directory.Build.props18-20
The Directory.Build.props file itself is included in the NuGet package metadata to provide transparency about build configuration:
Note: Pack="false" prevents the props file from being included in the actual package, but makes it visible in package explorers.
Sources: Directory.Build.props48-50
Refresh this wiki