I'm looking at MassTransit.SerilogIntegration now. MassTransit.NLogIntegration could be ported if it targeted the beta version of NLog, but the current stable release is full framework only. Thoughts on that?
Personally only stable packages should be referenced since that would bring the end users version up to beta and might break their existing logging.
I thought Autofac had a netstandard build as well
@phatboyg it does target netstandard1.1 in 4.6.0 https://www.nuget.org/packages/Autofac/4.6.0
Finished MassTransit.SerilogIntegration and added MassTransit.ExtensionsLoggingIntegration #910
I could take a look at EF persistence.
I can port MassTransit.SimpleInjectorIntegration and MassTransit.Reactive projects.
I had previously implemented an integration for Microsoft.Extensions.DependencyInjection, so I'll create a pull request for that soon.
@stromblom I do wonder if there will need to be a new proj for EFCore for persistence so people using EF6 can keep using that.
@andymac4182 Yeah probably. But that's cool. Ill take a look.
@stromblom Hopefully its just a copy paste and change of reference.
@phatboyg Do you have a preference on which projects are a minimum set of projects required for a preview/release?
Updated to show some of the packages that can't be upgraded currently due to dependencies. If anyone is aware of any extra ones or if I made a mistake please let me know ๐
Before a real .NET Core release, I'd like MassTransit, RabbitMQ, Autofac, as that comprises a complete stack of usable components for RabbitMQ.
No worries. I believe all of those are now either submitted or merged.
The last major thing I am not sure about is how to get the test running against both netcore and full framework.
Does anyone have a good way of doing this?
It appears as the DocumentDb client has two nuget packages now https://www.nuget.org/packages/Microsoft.Azure.DocumentDB/ https://www.nuget.org/packages/Microsoft.Azure.DocumentDB.Core/
Should this be two integrations or move to using the core one always?
Can packages be conditional based upon target framework?
Yeh they can. @phatboyg We could compile against each package for the different targets.
Looks like WindsorIntegration is a no-go at the moment. https://github.com/castleproject/Windsor/issues/145
Also, I have UnityIntegration building by using PackageTargetFallback to the portable library they have.
That plus StructureMapIntegration, and Automatonymous.StructureMapIntegration in PR #918
I have MassTransit.ExtensionsDependencyInjectionIntegration finished, with unit tests. I'll create a PR for that tomorrow.
PR #920 created for this ^^. After this is merged, all logging and IoC should be ported that can be.
Is there anything else that people would like to see supported in the initial release? It is good to see such a good list of projects that support netstandard now.
@andymac4182 as I have mentioned here scheduling support will be great.
You can use the Quartz packages in full framework where Quartz is currently supported. Once Quartz is supported on core in non pre-release I am sure it will be updated.
For those who come across this the Nuget feed URI is https://ci.appveyor.com/nuget/masstransit
Is this in any form usable?
I use the bare minimum of MT, send, publish, consume. Nothing else, not even retries.
I'm willing to test. Just point me to the version to use.
I see you're targeting Net Standard 1.6 making it incompatible with 2.0.
@thedumbtechguy It has just been published as a prerelease package to nuget. As I understand it netstandard1.6 is compatible with netstandard2.0. https://www.nuget.org/packages/MassTransit/4.0.0.1216-develop
So I had a different problem. I couldn't install MassTransit.RabbitMQ directly without first installing MassTransit.
I assumed it was a compatibility issue.
Off to test now.
I note that the AzureServiceBusTransport is crossed out because it's not currently supported. It looks like there is a library being developed that allows ASB connections that is dotnet core compatible at https://github.com/Azure/azure-service-bus-dotnet.
Are there any plans to add ASB support to the dotnet core Mass Transit libraries any time soon?
Thanks
Hi @robdmoore think the intention is to support everything MassTransit had before, but only looking at dependencies that are released at the moment, no alpha / beta or preview like quartz its still in alpha.
Yeah, the dependency versions are wrong for the .NET core builds - I'll have to fix as I had the same issue.
@gertjvr @robdmoore I've started a port of the AzureServiceBusTransport using the Microsoft.Azure.ServiceBus 1.0.0-RC1 package. https://github.com/MassTransit/MassTransit/pull/961
Redis is done. But, netstandard20 is there, may be it makes sense to change all targets to it?
Ideally netstandard1.6 support should be kept if possible as for a decent number of people moving to netstandard2.0 is still months away. We are starting to test out the preview with some applications running on netcore1. It also enables a larger number of frameworks that can use the library.
Adding netstandard2.0 as an additional target framework would be good I think since it will help find issues early.
I will try looking if netstandard20 target can help with performance counters and the host.
I vote for moving to .net standard 2.0. and removing 1.6, before .net standard 1.6 compatible version of masstransit is released as stable.
Nservicebus for example does that. It targets net452 and net standard2.0.
NetStandard 2.0 is definitely a better choice due to how much more compatibility it brings to net core 2.0.
It should make it easier to get a fully working net core MT out quicker and easier.
@thedumbtechguy There is already a version working for most packages already. I believe some more testing and updating of tests is what is required for the core release at the moment. Not much isn't supported under 1.6.
@andymac4182 can you update the head post to reflect current migration status?
These projects have been migrated:
Updated @jacobpovar ๐ sorry for missing them.
@andymac4182 my issue is that I get loads of errors in VS17 when I open MT develop on a machine with .NET Core 2.0 installed. I also have 1.0.4 SDK but it does not help. I thought this mess somehow gets resolved but no, it is still a mess with all these Microsoft contraptions to make our lives more complex.
@andymac4182 there is already a package for ASB.
Supporting .NET Standard 1.3: https://www.nuget.org/packages/Microsoft.Azure.ServiceBus/1.0.0
Supporting .NET Standard 2.0: https://www.nuget.org/packages/Microsoft.Azure.ServiceBus/2.0.0
Are you planning to include ASB again?
The library is significantly different and the management library is still missing important properties for queues and topics.
Quartz.NET beta 1 has .NET Standard 2 support https://www.quartz-scheduler.net/2017/10/08/quartznet-3.0-beta1-released.html
@MrZoidberg It does, but I think the idea for migration is not to take dependencies on pre-release packages.
@jacobpovar sure. I've compiled the MT with Quartz.NET beta 1 and will explore how does it work with in my project.
@mrzoidberg - have you had any issues with .net core support for quartz with MT?
I saw masstransit.quartz isn't compatible yet and thinking of compiling MT same as you did
@dekelMP I'm still using MT with quartz in that way and haven't found any problems so far. but I'm not using any persistence for quartz
@MrZoidberg @dekelMP https://github.com/MassTransit/MassTransit/pull/1041 ๐
@alexeyzimarev Any updates on ASB for MT supporting .net standard 2.0?
@Remedij I have a branch using the new .NET compatible assemblies, but it isn't done yet.
The microsoft assemblies are all preview versions, so it needs to get a little more real before I can release anything.
@phatboyg Well, great news! We would really like to use MT on new .net core project, is it possible to share an estimation (even for preview)? Or should we rather consider something else?
Thank you!
It will be there at some point. I can't promise a date though. You can develop and test on regular .NET.
@Remedij Chris started a new thing after heavy refactoring, I gave up rebasing the changes in topology.
And I've gutted more Of the internals to reduce complexity. Should be committing changes this weekend.
@phatboyg is the source code available for .Net Core 2.0? Please provide us the link. Thanks.
@dtssomak source code of what. if I may ask?
Tried all this out and seemed to work without a hitch! Great job so far.
When migrating from 3.5 to 4.0 - should it all just work and be backward compatible? (3.5 consumers, 4.0 publishers and vice-versa)
It should :)
Source code for MassTransit .Net core. I know its available on nuget as package for .net Core, but I wanted the source. The ne that is already available in Github is for .net 4.5.2
It would be great if you can provide me for .net core 2.0
Sent from my Windows 10 phone
From: Alexey Zimarev
Sent: 19 February 2018 08:07 PM
To: MassTransit/MassTransit
Cc: dtssomak; Mention
Subject: Re: [MassTransit/MassTransit] Migration to support netstandard (#909)
@dtssomak source code of what. if I may ask?
โ
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
@dtssomak You can find the tags the NuGet packages were built from on this very site, in fact, here is the latest tag for v4.0.1
Any update on quartz? Is it part of the development releases? I am looking to use it this sprint. Thanks.
Quartz already supports .NET Standard, and MT support was released as well:
The Azure Service Bus transport changes to support .NET Core are in progress, but lacking support for NET 4.5.2 means this would have to be a separate transport to avoid breaking those using the current ASB support. Ugh..
Anyway, this branch: https://github.com/phatboyg/MassTransit/tree/net-core-asb
In the next few months, yes. Just not today. It's a harder than I thought
thing, considering it's an entirely new library structure.
On Sun, Mar 11, 2018 at 3:21 PM, Paul VanRoosendaal <
[email protected]> wrote:
I realize Azure Service Bus Transport support is more involved. Are you
looking to release an update(.NET Std 2.0) for this in the next few months?โ
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MassTransit/MassTransit/issues/909#issuecomment-372145846,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABOSax2NVayanMQOoQyUg2O3C5BcaNUks5tdYc4gaJpZM4N5SPD
.
is there any saga Storage Engines for .net standard?
EF store is not migrated, EF.Core store should be used instead, for obvious reasons. All other stores are migrated.
I'm going to close this issue, and open a new one for the new Azure transport I'm nearly finished building. There will be two transports, one for legacy net452 (existing) and a new one for netstandard.
Most helpful comment
I vote for moving to .net standard 2.0. and removing 1.6, before .net standard 1.6 compatible version of masstransit is released as stable.
Nservicebus for example does that. It targets net452 and net standard2.0.