Skip to content
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

Add support for SystemMessaging and SOAP Web Services #16409

Closed
mvandenb opened this issue Feb 18, 2016 · 40 comments
Closed

Add support for SystemMessaging and SOAP Web Services #16409

mvandenb opened this issue Feb 18, 2016 · 40 comments
Labels
area-Meta enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@mvandenb
Copy link

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?

@danmoseley danmoseley removed their assignment Oct 14, 2016
@danmoseley
Copy link
Member

Not currently planned. @terrajobst has this come up before?

@terrajobst terrajobst changed the title Queueing/WebServices and associated protocols Add support for SystemMessaging and SOAP Web Services Oct 26, 2017
@terrajobst
Copy link
Member

Updated title and tag so we can track this for the compat pack.

@bording
Copy link
Contributor

bording commented Nov 27, 2017

Given that it looks like the System.Messaging code is available as Reference Source, is this something that an external contributor could work on?

@SimonCropp
Copy link
Contributor

looks like someone had a go already https://www.nuget.org/packages/Experimental.System.Messaging/

@valeriob
Copy link

valeriob commented May 8, 2018

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.

@gtbuchanan
Copy link

gtbuchanan commented Jun 26, 2018

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.

@bording
Copy link
Contributor

bording commented Jul 6, 2018

@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.

@valeriob
Copy link

valeriob commented Oct 1, 2018

Hi,
any news on this topic ? The milestone is future, why not 3.0 ?

@karelz
Copy link
Member

karelz commented Oct 1, 2018

@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.

@danmoseley
Copy link
Member

It is not on my radar.
cc @zhenlan

@zhenlan
Copy link
Member

zhenlan commented Oct 1, 2018

I am not aware of any plan for this at this point.

@valeriob
Copy link

valeriob commented Oct 2, 2018

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 ?

@gdar91
Copy link

gdar91 commented Oct 7, 2018

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!

@valeriob
Copy link

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

@karelz
Copy link
Member

karelz commented Oct 31, 2018

@terrajobst @DamianEdwards can you please comment on the related plans / priority?

@valeriob
Copy link

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.

@dariogriffo
Copy link

This will also allow Rebus MSMQ to exist on .net core 3.0

@foobarred1
Copy link

No MSMQ? I'm porting over a .NET app that uses it extensively. Not good!

@wangjia184
Copy link

For now, we are using https://www.nuget.org/packages/Experimental.System.Messaging/

@eleg8r
Copy link

eleg8r commented May 11, 2019

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.

@valeriob
Copy link

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.

@dariogriffo
Copy link

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

@karelz
Copy link
Member

karelz commented May 11, 2019

@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!

@satyajit-behera
Copy link

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.

@valeriob
Copy link

valeriob commented Jun 4, 2019

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.

@ElijahReva
Copy link

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?

@CrossBound
Copy link

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.

@SimonCropp
Copy link
Contributor

as a first step, could the code for MSMQ be released as open source?

@valeriob
Copy link

valeriob commented Jul 8, 2019

@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

@terrajobst
Copy link
Member

We don't plan on bringing this .NET Framework API to .NET Core. See this announcement for details.

@gdar91
Copy link

gdar91 commented Oct 14, 2019

@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.

@SimonCropp
Copy link
Contributor

@terrajobst is System.Messaging open sourced? and if not, can it be?

@terrajobst
Copy link
Member

terrajobst commented Oct 14, 2019

@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.

@SimonCropp
Copy link
Contributor

@terrajobst thanks for chasing this. and i hope you and the team dont get too much abuse for burning some legacy stuff.

@terrajobst
Copy link
Member

@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 :-)

@CrossBound
Copy link

Personally, I moved on and we ended up going with NATS. This works like a champ for us (way outperformed MSMQ btw).

https://nats.io/

@weloytty
Copy link

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?

@karelz
Copy link
Member

karelz commented Jan 11, 2020

Oh, that is great!
@weloytty please add me and @richlander @danmosemsft to the email, we will try to push on it ...

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 5.0 milestone Jan 31, 2020
@tommypetersson58
Copy link

"msftgits added this to the 5.0 milestone on 31 Jan"

What does that implicate?

@weloytty
Copy link

It looks as if this is happening, thanks @karelz

microsoft/referencesource#141

@ghost ghost locked as resolved and limited conversation to collaborators Jan 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Meta enhancement Product code improvement that does NOT require public API changes/additions
Projects
None yet
Development

No branches or pull requests