search

rebus-org / Rebus

:bus: Simple and lean service bus implementation for .NET
https://mookid.dk/category/rebus
Other
2.32k stars 364 forks source link

Port to .NET core #358

Closed mookid8000 closed 7 years ago

seankearon commented 7 years ago

I agree with @atrauzzi. I think there is greater value in getting a .Net Core story for Rebus out sooner than later. The dependency can be looked at later.

mookid8000 commented 7 years ago

Thanks to @mvandevy 's persistence and hard work, I have now adapted build scripts and stuff and figured out how to release this betaversion of Rebus that targets .NET 4.5 and .NET Core (in the form of netstandard1.6).

Check this out:

image

I have done the same things to Rebus.Serilog, Rebus.SqlServer, Rebus.RabbitMq, and Rebus.Autofac, so it should actually be possible now to get an endpoint up and running with all areas covered.

Thanks @mvandevy for kicking me until I could no longer ignore you 🤜 😁

mvandevy commented 7 years ago

Great news! Thanks for the effort of getting it published!

mookid8000 commented 7 years ago

I'll keep track of the status here:

🏖 : means that the package has no dependencies 🏅 : means that the dependencies support .NET Core 😞 : means that the dependencies do NOT not support .NET Core 😐 : means that it probably doesn't make sense to port the package to .NET Core ––––– means that the project is to be considered deprecated

mookid8000 commented 7 years ago

If anyone plays around with the new 4.0.0-b?? versions, it would be awesome if you would post your experiences here.... I am interested in hearing about full .NET framework experiences just as well as .NET Core experiences.

danielmarbach commented 7 years ago

The ASB Team is working on a .NET core compliant SDK. https://github.com/Azure/azure-service-bus-dotnet it is just a question of how long it takes ;)

mookid8000 commented 7 years ago

Here's the steps I go through when porting a project:

0. Don't open the solution file

Using Visual Studio 2017, control yourself and refrain from opening up the .sln. We will manually edit some files first, using a real text editor like e.g. Sublime.

1. Edit appveyor.yml

Take appveyor.yml from a project that has already been ported (e.g. Rebus.DryIoc) and adapt it to build the package's main and test projects.

Look out for required services: and be sure they are brought over too.

2. Edit <main-project>.csproj

Open it up in a text editor and copy over the csproj contents from a project that has already been ported. Fix the 3-4 places where the project name occurs. Remove any unneeded NuGet PackageReference elements carried over.

3. Edit <test-project>.csproj

Same procedure as when porting the main project, only using e.g. Rebus.DryIoc's test project as source.

4. Copy over the updated scripts

Copy over the four files in the /scripts folder from e.g. Rebus.DryIoc. Just overwrite the existing scripts.

The scripts are there to be invoked by Bob.

5. Finally: Open the solution in VS2017

Iterate like this:

VS2017, or Resharper 2017.1 EAP 5, or both in combination, are buggy as hell, and you may need to close the solution and open it again for some changes to take effect. Especially when adding new NuGet imports or new source files, weird stuff can happen, and the solution is almost always to simply reopen the solution.

6. Send PR 💌

mvandevy commented 7 years ago

BTW, would anyone be interested in a Rebus.MySql project which is also .net standard compatible? Just happened to have this lying around. 😁

mookid8000 commented 7 years ago

I don't have that need myself, but I think it would be a pretty cool addition!

mvandevy commented 7 years ago

OK, let me clean it up a little so I can point you to it. Or would you want to create a repo for this, with the basic stuff in it, so I can create a pull request?

mookid8000 commented 7 years ago

I'll create the repo – this way, you can send a PR and have your name all over it 😄

mookid8000 commented 7 years ago

@mvandevy I've pushed my boilerplate here

mookid8000 commented 7 years ago

ALL projects have now been ported to the new project structure, and those whose dependencies do not prevent it are targeting .NET Standard 1.6 in addition to the usual .NET 4.5 (or in some cases 4.5.1 / 4.5.2)

The core Rebus package is out in version 4.0.0-b10, and all the most recent versions of the other packages depend on this particular version.

All packages are out in prerelease versions. It would be awesome if someone would check it out, no matter if they're on .NET Core or on the full .NET framework.

🤗

BredStik commented 7 years ago

Great work to all of those involved!

debabrata-das commented 7 years ago

Azure Service Bus is now available for .Net Core. Do you know when Rebus.AzureServiceBus will support it also??

mookid8000 commented 7 years ago

🤘

soon! (as in: one of the following days)

danielmarbach commented 7 years ago

Be aware that it lacks a few things like SendsWithAtomicReceive and has a breaking change in how it treats stream messages that might not be backwards compat depending on how the previous client was used

Am 15.08.2017 um 08:24 schrieb Mogens Heller Grabe notifications@github.com:

🤘

soon! (as in: one of the following days)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

mookid8000 commented 7 years ago

Ah, thanks for warning me – it'll be interesting to see how much of the API surface I am currently using can be translated directly to the new driver.

theoriginalkien commented 7 years ago

hi @mookid8000, any expected date on a release of Rebus.AzureServiceBus that support .net core?

mookid8000 commented 7 years ago

Unfortunately, it turned out that the new driver implementation had been changed radically, compared to the old driver, especially with regards to receiving messages.

I think I will get some time next week where I can see if I can make something work.

hulvei3 commented 7 years ago

@mookid8000 thank you for this awesome work on getting Rebus onto supporting .NET Core. It's a bummer with Rebus.AzureServiceBus though, but we can already use it as is right now, at least on windows. It would be great in time to be able to this lib to the full extend of .Net Core.

bhaidar commented 6 years ago

Any updates on the status of Rebus? Can we use it in ASP.NET Core 2.1? Thanks

mookid8000 commented 6 years ago

Yes, Rebus has supported .NET Core since March 2017 😄

Rebus 4 is built targeting .NET 4.5 and .NET Standard 1.3, and Rebus 5 will add .NET Standard 2 as a target too.

bhaidar commented 6 years ago

@mookid8000 Thanks a lot.

Im new to this and I am bit confused about Rebus.

Is it just a bus? I see, there is Rebus.AzureServiceBus, Rebus.RabbitMq, Rebus.AzureStorage, Rebus.PostgreSql, and other packages? What's the deal here, what is exactly Rebus and why having all those packages?

I am switching to CQRS now.

Thanks

mookid8000 commented 6 years ago

Is it just a bus? (...) What's the deal here, what is exactly Rebus and why having all those packages?

Rebus provides implementations of common messaging patterns like request/reply, publish/subscriber, correlation ID, process manager, dead-letter queues, claim check, etc.

It does so in a way that makes your code portable across transports, so you can e.g. start out by configuring it to work with RabbitMQ. Later, if you need to move your system to the cloud, you can configure it to use Azure Service Bus. Or Amazon SQS.

In addition to this, it makes coding event-driven applications pleasant, because its APIs are quire simple and approachable 😄

If you are curious to read about Rebus, I suggest you go look at the wiki – it has explanations for most concepts.

If you want to see code that uses Rebus, you can check out the RebusSamples repository

bhaidar commented 6 years ago

That's an amazing explanation @mookid8000 Indeed, looks very promising!

I am reading and learning CQRS, DDD and such patterns nowadays and want to apply those concepts to a real-life app.

There are many micro frameworks out there on Github that can handle messaging, etc. That's why the options are many :-)

When you say request/reply, does that correspond to commands? Typically, when you execute a command, you need an answer to the client (accepted or not at least).

As for publishing/subscriber, it reminds me more of handling Domain Events and Event Sourcing? Or am I talking about something else?

What about the event store? Does Rebus support that? Because with event sourcing you need the event store to persist the events, etc.

Process Manager, are we talking about a "Saga"?

I will for sure check out the wiki and the samples!

Thanks

mookid8000 commented 6 years ago

When you say request/reply, does that correspond to commands? Typically, when you execute a command, you need an answer to the client (accepted or not at least).

Yes, it's typically a command where the sender is somehow interested in the result. In code it could look like this (at the client's end and the "Inventory Service"'s end, respectively):

// at the client end:
await bus.Send(new MakeInventoryAllocation(...));

// and then in the "Inventory Service":
await bus.Reply(new MakeInventoryAllocationReply(
    success: couldMakeInventoryAllocation,
    correlationId: correlationIdFromCommand
));

As for publishing/subscriber, it reminds me more of handling Domain Events and Event Sourcing? Or am I talking about something else?

If you work with event sourcing, you typically need stronger ordering guarantees than what a library like Rebus can provide (because it runs on message queues and often will process messages in parallel, either by multiple threads or even in multiple processes).

What about the event store? Does Rebus support that? Because with event sourcing you need the event store to persist the events, etc.

No 😄 Rebus runs on message queues. You could of course model a message queue on top of an event store, but if you want to use a real event store, it's probably more fun to code your app such that it takes advantage of all of the extra guarantees that it provides.

Process Manager, are we talking about a "Saga"?

Yes 😄 it's called "Saga" because Rebus started out as a copy of the functionality I liked from NServiceBus, so that word stuck. It's called a "Process Manager" in the literature though, so I usually use that word. Also, "Sagas" usually imply you use some kind of compensating actions for steps that fail or otherwise cannot be completed, but that's in no way required with Rebus.