Create NuGet Package about azure-service-bus-dotnet

[jtaubensee]

NuGet package is available here: https://www.nuget.org/packages/Microsoft.Azure.ServiceBus

And here is the corresponding release: https://github.com/Azure/azure-service-bus-dotnet/releases/tag/0.0.2-preview

[BrianVallelunga]

I was waiting for this library to release a .NET Core port of an app as well. I ended up having to release early so I used the AMQPNetLite Nuget package to communicate with the service bus. If your needs are simple, such as just sending a message to a queue or topic, it's trivial to implement.

[chadwackerman]

https://twitter.com/jtaubensee/status/826630044520849412

You're using Twitter to solicit feedback on class names?

I'm a bit busy discussing graphics driver kernel architecture with Linus on Snapchat but I'll try to get back to you after I help Elon Musk choose rocket nozzle alloys on Pinterest.

Edit: Dude is trying to get the #ServiceBus hashtag trending on Twitter. Good luck with that.

He reaches two people with this tweet. One guy gives a thumbs down to this very comment. That's quite the dedicated effort. The other responds with "+1 for SerbiceBusClientFactory" on Twitter -- yes, "SerbiceBus." And the only reason this discussion is summarized in one place where we can all consider it is because I'm revealing what a self-parody this whole exercise is right now.

[kherrgcmlp]

Hi team,

I just wanted to thank you for all your work on this project. I'm looking forward to seeing a pre release/release of this project.

I'm building a small POC that will greatly benefit from this project.

👍

[jtaubensee]

@neerajyadav - I agree with you. This should be coming right after the new year.

[banisadr]

@chadwackerman we appreciate that you feel so passionately about this topic, however this is an avenue for constructive feedback, not personal attacks. Please limit your comments to well thought-out, adult feedback relevant to the product/issue and refrain from harassing other contributors.

For more information, please refer to the Microsoft Open Source Code of Conduct.

[jtaubensee]

We will publish a NuGet package on April 3rd. For details of what is remaining, see the milestone: https://github.com/Azure/azure-service-bus-dotnet/milestone/2

[jtaubensee]

@sealightPT - I'm currently working to solve 2 issues that are related to our internal process:

• Adding the strong name certificate to our repo
• Verifying that our library is compliant with Microsoft guidelines

As soon as I have these worked out, I will create a NuGet release. Until then, my apologies for the delay.

[jtaubensee]

@galvesribeiro - Unfortunately I don't. Best case scenario it could happen on Monday, worst case it could be 2 weeks out. And to clarify this package will definitely be considered preview. #72 will allow you to strong name sign the package the same way that we do, in case you are looking to try this out ASAP.

[SeanFeldman]

I realize the root cause is NOT your team's fault but it really is quite the mess...

Then why are you taking all of your frustration on this team? ASB team is fixing what should have fixed looong time ago. Yes, long overdue, but they do it. And not only it's taking place in open, but also allow the community to participate and drive the design and implementation. Yes, that includes YOU as well.

Now let me ask you a simple question. Would you rather wait another N months waiting in the dark, or have what you have here? Rhetoric question, indeed.

Amazon Web Services provides a much larger set of services than Azure however they managed to ship .NET Core support for everything in Summer 2015. This past August they even lowered the requirement to .NET Standard 1.3.

Yes. When you have a "messaging" solution that doesn't support atomic operations it's not that difficult to lower the bar. Ops, my bad, taking a bit of a sarcastic path here.

Sometimes "pile o' functions" works great so I'm not staring at old code that doesn't compile, desperately trying to hunt down an aesthetically-renamed parameter, extension method hidden in some new assembly, or web of refactored constructors/startup code that enable some absurd fad dependency-injection subsystem.

If you're saying "having an upgrade guide would be nice" I will back you up 100%. So say so. You don't have to be aggressive. Raise an issue. State the problem. Help making it better.

Ship small pieces and then rev them. Then ship those.

Wish it was that simple. Public API is not a hosted webapp where you can swap the guts and no one will notice. Once API is out, it's locked. ASB team will respect SemVer, so API needs to be proper and not half baked.

Again that's a noble goal and like everyone else at Microsoft you're about to learn that having people type about source code that they can't easily run will turn this into an immense waste of time for everyone. You'll get jobless GitHub hobbyists with 175 starred repositories they pretend to watch and two personal projects, one of which is a 20 line node.js garage door opener gateway they forked after reading about it on Hacker News. These are the same types of people who sit around in the SpaceX group on Reddit, giving armchair advice to actual rocket scientists.

Well, that makes me a "jobless GH hobbyist". Except I don't read Reddit 😃

Seriously, I'm sure you could whip a PR to create a package in less time then it took you to type responses to @jtaubensee.

