Repository navigation
Releases: DylanSnel/DDDToolkit
Release list
3.2.0-preview.5
3.2.0-preview.3
3.2.0-preview.2
3.2.0-preview.1
Prerelease of Tenancy and Membership, from the draft pull request. Packages: Temp.DDDToolkit.*, including the six new Supporting packages.
3.1.0
The module names its generated code. [assembly: Module] now wins for every generated name, and DDD_Module is the default beneath it. This renames generated methods in some projects that declare a module; The names of generated registrations has the cases and what to do in each. The changelog has the full entry.
Changed
Add{Module}Converters, Add{Module}IntegrationEvents and Add{Module}GraphQlRuntimeBindings take their name from the first of three places that has one, the order {Module}EventNames already had:
| Where | Who it is for |
|---|---|
[assembly: Module("Ordering")] |
A module. It always wins. |
<DDD_Module>Shop</DDD_Module> |
A project that is no module. A Directory.Build.props can set it for a whole folder. |
| The assembly name, dots removed | A project with neither. |
A project without the attribute is not affected. A project with it is renamed when it set no DDD_Module, or another name:
| The project has | 3.0.1 | 3.1.0 |
|---|---|---|
The attribute and the same DDD_Module |
AddOrderingConverters |
AddOrderingConverters |
The attribute and no DDD_Module |
named after the assembly | AddOrderingConverters |
The attribute and another DDD_Module, such as OrderingContracts |
AddOrderingContractsConverters |
AddOrderingConverters |
Two assemblies, one module
A module and its contracts project give their registrations the same name. Add{Module}Converters and Add{Module}GraphQlRuntimeBindings call the ones of the module's other assemblies they reference, so a context or a schema makes one call for the module. Another module that references only the contracts calls the contracts' method, under that same name. See Two assemblies, one module.
Package ids
3.x is still published as Temp.DDDToolkit.*:
dotnet add package Temp.DDDToolkit --version 3.1.03.0.1
DDD_Module now reaches the generators wherever they run. Nothing changes for a project that references Temp.DDDToolkit. A project that references only Temp.DDDToolkit.Abstractions and Temp.DDDToolkit.Analyzers gets the names it asked for after the update. The changelog has the full entry.
Fixed
DDD_Module was ignored in a project that had the generators without the DDDToolkit package. The property was declared to the compiler by a props file in DDDToolkit, while the generators that read it ship in DDDToolkit.Analyzers. Two setups were affected, and in both {Module}EventNames was named after the assembly without a word:
- A contracts project that references
DDDToolkit.AbstractionsandDDDToolkit.Analyzers. - A project that gets the toolkit through a project reference.
DDDToolkit.Analyzers now carries the props file itself, in build/ and in buildTransitive/. See DDD_Module, and the package that brings it.
Added
- DDD00014, a warning for a project the generators run in while the props file was not imported, for example because the reference excludes the package's build assets.
DDD_Moduleis ignored there, and the build now says so. - Referencing
DDDToolkit.AbstractionsandDDDToolkit.AnalyzerswithoutDDDToolkitis a supported setup, built against the packed packages on every pull request.
Package ids
3.x is still published as Temp.DDDToolkit.*:
dotnet add package Temp.DDDToolkit --version 3.0.13.0.0
A breaking release. Upgrading from 2.0.22 needs code changes and a retarget to .NET 10. Migrating to 3.0 walks through each break, and the changelog has the full list.
New package ids, for now
3.x is published as Temp.DDDToolkit.*. The nuget.org account that owns the DDDToolkit.* ids cannot publish at the moment, so DDDToolkit on nuget.org is still 2.0.22.
dotnet add package Temp.DDDToolkitOnly the package id changed. The assemblies and namespaces are still DDDToolkit.*, so swap each PackageReference and nothing else: DDDToolkit.EntityFramework becomes Temp.DDDToolkit.EntityFramework, and so on.
v2.0.22
v2.0.21
What's Changed
- refactor: Refactor PublishDomainEventsInterceptor to use response variable by @DylanSnel in #22
Full Changelog: v.2.0.20...v2.0.21