AceMQ hosting for .NET

Dependency injection and hosted-service integration for AceMQ for .NET: one AddAceMq call, handlers resolved from the container, consumers that start after the host is built and drain when it stops, and a health check that knows the difference between a broker that is down and a broker that is busy.

builder.Services
    .AddAceMq(builder.Configuration.GetSection("acemq"))
    .AddConsumer<Order, OrderHandler>("orders.new");

{
  "acemq": {
    "url": "amqp://localhost:5672",
    "topology": {
      "exchanges": [{ "name": "orders", "type": "topic" }],
      "queues": [{ "name": "orders.new", "deadLetter": true }],
      "bindings": [
        { "queue": "orders.new", "exchange": "orders", "routingKey": "order.created" }
      ]
    }
  }
}

That is the whole surface for the common case.

The pages

If you are looking for a pattern the library has and cannot find a setting for it, patterns from a host is the page: it says where each one lives, which of them are configuration and which are a service you register, and why.

What this is, and what it is not

It is the .NET analogue of the Spring Boot starter: the same job, done the way the target framework does things. Where the starter scans for an annotation, this resolves an interface from the container, because that is what a .NET application already understands and because it means a handler is an ordinary service with ordinary constructor injection.

It is not a second messaging library. Everything it configures is AceMq.Amqp, and an application that outgrows what is configurable here drops to the library directly without leaving anything behind — the connection it hands you is the library's own AceMqConnection, with the library's whole surface on it.

It is on its own version line, starting at 0.1.0, because it tracks two release trains: AceMQ's and Microsoft.Extensions'. A change in either can force a release here, and a shared version number would only be able to say that one of them moved.