[sealightPT]

@jtaubensee - When can we expect to have this library on NuGet?

[galvesribeiro]

Hello @jtaubensee, do you have an ETA for the first (even preview) release for the nuget packages?

We want to upgrade our ServiceBus stream provider in dotnet/orleans to support netstandard.

Thanks!

[galvesribeiro]

@jtaubensee Thanks for get back.

I understand. We at Orleans have the same process to follow by getting our packages codesigned to comply MSFT guidelines.

Unfortunately, we can't build from source and use as reference, since it will become a direct dependency on our projects in Orleans and the users wont be able to do the same.

Ok, I hope you can get it out asap.

Thank you, looking forward to get it.

[chadwackerman]

Any news on this?

[jtaubensee]

Hey Everyone - Thanks for your patience on this. We are going to hold off for a while; we have some potential major changes coming. See #87. We would rather not release, only to break what was released.

[chadwackerman]

The issue is that a .NET Core app that needs to talk to ServiceBus is totally blocked in the meantime. By way of example Amazon Web Services provides a much larger set of services than Azure however they managed to ship .NET Core support for everything in Summer 2015. This past August they even lowered the requirement to .NET Standard 1.3.

This puts me in the odd position where I can fully automate Amazon Elastic Beanstalk (whatever the hell that is) however sending a BrokeredMessage leads me down a 20 hour detour through StackOverflow into GitHub and things like "we'll release a package" in December followed by "oops, nope" in mid-February.

Microsoft is charging me by the minute and by the message to run my stuff on Azure however they can't ship libraries that talk to these services. I realize the root cause is NOT your team's fault but it really is quite the mess...

I could argue a business case that you release what you have now as a 1.0-prerelease and then bump to a 2.0-prerelease after you refactor.

I'm glad Microsoft is finally looking at some of these weird ass, overcomplicated method signatures but porting an app is tough enough without dealing with methods that rename, move and wander between different namespaces.

Sometimes "pile o' functions" works great so I'm not staring at old code that doesn't compile, desperately trying to hunt down an aesthetically-renamed parameter, extension method hidden in some new assembly, or web of refactored constructors/startup code that enable some absurd fad dependency-injection subsystem.

Ship small pieces and then rev them. Then ship those. Right now the .NET disease is everybody waiting for everybody else.

[jtaubensee]

@chadwackerman - I totally understand where you are coming from. Our concern is that if we release something today, then we drastically change the programming model tomorrow, customers would be resistant to those changes (since we are drastically breaking APIs).

While we re-design our clients, the best solution for you would be to build your own NuGet package. You can run the dotnet pack command to get the the output you are looking for. We realize this isn't a perfect solution, and we appreciate your patience while we clean up and re-tool some of our clients.

Our intention in open sourcing this project is to get early feedback from our customers as we redesign it. This will be the library that we are going to be living in for a while, and we want to make it right.

[chadwackerman]

That's a fantastic mindset and I applaud it but I'm also going to point out that it's 2017 and I can't send a BrokeredMessage to a Queue from my Linux batch worker node.

Your aesthetic bathroom remodel is surely going to be fabulous but doing it this way turns GitHub into Tumblr, with a bunch of people clicking thumbs up or thumbs down while you pick out floor tile that we can't even walk on.

Meanwhile I'm blocked up with a big load of BrokeredMessages ... and um, where's the toilet?

Anyone coming at this from a NET 4.61 perspective is going to be immediately confused as to where the heck Microsoft.ServiceBus.Messaging went. So you find Microsoft.Azure.ServiceBus, add it, but you get nothing but squiggles in the IDE until you somehow decide to add Microsoft.Azure.ServiceBus.Primitives.

Now... where's ServiceBusNamespaceConnection?

Oops, that's gone, now it takes a connection string. And man those are weird and unlike anything else in Azure. Now, where's SendBatchAsync?

