Skip to content

Version 5.0.0 #29

@mikebeaton

Description

@mikebeaton

UPDATE: This release will now be v5, to match the fact that it will include explicit .NET 5 support. (Implicit .NET 5 support is already available, and valid - for now - via Mighty's existing .NET Core 3.1 support.)

The other main enhancements in this version will be:

Other more minor enhancements include:

  • Add CurrentPage and PageSize to PagedResults c.f. Paging enhancements #10
  • Correct behaviour on only passing ProviderName in the connection string (namely, the provider is set correctly, but Mighty does not incorrectly think that it has a usable connection string)
  • Add SqlServerAutoEnlistCommandsToTransactions flag with default true, and supporting code, so that if you pass a connection with an open transaction to a Mighty operation, Mighty can just use it SQL Server transaction support #28

The reason this release is a breaking change (semver v3 -> v4) is that I am in the process of writing some code to do an automated audit of all the variant and similarly named methods (e.g. sync vs ...Async, no params vs. ...WithParams, etc., etc.) and I have inevitably found a few minor inconsistencies and missing methods. In order to avoid hard-coding the inconsistencies into tests and baking them into Mighty forever, it seemed preferable to make the changes necessary and release a new major version. This is unlikely to affect you unless you are already using cancellation tokens with async methods, or unless you were using the (incomplete in the previous version) Mighty support for passing in DbConnection, in which case you may have to move some parameters around in your method calls.

The version is stable, I am using it in my own production code; the only reason I've put is as alpha and not beta is that I may still have to make a few more - hopefully small - method signature changes once I've done the last couple of pieces of the automated audit code. I'm hoping to have that done very shortly (i.e. days not weeks).

Finally, up to now I've only successfully been making subsequent versions of Mighty compile compatible, but not necessarily binary compatible. That won't be an issue unless a NuGet package which you're using, is itself using Mighty. Then, it definitely can be an issue, so it's obviously something I can and should (and will!) double-check for, ongoing. (The issue arises around adding, e.g., new optional parameters. Recompiled code will work just fine, but a package compiled against an earlier version won't find the new method and will break.)

To Do

  • Add last automated method signature tests
  • Finish creating a test harness to test binary compatibility ongoing
    • Includes removing all Console output from old Massive tests
  • Use Devart license (see below)
  • Fix new IAsyncEnumerable problem in .NET Core 2.0 tests (only)
  • Take latest minor master branch updates into v4
  • Add providerName parameter
    • Update built-in providers to use it: if it is present, don't even try to parse the connection string
  • Explicit .NET 5 support (should already be implicit support, valid for now, via .NET 3.1 support)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions