-
Notifications
You must be signed in to change notification settings - Fork 583
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.NET Core support #148
Comments
Duplicate of #103. We already have a WinRT port which ended up reusing most of the code, so I'd be interested in seeing how difficult can it be to support CoreCLR. |
I should have some free time over the weekend, so i'll pull down the code and have a go at porting it for you. Will report back with my findings. |
@sblackler How is it going? I attempted the port too as a hobby: master...jeremymeng:CoreClr. Both client and unit test project build. I attempted to run the tests but it seems like I don't have the |
@jeremymeng thank you. If you can explain what kind of environment is necessary to give it a try (I have Windows 8.1), I can do it. |
@jeremymeng the changes look smaller than I thought, this is encouraging. Note that I'm afraid we can't license parts as MSPL and to integrate your changes eventually we'd have to ask to you sign our CA. |
VS 2015 Community Editor with update 1 should be good. For command-line only experience, you can install ASP.NET 5 RC as described at https://docs.asp.net/en/latest/getting-started/index.html. I now use the code from Stephen's blog so there should be no license involved. |
@ru-sh has created a fork that targets CoreCLR that I've been using (he also has an unofficial NuGet package). It has a bug where trying to connect via IPv6 throws an unexpected exception type, so then it doesn't try connecting via IPv4. Once I fixed that it would connect from my Windows client host to my Rabbit running on my Linux Vagrant guest. But going from a Linux Vagrant client to Rabbit running on another Vagrant client hangs. Haven't gotten farther than that yet. Here's a link to his fork: ru-sh@ffedb32 |
Hey Guys, any updates on this port? Keen to see support for .net core arrive so happy to help in any way I can. |
No updates besides that we've decided it should be a completely new client.
|
We've outlined our plan for the future of this client on rabbitmq-users. |
I see this as a pretty big blocker for building real enterprise applications with CoreCLR. Building a brand new client sounds pretty ominous with long timelines. Should this maybe get forked to give the community a temporary solution sooner? |
@jacksontbryan we can't prevent people from forking but it'd be a huge waste of time. We have a branch that works on CoreCLR but we cannot really test it beyond small F# scripts because the NUnit version we use doesn't run on CoreCLR. We'll try NUnit 3 or a different library but there is no guarantee that those work. Moving to a different testing framework is not a small task either. I don't know what "real enterprise applications" means but the overall ecosystem migration to CoreCLR is far from being on the finish line, so "pretty big blocker" is a bit of an overstatement if you ask me. And our little client barely has any dependencies to worry about. Anyhow, I'm going to lock this as we do not use GitHub issues for lengthy discussions. If we can find a testing framework that works on CoreCLR today, there will be a branch of this client available as an interim step to the new client. |
I've been working on this and have just about got it to pass the test suite. It needs a bit of tidying up and documentation needs to be updated but I should be ready to push a branch with dotnetcore support in the next couple of days or so. @doc @jacksontbryan are you up for doing a bit of testing when that happens? |
ok I've now pushed a branch named Please note this branch is largely unproven/untested and here for previewing purposes only at this stage. |
@kjnilsson we should produce a binary build (and upload it to GitHub as a release plus post to the mailing list with an announcement) |
This client in master is now compatible with .NET Core (we have a .NET Core-based toolchain and all tests pass). We are planning to have a NuGet feed with master releases ready for public consumption soon. All credit for this work goes to @kjnilsson. Note that this support is experimental at this point, both because .NET Core itself changes often and so does our understanding of how to best support .NET 4.5 and .NET Core (WinRT is not supported in master at the moment since we couldn't get the .NET Core build toolchain to work with WinRT). The plan is to stabilize .NET Core support and then keep this client in maintenance mode (with .NET 4.5 and .NET Core being two supported targets) until a new client that exclusively targets .NET Core can be developed from scratch. That's why I think it's fair to close this issue. Please file new ones if you have suggestions about specific and actionable changes in master. |
Thank you @kjnilsson and @michaelklishin for prioritizing this! |
Another update: as of #213 we target the most recent version of .NET Core available a.t.m. |
Prereleases can be obtained from our AppVeyor NuGet feed: https://ci.appveyor.com/nuget/rabbitmq-dotnet-client-ci |
FTR, theere is no need to use the AppVeyor NuGet feed above. 4.0 and later releases of this client are distributed using the regular NuGet feed used by this library. |
Hey,
Do you have any plans to port to CoreClr? Happy to help out if there is buy-in etc.
UPD1: prerelease NuGet feed: https://ci.appveyor.com/nuget/rabbitmq-dotnet-client-ci
UPD2: RabbitMQ.Client releases on NuGet are now .NET Core compatible.
The text was updated successfully, but these errors were encountered: