Giters

MassTransit / MassTransit

Distributed Application Framework for .NET

Home Page:https://masstransit.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

.NET Core 2.0 Release Master Issue

dls314 opened this issue · comments

commented

Get MassTransit running on .net core.

Some related dependencies (there are a lot more that deserve tracking down):

commented

First, the .NET Core 2.0 roadmap is expecting to see a Q3 2017 release, which is the time at which we hope to have a release of MassTransit nearly complete for use with this new standard framework. See the .NET Core roadmap for details.

Transports

Containers

Loggers

Saga persistence

commented

@TravisTheTechie that's super markdown fu

I think that Autofac and Serilog get "does support .net core" checks--if that's what you meant there.

commented

We don't have to support everything on .NET Core, but I think it will be a challenge to communicate it if we don't support most things.

commented

Sounds like we'll need to use some of your -Fu to get the readme.md updated with a grid as support for that various runtime versions is added.

Nice work on the issue documentation!

commented

Seems like castleproject is going on with .net core https://github.com/castleproject/Core/tree/netcore

commented

It looks like some work is moving forward in RabbitMQ.
rabbitmq/rabbitmq-dotnet-client#148 (comment)

commented

RabbitMQ has a new issue for .NET Core: rabbitmq/rabbitmq-dotnet-client#213

commented

I'm moving ahead with some of the work on this. Currently porting the core MassTransit project to Core. Issues so far:

  • No System.Transactions in .NET Core 1.0 (support has been added)
  • No BinaryFormatter in .NET Core 1.0 (support has been added)
  • No Performance Counters in .NET Core 1.0 (support is being considered)
  • No System.Runtime.Caching in .NET Core 1.0. Looking at using Microsoft.Extensions.Caching.InMemory as a replacement.

I think support for the MT features that depend on these APIs could be selectively dropped until they become available.

  • No System.Net.Mime namespace in .NET Core 1.0. This is a big one since the ContentType class is used all over the place. Not sure what to do about this...
commented

Performance counters could be extracted in an assembly supporting the required the runtime. I don't remember what we use System.Transactions for, likely Saga related. Might be able to extract this as well.

We could replace ContentType class with a custom implementation. I don't think we need it for much, just used it because it is there. However, I'd have to dig in to make sure there's not a case I'm forgetting. So 👍, I'm excited to see someone make some progress and we can try and help out if you have questions.

commented

So far, I have
MassTransit
MassTransit.TestFramework
MassTransit.Tests
MassTransit.RabbitMqTransport
ported and compiling for net452 and netstandard1.5.
The main thing I'll need help with is getting the build process working. I have nunit updated and running on the .NET Core command line runner, but I don't really have any experience with FAKE, so I have no idea how it plays with Core and the new tooling.

commented

@jarroda can you push this to your local branch? When checking out everything seems to be broken

commented

After some research Azure ServiceBus will provide a new opensource implementation somewhere soon see: https://twitter.com/jtaubensee/status/759031851537227780

commented

So far I just have the main MT project and the RabbitMq transport working. I have been testing it out with our app for a week or so and it seems to be functioning well. I hope to have time over the next week or so to finish porting the other MT projects (that can be ported at this time) and then we'll need to get the build process working.

commented

If you commit a working phase for MT then ill investigate for azure service bus

commented

I have committed the nuget config I am using, which should be all you need to get the MassTransit project to build. It depends on the port of NewId by @lahma that I packaged and pushed to myget, until those changes get merged into the main repository.

commented

I could probably give a hand with the Quartz integration project at least next week.

commented

Progress is great, I'll be ready to pull in these changes once they're ready.

