Skip to content

DHI Public NuGet Packages Policy

Contacts
Guidelines Owner sksh
Task force sksh; jgr; dest; pelo
Stakeholders frt; aug; lete; akf; fari
Approver(s) Architecture Board

Overview

This policy governs the publication and management of DHI NuGet packages on nuget.org, ensuring consistent quality, security, and governance for packages that represent DHI's public software offerings. Given DHI's position as a global leader in water and environmental software solutions, public packages serve as critical distribution channels for MIKE Software components and related libraries to external clients, partners, and the broader engineering community.

Business Objectives:

  • Maintain DHI's reputation for high-quality engineering software
  • Ensure secure and reliable distribution of MIKE Software components
  • Support client integration scenarios while protecting intellectual property
  • Establish consistent branding and quality standards across public offerings

Document Structure: This policy is organized into the following sections to guide different stakeholders through relevant requirements:

Scope and Applicability

Purpose: This section defines exactly which packages and scenarios fall under this policy's governance, ensuring clear boundaries and preventing confusion about when these requirements apply.

Covered Package Types

  • MIKE Software SDKs and APIs: Core libraries enabling client integration with MIKE products
  • DHI Utilities and Tools: General-purpose libraries supporting the development and engineering community
  • Open-Source Components: DHI-contributed libraries benefiting the broader engineering community
  • Client Integration Libraries: Packages designed explicitly for partner/client consumption

Exclusions

  • Internal development libraries (covered by Internal Packages Policy)
  • Experimental or prototype packages (use Project Packages until proven)
  • Region-specific or client-specific customizations
  • Packages containing proprietary algorithms or sensitive intellectual property

Package Classification and Requirements

Purpose: Different packages carry different business risks and consumer expectations. This tiered approach ensures that mission-critical MIKE Software components receive the highest level of oversight, while allowing more flexibility for community contributions. The classification system balances quality assurance with development velocity.

Tier 1: MIKE Software Core Components

Definition: Essential libraries for MIKE Software integration. Example: DHI.PFS, DHI.EUM

Requirements:

  • Minimum 2 architect approvals from different impact areas
  • Comprehensive automated testing (>80% code coverage)
  • Professional documentation with examples
  • Signed assemblies and packages
  • LTS support commitment (minimum 2 years)
  • README documentation with usage examples (see NuGet README best practices)

Tier 2: DHI Professional Libraries

Definition: High-quality utilities supporting engineering workflows. Example: DHI.Services, DHI.Workflow.Actions.Core

Requirements:

  • Single architect approval + peer review
  • Automated testing (>80% code coverage)
  • Standard documentation with API reference
  • Signed packages
  • Standard support commitment (minimum 1 year)
  • README documentation with usage examples (see NuGet README best practices)

Tier 3: Community Contributions

Definition: Open source libraries benefiting the engineering community. Example: DHI.Mesh

Requirements:

  • Package Owner approval + architecture review
  • Basic automated testing (>70% code coverage)
  • README documentation with usage examples (see NuGet README best practices)
  • Community support model

Note: Code coverage percentages represent minimum thresholds for critical path testing, not targets. Quality and relevance of tests matter more than achieving exact percentages. Focus tests on critical business logic, error handling, and integration points. Refer to DHI Testing Guidelines for detailed test strategy guidance

Publication Workflow

Purpose: A structured publication process ensures consistent quality, prevents security vulnerabilities from reaching production, and maintains DHI's reputation. The workflow balances thorough validation with development efficiency, using automation where possible to reduce manual overhead while maintaining necessary human oversight.

Pre-Publication Requirements (Process for new packages)

1. Package Design Review

Purpose: Validates that the package aligns with DHI's architecture standards and business objectives before development investment. Pre-releases to be published in the internal stream before releasing to the public NuGet.org.

- [ ] Package scope and purpose clearly defined
- [ ] Appropriate tier classification assigned
- [ ] Dependencies reviewed and approved (ex. Ensure there is no internal dependency for public packages)

2. Quality Gates

Purpose: Ensures technical excellence and prevents defects from reaching consumers through automated and manual validation.

- [ ] All automated tests passing and manual testing approved by the product owner
- [ ] Code coverage meets tier requirements (Refer to Testing Guideline)
- [ ] Security scan completed with no high/critical issues (Refer to Security Guideline)
- [ ] Documentation review completed
- [ ] API stability review completed

Publication Process (publishing a new version of an existing package)

Step 1: Package Preparation

Purpose: Ensures packages are built consistently with all required security and quality measures before entering the approval pipeline.

  1. Apply required package metadata and Source Link
  2. Sign with DHI strong name and authentication certificates (Refer to CI/CD guidelines for details)
  3. Configure deterministic builds with CI flags
  4. Always start with pre-release identifiers (e.g., 1.0.0-rc1)

Step 2: Internal Validation

Purpose: Validates package functionality and performance in a controlled environment before external exposure, catching issues early in the process.

  1. Deploy to dhi-public-staging feed (internal NuGet feed - currently under setup)
  2. Validate against consumer scenarios using pre-release version
  3. Verify performance benchmarks where applicable
  4. Run vulnerability assessment and dependency analysis
  5. Ensure README and API documentation accuracy

