PPWCode.Vernacular.Exceptions.V 1.2.1

Changes

• Remove Microsoft.SourceLink.GitHub from global package references

View full changelog →

PPWCode.Vernacular.Exceptions.V 1.2.0

Changes

• Switched the solution file from .sln to .slnx format
• Updated the .NET SDK version to 10.0.302
• Added gen5 to the NuGet package tags
• Generated portable debug symbols for both Debug and Release configurations
• Changed test and analyzer package versions to floating versions
• Updated test project dependencies to the latest available versions

View full changelog →

PPWCode.Vernacular.Exceptions.IV 2.4.1

Changes

• Remove dependency on Microsoft.SourceLink.Github: no longer needed

View full changelog →

PPWCode.Vernacular.Exceptions.IV 2.4.0

Changes

• Upgrade dotnet SDK to 10.0.302
• Add tag gen4 as PPWCode generation indicator
• Migrate to slnx solution format
• Upgrade package dependencies

View full changelog →

PPWCode.Vernacular.Exceptions.IV 2.3.0

Changes

• use portable pdbs
  • better debugging experience
• Upgrade dotnet SDK to 10.0.301
• Upgrade dependencies

View full changelog →

PPWCode.Vernacular.Exceptions.V 1.1.0

Changes

• Added ValidationViolationException by @rvdginste in #7

View full changelog →

PPWCode.Vernacular.Exceptions.V 1.0.0

Changes

• Initial release of mark V
• Supported targets: .NET 8.0, .NET 9.0, .NET 10.0
• Code built using nullable reference types
• Use of Microsoft attributes for nullable static analysis

View full changelog →

PPWCode.Vernacular.Exceptions.IV 2.2.1

Fixes

• Reproducible builds
  • Strict locking when restoring dependencies (dotnet restore --locked-mode)

View full changelog →

PPWCode.Vernacular.Exceptions.IV 2.2.0

Features

• Reproducible builds
  • Locking the compiler version to ensure reproducible builds
    • Compiler version is now tracked through global.json

View full changelog →

PPWCode.Vernacular.Exceptions.IV 2.1.0

Features

• Add refinements of ProgrammingError for use in backends that offer an external api
  • InternalProgrammingError, used for a programming error in the backend internally; in the context of an HTTP api this would result in response status code 500
  • ApiUsageError, used for a programming error related to the usage of the external api; the api is called but the preconditions of the api call are not fullfilled; in the context of an HTTP api this would result in response status code 400

View full changelog →