The NewId project needs to be updated to Fake, if possible. Otherwise I can install all the old Ruby bits on my machine to get it building (new VM, doesn't have ruby).

Excited to see all the efforts coming together!

commented

@jarroda can you also save the solution file? If i open it then the .net core projects aren't loading -> open .sln file try to build.

edit: if anyone else is trying besure you have the latest version of dotnet cli it doesn't compile with RC2 but with preview 3 it does

commented

Sorry, I had been doing all my work in VSCode and the cli, and had not generated xproj files or a working solution. I have committed xproj files for the projects I have working, and I created a new solution that we can use to add the ported projects to as we get each one working. Use the MassTransit.Netcore.sln and add you're projects there.

We will have to flatten the folder structure, since it appears the dotnet tooling does not support projects nested into subfolders (project references do not work), but I am keeping the existing VS solution folder layout, so the impact on organization will be minimal.

commented

Yeah thanks its building now 👍

commented

Small update we have:

MassTransit
MassTransit.TestFramework
MassTransit.Tests
MassTransit.RabbitMqTransport
MassTransit.StructureMapIntegration
MassTransit.CoreLoggingIntegration
MassTransit.NLogIntegration
MassTransit.SerilogIntegration

I am working on MassTransit.AzureServiceBusTransport its being bit of a pain as the package we where using (WindowsAzure.ServiceBus) is deprecated and won't get .NET core support

commented

Busy activity, looking forward to having this ready to pull - great work so far!

commented

Small update on my side got Masstransit + Azure ServiceBus to run on dotnet core still needs a lot of polish.

https://twitter.com/daanleduc/status/762246995780202496

commented

Nice way to keep track of whats .net core compatible https://icanhasdot.net/result?github=MassTransit~2FMassTransit
image
image

commented

FYI: Quartz alpha on .NET Core now http://www.quartz-scheduler.net/2016/08/16/quartznet-3.0-alpha1-released.html , Common.Logging no longer required.

commented

Any update on the work to get MassTransit working on .NET core? I realize that NewId needs updated, and Automatonymous as well.

I need to get NewId updated to use FAKE, it's still on Rake :(

commented

Tried to test the azure servicebus as much as possible. I am on holiday now will resume in two weeks by doing pull request to the temporary repository we are using now.

commented

My family and I moved and so I have been slammed in the evenings after work with getting our new house together. I hope to soon be able to pick back up and continue converting projects in the MT repo, but I'll definitely stay on top of any work others are doing and pull any PRs into my WIP repo.

commented

@jarroda I'll try to whip up a pull request for updated Quartz bits

EDIT: Quartz 3 alpha 2 integraed and pull request done: jarroda#5

commented

So I have worked today on getting my netcore repo rebased back onto the current MassTransit develop branch, so I don't get too far behind the work being done there. Looks like alot of changes have happened and it was some work getting conflicts resolved, but I think I'm up to date.

One issue I've hit immediately is the stuff added in the Util.Scanning namespace. Some of the stuff like StackTrace and AppDomains won't be around for a while. What is this feature and can I exclude it from the core build or does it make sense to split out into its own project/package?

commented

It's used by the MassTransit host, for finding endpoints and services, but I think we can work to exclude certain parts and put the .NET core alternatives to locating the current directory in place. If there are unused methods in the scanning, we can likely just eliminate them for the time being until they're needed.

commented

Ok cool. I'll dig in and see if I can just #if out the non-supported bits.

commented

What is the status on this? It looks like most of the issues marked as outstanding in @TravisTheTechie 's post above are already solved.

commented

Keen to see an alternate sln file merged for this as well, along with supporting changes. Any activity here?

commented

Yeah we need to get this rocking. I'm ready to engage and help make it Happen.

commented

So for the initial release that supports .NET Core, we can drop NHibernate, Unity, and the other things that don't support Core yet. And create new packages for EF-Core.

commented

One thing I think needs to be done is to restore the old directory layout, I believe the made changes are not actually required if we tweak a proper global.json file that lists full paths for the projects that don't follow src/ProjectName pattern.

Then the changes would be easier to diff and branch would be easier to keep in sync with main MT source.

Should the work be done in official netcore MT branch instead of using contributing repos?

commented

I tried maintaining the current directory layout but could not find any valid way of using global.json to support nested directories for many of the dotnet commands. I agree maintaining the legacy layout will make diffing the changes easier, but it would seem to me there is an argument for bringing MT's layout into the 'standard' dotnet project layout. Nesting and better organization can still be supported in the .sln regardless.

All that said, all the tooling is radically changing. Project json is of course going away, not sure about global.json, but I assume it is as well. I'm certain the nesting won't be an issue once .net core is utilizing csproj.

commented

Tooling churn, for the loss. I'm fine flattening the directory structure, it's not a big deal to me. I can do it easily on the main develop repository.

commented

any news on when this might be completed?

commented

When it's ready. Even .NET core isn't ready yet.

commented

.NET Core isn't ready? It's RTM. v1.1 is in preview. Are you waiting for specific features?

commented

I think the issue would be that while the runtime is RTM, the tooling isn't mature yet and there's still the migration to csproj that's outstanding.

commented

IMHO .NET Core 1.0 made a mockery of the term "RTM" (and to a worse extent, "RC") .NET Core 1.x is far from ready and the releases are premature.

A base level of tooling for any runtime is essential and therefore part of the product. Arguments to the contrary remind me of:

image

By all definitions known to me, the product is still in the alpha phase.

That said, .NET Core 2.0 is shaping up very nicely. I suspect it's going to be the first version that will truly progress past alpha through to RTM and be suitable for general use, and I'm looking forward to it.

(These feel like echoes of the original .NET Framework 1.0 and 2.0 releases, but on a grander scale.)

commented

Ugh. Yes, .net Core was a big shock for dark matter developers and not all of them are handling it very well.

Welcome to the world of FOSS. Lots of things at 0.*.* get used. That isn't a reflection on the people. There are countless technologies with vastly inferior tooling experiences that enjoy much broader adoption. It was a matter of shape up or ship out for Microsoft as the Rubys, PHPs, nodes, Pythons and Scalas ran off with the market.

Even during the last ASP.net community standup, Damian remarked how easy it was to go from 1.0 to 1.1. Having the opinion that "things aren't stable enough" gives way to eventually never seeing when things are "stable enough".

Just embrace change, things get easier -- and better.

commented

The OSS development model and the following of recognised development and release phases are demonstrably not mutually exclusive. I'll stop here because I don't want to hijack this thread any longer. Happy to discuss elsewhere.

commented

I got Azure Service Bus kinda working not sure if @jarroda continued. Yesterday tried RabbitMQ implementation and it was not completely working for me.

commented

Do we have a branch to check out and pitch in if we're feeling brave?

commented

We are currently working on the upstream dependency of this, GreenPipes, which is basically finished other than getting the build running. That work is happening here https://github.com/phatboyg/GreenPipes/tree/develop-netcore

Once this is is finished (along with NewId), we can focus on getting the rest of MT ported.

commented

Any chance of supporting .NET Core 1 now that the tooling is a lot better in VS2017.

commented

If we wanted to help out with this issue, what would be the best way?

commented

@sirlukecoop There is some work going on to finish off some of the other dependent libraries MassTransit/GreenPipes#3 and phatboyg/NewId#8 personally not sure what is next after they are updated. #874 will hopefully speed up things a little.

commented

@jarroda Did you have to make many changes to support core? I have a PR with the csproj changes for VS2017 RTM.

commented

@andymac4182 Yeah there were quite a few, though not major changes. Mostly stuff like working around the lack of [Serializable] attribute, BinaryFormatter classes and a few other small pieces that were missing. Easy to work around, but a little tedious fix. We have been running our application on my forked version of MassTransit, on core for about a year now with great results. However our version is out of date now so I'm very excited to see the renewed interest in getting it officially ported.

I was just never able to overcome the tooling problems to the point of getting my PRs accepted.

commented

I just finished moving to the VS2017 tooling so should be easy to add the changes you were doing on top. Any chance you could rebase your branch? I can take a look tomorrow at cherry picking those changes over or rebasing on top of my changes as I made zero changes to the actual code just the csproj files.

commented

Rebasing will definitely be a challenge. I think somewhere along the way the history changed on the branch I did my work in, and I had tried to rebase once before and had difficulty. Also, my branch was before the GreenPipes project, which caused a big chunk of code to move from MT.

Some of the supporting projects I ported or created (like the IoC providers, logging providers etc) should be able to be pulled over easily, but it might be just as easy to manually port the two core projects again.

I should be able to lend a hand in doing that.

commented

This week is a good week for me to engage on this, I'll have 2017 installed tonight.

Looking at the "ICanHas.NET Core" site there are a couple of projects that won't build for .NET core (not a big deal, but NHibernate, Unity are big ones).

It will work for RabbitMQ, seems like ServiceBus (Azure) isn't ready yet. But that's fine, we can build the projects that work with that solution type or something.

commented

@jarroda I have started to manually pull over the changes for the MassTransit project only at this point. https://github.com/andymac4182/MassTransit/tree/initial_netstandard

commented

Do you have any news about porting progress? How can we help you?

commented

@syberside Process is well underway. Check out #909
There are enough projects ported at this point to make MassTransit usable on netstandard for most people I'd imagine.

commented

@jarroda that's awesome! Thank you!
As I can see MassTransit.QuartzIntegration is not supported yet.
Does this mean that there will be no Shedule support for sagas until quartz 3.0 will be released?
Do you plan to support any other sheduler? May be it's time to make scheduler replaceble?
There are many schedulers awailable for .NET Core. For our projects we use Hangfire (it's primary task is not sheduling but this feature also awailable)

commented

I would suggest posting another issue around support for other schedulers if that is something you need since this task is just around getting the existing compatible packages up to date to support core.

commented

All further discussion should refer to: #909