Even today half of Microsoft is going to "one big dll" and the other half is going "ten stupid packages" -- look at Microsoft.Extensions.Configuration for a load of fun. System.Configuration went from name/value pairs to "Microsoft.Extensions.Configuration.Abstractions" and ten trips through NuGet just to "bind" file extensions and read name/value pairs from json. Or look at the alternative: Azure storage, which forces me to to hand code project files in order write a blob to Azure Storage because that team insists on pulling down Korean OData DLLs and KeyVault (Azure/azure-storage-net#372), and even those are blocked on a sev 1 that Microsoft hasn't been able to ship a fix for since June (https://github.com/dotnet/corefx/issues/11100).

Our intention in open sourcing this project is to get early feedback from our customers as we redesign it. This will be the library that we are going to be living in for a while, and we want to make it right.

Again that's a noble goal and like everyone else at Microsoft you're about to learn that having people type about source code that they can't easily run will turn this into an immense waste of time for everyone. You'll get jobless GitHub hobbyists with 175 starred repositories they pretend to watch and two personal projects, one of which is a 20 line node.js garage door opener gateway they forked after reading about it on Hacker News. These are the same types of people who sit around in the SpaceX group on Reddit, giving armchair advice to actual rocket scientists.

Really -- it's ServiceBus. And You're Microsoft, Dammit. You know what to do here. You don't need our help. It's been on NuGet since 2011. If you ran a survey at any paid dev conference I sincerely doubt you'd get ANYONE saying "Yeah, ServiceBus. I sure wish they'd change it around a little."

But do it here and you're going to get horrible advice.

Sure, we can sit here and debate whether you should have a Doric, Ionic or Corinthian toilet brush handle but... c'mon. You guys know what's needed. It doesn't really require "community feedback." Just ship something.

[chadwackerman]

If you want to have a long-winded group discussion about what ServiceBus should be, what it should be called, how much it should cost, what development tools should be provided, what features it should have--maybe spread a little misinformation about AWS queue technologies--then sure, let's see what "open development" can do. But that's not at all what we're discussing here.

We're talking about providing a .NET Core port for an existing library for an Azure Service that shipped years ago. It has nine REST endpoints. And shipping SDKs for Java, Python, PHP, Ruby...

But no .NET Core. And no NuGet package.

Because we have to have a pow-wow about how to rename the methods first? Why exactly?

Wish it was that simple. Public API is not a hosted webapp where you can swap the guts and no one will notice. Once API is out, it's locked.

No, the public API is the REST service. This is some simple code that's supposed to make my life easier talking to that service. As evidenced by the NuGet history and the forked versions and the radical (and probably needless) changes being proposed, obviously this library can and will change.

I suggest: ship a package like they said they would. Then discuss improvements. Increment the major version number and ship that if it's even necessary. Might not be.

In the meantime you're not holding back people from adopting Azure and you're not screwing up cross dependencies like the WebJobs stuff.

[SeanFeldman]

maybe spread a little misinformation about AWS queue technologies

SQS supports transport transactions? Yes or no?

@chadwackerman The point I'm trying to make is coming and shooting off the hip will not get you what you want.

My customers that use ASB have other concerns, that are not Linux or REST related. Does that mean those are cases to dismiss because your way or high way? People adopt Azure in various ways.

[chadwackerman]

Amazon decided to go AMQP which is where Microsoft was headed when they announced they were killing this library last summer. Only to have it reappear right before the holidays. So here we are.

Are you suggesting that not having a NuGet package where people can try this out as improvements are discussed somehow makes for better discussion? Because in addition to seeing no technical suggestions I'm not seeing that argument from you either.

[SeanFeldman]

You haven't answered the question @chadwackerman

[chadwackerman]

What's the question? That Amazon provides .NET Core library for SQS, that Pivotal provides a .NET Core library for RabbitMQ, and Microsoft does not provide a .NET Core library for ServiceBus and that's somehow related to the fact that ServiceBus provides transactions over received messages (oops it can't) or somehow magically wraps a transaction around around a SQL update (in our dreams)? Because I fail to see how that advances this discussion.

Distributed systems are hard and there ain't nothing this little shim library can do to help you there. In fact, if we're going to talk about architectural considerations I'd strongly suggest that this library NOT get into the business of implying features the REST backend doesn't support through clever function signatures. This is important stuff and if someone is using ServiceBus instead of Azure Queues they've likely landed here for a reason.

[jtaubensee]

@BrianVallelunga - That is a good idea, and unfortunately the temporary work around until we have a released library.

@chadwackerman - I do apologize that this is an inconvenience for you. I too wish that we had this library earlier. One thing that I would like to clear up though is the following:

In fact, if we're going to talk about architectural considerations I'd strongly suggest that this library NOT get into the business of implying features the REST backend doesn't support through clever function signatures

This library is not a REST wrapper. The primary protocol of our service is AMQP, as this provides far better performance.

If you would like to discuss our plans for this library further, please contact me on twitter.

[chadwackerman]

@banisadr The issue here is process, and in order to improve process you have to cite examples. Sorry if someone got embarrassed. But shining a flashlight isn't an attack.

I would propose that all discussions regarding this library happen on GitHub. Especially really important issues that are blocking it from being shipped. Such as how to rename the class factory.

I'm not saying it's the case here (at all!), but there are definitely people in the Microsoft ecosystem who are far more interested in building their personal brand than actually getting work done.

[niemyjski]

Any idea when a nuget package will be available>?