Step 3: Approval Workflow

Purpose: Provides appropriate oversight and risk management through tiered approval based on package criticality and business impact.

  1. Package Maintainer submits for review via Azure DevOps
  2. CI/CD pipeline validates all requirements
  3. Technical lead or architect approval
  4. Security team automated scan + manual review for Tier 1 and Tier 2
  5. Architecture Board approval (Tier 1 only for new packages)

Step 4: Production Release

Purpose: Ensures that only thoroughly tested packages reach production while maintaining traceability between test and production artifacts.

  1. Convert approved pre-release to stable version (no rebuild)
  2. Authorized Package Owner publishes stable version
  3. Remove pre-release from staging, publish to production feeds
  4. Automated stakeholder notification via DevOps integration
  5. Package health monitoring and dependency tracking configured

Package Standards and Requirements

Purpose: Consistent standards ensure that all DHI packages are professional, discoverable, and maintainable. These requirements protect DHI's brand while making packages easy for consumers to identify, trust, and integrate into their solutions.

Naming Conventions

Purpose: Clear naming prevents conflicts, ensures brand recognition, and makes packages easily discoverable by DHI customers and partners.

Primary Namespace: DHI.*

Product-Specific: ex. DHI.Mike.*, DHI.FeFlow.*

Utility Libraries/Tools: ex. DHI.Services.*, DHI.Workflow.*

Prohibited Names:

  • Generic terms without DHI prefix
  • Names conflicting with Microsoft or other major vendors
  • Region-specific or client-specific identifiers

Prefix Reservation: Confirm DHI.* prefix with nuget.org for brand protection

Version Management

Purpose: Proper versioning communicates compatibility expectations to consumers, enables safe automated updates, and follows industry standards that developers understand. The repackaging approach ensures that production deployments use exactly the same code that was tested, eliminating "works on my machine" issues.

Strategy: Semantic Versioning (SemVer) 2.0 with Enterprise Practices

Format: MAJOR.MINOR.PATCH[-prerelease][+build]

Requirements:

  • Major version for breaking changes
  • Minor version for backward-compatible features
  • Patch version for backward-compatible fixes
  • Mandatory pre-release versions for all initial builds (e.g., 1.0.0-rc1, 1.0.0-beta.1) to be published in dhi-internal-staging feed
  • Repackaging process for production releases (convert pre-release to stable version)

Build Workflow:

  1. All packages initially built with pre-release identifiers
  2. Testing and validation on pre-release versions
  3. Repackaging to stable version for production release
  4. Never rebuild packages - always repackage tested artifacts

Package Metadata Requirements

Purpose: Rich metadata improves package discoverability, provides essential information to consumers, and supports debugging and compliance tracking. Reproducible builds enable better developer experiences and security validation.

Required Elements:

  • README.md: Mandatory package documentation
  • Icon: DHI-branded package icon (64x64 PNG minimum)
  • Symbol packages: Publish separate symbol packages (.snupkg)
  • Reproducible builds: Enable deterministic and CI build flags
  • Version: Semantic versioning (SemVer 2.0) or agreed versioning
  • Description*: Minimum 100 characters, clear package purpose statement
  • Author: DHI
  • Owners: DHI

Security Requirements

Package Integrity

Purpose: Digital signatures and reproducible builds provide cryptographic proof of package authenticity and enable detection of tampering, protecting both DHI and consumers from supply chain attacks.

  • Author signing: All packages must be signed with DHI's author certificate
  • Strong name signing: Required for all assemblies in packages
  • Package signing: Repository signing by nuget.org (automatic)

Vulnerability Management

Purpose: Proactive vulnerability management protects DHI's reputation and customer environments by ensuring security issues are identified and addressed quickly before they impact production systems.

  • Automated vulnerability scanning: Pre-publication assessments
  • CVE response timeline:
    • Critical vulnerabilities: 1 Week response
    • High vulnerabilities: 1 month response
    • Medium/Low: Next scheduled release

Access Control and Certificate Management

Purpose: Secure credential management and access controls prevent unauthorized package publication and ensure that only trusted personnel can publish packages representing DHI's brand.

  • API key management: Store in Azure Key Vault with restricted access
  • Multi-factor authentication: Required for all publishing accounts
  • Certificate lifecycle management:
    • Annual certificate review and renewal
    • Automated rotation for expiring certificates
    • Backup certificates are maintained securely
  • Principle of least privilege: Package-specific permissions where possible

Lifecycle Management

Purpose: Clear lifecycle management ensures packages remain supportable throughout their useful life while providing consumers with predictable support commitments and migration paths when packages reach end-of-life.

Release Management

Release Cadence: Coordinated with MIKE Software release schedule, where relevant

Emergency Releases: Security or critical bug fixes only

Communication: 30-day advance notice for breaking changes

Support Lifecycle

Purpose: Clear support commitments help consumers make informed decisions about package adoption and provide predictable resource planning for DHI's support teams.

Tier 1 Packages: 2-year LTS support minimum

