Add support for SystemMessaging and SOAP Web Services
mvandenb opened this issue · comments
Is there planned support for Queueing through the System.Messaging namespace and Soap WebServices through some other namespace? Will there be support for MSMQ, AMQP, SOAP, etc?
Not currently planned. @terrajobst has this come up before?
Updated title and tag so we can track this for the compat pack.
Given that it looks like the System.Messaging code is available as Reference Source, is this something that an external contributor could work on?
looks like someone had a go already https://www.nuget.org/packages/Experimental.System.Messaging/
Nice @SimonCropp looks like system.messaging is not such a big effort.
I think it would be better to split the task of porting System.Messaging from the whole SOAP World.
msmqIntegrationBinding and netMsmqBinding are WCF-specific, which may be what the OP was getting at by mentioning SOAP. Some sort of built-in consumer and poison message retry functionality like is present in the WCF bindings would be great since I'm not sure the bindings will make it to .NET Core.
@karelz @terrajobst Given that .NET Core 3.0 is going to be focusing on getting a lot more Windows-specific parts running on top of it, it seems like System.Messaging would be a good candidate for being brought over in some fashion as well. We definitely have customers who would use MSMQ on .NET Core if it was available.
Hi,
any news on this topic ? The milestone is future, why not 3.0 ?
@danmosemsft is it something on your radar?
The milestone is future, why not 3.0?
Because it is not on our 3.0 roadmap (yet). It didn't get prioritized so far over other work.
It is not on my radar.
cc @zhenlan
I am not aware of any plan for this at this point.
Can it be included in 3.0 roadmap ?
The only hard work i see is about code security, is it already ported with for other components ?
Including at least System.Messaging in .net core 3.0 / Windows Compatibility Pack would be great, especially for NServiceBus users, as it makes a heavy use of MSMQ, because of it's bus-style messaging. All other messaging systems are broker-style, single point of failure.
Please, let us use Microsoft Message Queuing within .net core or compatibility pack!
Given the announcement that apsnet core will not run on .net framework, this issue is now a priority for netcore 3.0, it will block a whole lot of nservicebus users ! aspnet/Announcements#324
@terrajobst @DamianEdwards can you please comment on the related plans / priority?
Given aspnet/Announcements#324 can you pls break this issue in smaller ones ?
Bringin on MSMQ will allow NServiceBus transport to exist in netcore 3.0, i understand the the whole SOPA thing is a major undertaking, but MSMQ alone it's not.
This will also allow Rebus MSMQ to exist on .net core 3.0
No MSMQ? I'm porting over a .NET app that uses it extensively. Not good!
For now, we are using https://www.nuget.org/packages/Experimental.System.Messaging/
Where can I find any timeline regarding the release of this feature in .NET Core 2.2 (+)? In the .NET world new systems are often built using .NET Core 2.2 and you work through your enterprise until you get to some external/messaging system that needs MSMQ and you are stuck. Forced to look at different technology stacks. No good.
An update would be welcome, and i would feel much better separating the MSMQ porting (System.Messaging) from the SOAP world, i do not understand why they are tied together.
As far as I know there is no plan for MSMQ in .net core 2.x
The intention is to bring that on 3.x along with other platform specific features. So I would not expect much of this issue
@dariogriffo do you have source of your statements?
First, we do not plan to bring ANY features to 2.1/2.2. Those are are primarily servicing trains, targeted at stability. New features go into new in-the-making versions.
Second, based on my chats with the teams involved, there are currently no plans to support MSMQ in .NET Core 3.0. If you have official info otherwise, please link it to avoid confusion to others and setting false expectations. Thanks!
Any specific reason of not including MSMQ with .net core 3.0 also. In my opinion, its being widely used and will help applications using MSMQ to move to .net core 3. Thanks.
Hi guys, since donet core 3.0 will not include this, do you have any plan for 3.1 ? I'm really afraid that it does not given that 3.1 is scheduled to be released just a few months after 3.0 :(
As stated before I'm not referring to anything SOAP related, just System.Messaging.
MSMQ bindings for WCF Core is really needed to make the flawless switch to the dotnet core.
The same as WF and WCF, it was used a lot in enterprise solutions. Is there any chance we could get this in 3.1?
Please add this in .net core 3.0 or at least sometime in the near future. We are starting a very major project and our intentions are to build this on .net core. It would be nice if MSMQ would be an option for an event bus instead of having to rely on external providers such as RabbitMQ or some other alternative.
As others have mentioned, I am not needing any kind of SOAP / WCF interactions, we simply need a low level Event Message Broker.
as a first step, could the code for MSMQ be released as open source?
@DamianEdwards told at ndc that no other api will come to dotnet core after 3.x so we definitely need an answer on this topic, pretty please ( https://youtu.be/uuc3MjigHSg?t=2850 ).
Regarting Nservicebus, I've tried to implement an msmq netstandard transport starting from this code https://github.com/krazure/Experimental.System.Messaging and i noticed that the missing bits are about code security MessageQueue.SetPermissions and related code, i can't fathom the implication of that :(
I was able to make Nservicebus work, but of course MSDTC is not supported so we lowered the consistency grantee of the transport https://docs.particular.net/transports/transactions to SendsAtomicWithReceive, i guess this is expected and not a blocking issue. https://github.com/valeriob/NServiceBus.Transport.Msmq/tree/experimental_system_messaging
We don't plan on bringing this .NET Framework API to .NET Core. See this announcement for details.
@terrajobst Not cool. I don't see a good reason why you decided to omit "System.Messaging" library from the compatibility pack.
It's not only about WCF. Lots of enterprises use NServiceBus. And MSMQ is the only messaging system that supports bus-style distributed messaging to be used with NServiceBus.
@terrajobst is System.Messaging open sourced? and if not, can it be?
@terrajobst Not cool. I don't see a good reason why you decided to omit "System.Messaging" library from the compatibility pack.
We've spent a lot of our engineering resources over the last years to port stuff that (1) a lot of people depend on or (2) that makes sense to have on .NET Core. Based on the evidence we've seen so far, we don't believe System.Messaging (MSMQ) is in either bucket. Of course, this doesn't mean that this component can't be made available as part of the Windows Compat Pack; it just means we don't believe it's a good investment from a cost/benefit standpoint.
@terrajobst is System.Messaging open sourced? and if not, can it be?
I'll be looking into it. That's why I wrote this in the announcement:
Simultaneously, we’re looking into releasing more of the .NET Framework code base under the MIT license on GitHub to allow the community to create OSS projects for technologies we’re not intending to bring to .NET Core. For example, there already are community projects for CoreWF and CoreWCF.
@terrajobst thanks for chasing this. and i hope you and the team dont get too much abuse for burning some legacy stuff.
@terrajobst thanks for chasing this. and i hope you and the team dont get too much abuse for burning some legacy stuff.
Thanks. Fortunately, we've the luxury of having an amazing community :-)
Personally, I moved on and we ended up going with NATS. This works like a champ for us (way outperformed MSMQ btw).
So for fun, I got System.Messaging working under netcore, using the reference source. Since the reference source for System.Messaging is NOT included at https://github.com/microsoft/referencesource, I was wondering what the licensing implications of porting it are. (I emailed refsrcfeedback@microsoft.com and got nothing back).
At this point, it works as far as I need it to (basic send/receive from queues on windows only), but the licensing keeps me from using the code for real.
Can anyone at MSFT comment on who I should ask? @terrajobst ? Anyone?
Oh, that is great!
@weloytty please add me and @richlander @danmosemsft to the email, we will try to push on it ...
"msftgits added this to the 5.0 milestone on 31 Jan"
What does that implicate?
It looks as if this is happening, thanks @karelz