Tier 2 Packages: 1-year standard support minimum

Tier 3 Packages: Community support model

Deprecation Process

Purpose: Structured deprecation protects existing consumers while allowing DHI to retire obsolete packages, providing sufficient notice and migration assistance to minimize business disruption.

  1. 6-Month Notice: Deprecation announcement with timeline
  2. Alternative Guidance: Migration path documentation provided
  3. Grace Period: Extended support during transition
  4. Final Notice: 30-day final warning before removal
  5. Package Unlisting: Remove from search results
  6. Documentation Archive: Maintain historical documentation

Compliance and Monitoring

Purpose: Continuous monitoring and compliance tracking ensure the policy remains effective, packages stay secure, and DHI maintains visibility into the health and usage of its public package ecosystem. This data drives informed decisions about resource allocation and process improvements.

Monitoring Requirements

Package Health Metrics:

  • Download statistics and trend analysis
  • Dependency vulnerability tracking (automated via NuGet / Snyk Audit)
  • Consumer impact assessment
  • License compliance tracking for all dependencies
  • SBOM (Software Bill of Materials) generation and maintenance

Compliance Metrics:

  • Policy adherence scoring with automated reporting
  • Security scan compliance (100% requirement)
  • Documentation completeness assessment
  • Support response times and SLA compliance
  • SCA for all dependencies

Audit Requirements

Purpose: Regular audits ensure the policy remains effective, identify areas for improvement, and provide evidence of compliance for internal and external stakeholders.

Semi-Annual Reviews:

  • Package security status review
  • Compliance metrics assessment
  • Consumer feedback analysis
  • Package portfolio optimization
  • Resource allocation assessment
  • Policy effectiveness evaluation

Annual Reviews:

  • Comprehensive security certification
  • Business value assessment
  • Strategic roadmap alignment

Roles and Responsibilities

Purpose: Clear role definition prevents confusion, ensures accountability, and establishes decision-making authority. Each role has specific responsibilities that collectively ensure package quality, security, and business alignment while maintaining operational efficiency across DHI's global organization.

Architecture Board

Composition: Lead Architects and CTO Representatives

Responsibilities:

  • Final approval for all public package publications
  • Package naming convention governance
  • Strategic direction for public package ecosystem
  • Escalation resolution for package disputes

Product Owners

Role: One designated owner per product area with backup

Responsibilities:

  • Product package publication coordination
  • Stakeholder training and support
  • Compliance monitoring and reporting
  • Interface with Architecture Board

Package Maintainers

Role: Designated by the product owner or the technical lead to deliver product

Responsibilities:

  • Day-to-day package maintenance and updates
  • Version management and release coordination
  • Consumer support and issue resolution
  • Documentation maintenance

Security Team

Role: Designated by CISO or Security Representative

Responsibilities:

  • Package vulnerability scanning and monitoring
  • Security requirement definition and enforcement
  • Incident response for security issues
  • Annual security review

Terms and Abbreviations

This section defines key terms and abbreviations used throughout this policy to ensure clarity for all stakeholders.

Abbreviations

  • API (Application Programming Interface): A set of protocols and tools that allow different software applications to communicate with each other
  • CI/CD (Continuous Integration/Continuous Deployment): Automated practices for building, testing, and deploying software.
  • CISO (Chief Information Security Officer): Person responsible for an organisation's information security auditing
  • CVE (Common Vulnerabilities and Exposures): Publicly disclosed cybersecurity vulnerabilities with unique identifiers
  • IP (Intellectual Property): Creations of the mind protected by law (patents, copyrights, trade secrets)
  • LTS (Long Term Support): Extended support period with security updates and critical bug fixes
  • MFA (Multi-Factor Authentication): Security process requiring two or more verification methods to access an account
  • SBOM (Software Bill of Materials): Formal record of all components and dependencies in a software package
  • SCA (Software Composition Analysis): Process of identifying open-source and third-party components and their associated security risks
  • SDK (Software Development Kit): Collection of tools, libraries, and documentation for developing software applications
  • SemVer (Semantic Versioning): Version numbering scheme (MAJOR.MINOR.PATCH) communicating backward compatibility
  • SLA (Service Level Agreement): Commitment defining expected service quality and response times

Key Terms

  • Author Signing: Digital signature applied by the package creator to verify authenticity
  • Code Coverage: Percentage of code executed during automated testing
  • Deprecation: Process of phasing out a package or feature with advance notice and migration guidance
  • NuGet.org: Public repository hosting NuGet packages, accessible globally
  • Package Maintainer: Individual responsible for day-to-day maintenance, updates, and support of a NuGet package
  • Pre-release Version: Package version marked for testing (e.g., 1.0.0-rc1, 1.0.0-beta.1) before production release
  • Product Owner: Designated leader responsible for product strategy and package publication coordination
  • Strong Name Signing: .NET assembly signing provides a unique identity and prevents tampering
  • Transitive Dependencies: Dependencies brought in indirectly through your direct dependencies
  • Vulnerability Scanning: Automated analysis identifying known security issues in package code and dependencies