“.NET 9 Is Killing MediatR, MassTransit & Wolverine!”

Get the Getting Started with C# course for free: dometrain.com/course/getting-...
Use code KUBE20 and get 20% off the brand new "From Zero to Hero: Kubernetes for Developers" course on Dometrain: dometrain.com/course/from-zer...
Become a Patreon and get special perks: / nickchapsas
Hello, everybody, I'm Nick, and in this video, I will talk about the new eventing (or messaging) framework that is coming in .NET 9 and explain how it will impact the .NET open-source ecosystem.
Link to the issue: github.com/dotnet/aspnetcore/...
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: github.com/Elfocrash
Follow me on Twitter: / nickchapsas
Connect on LinkedIn: / nick-chapsas
Keep coding merch: keepcoding.shop
#csharp #dotnet

[@andersborum9267]

I think it's the right direction, better abstractions for everybody.

[@fatlumlatifi2897]

This is Microsoft making open source tooling while the .NET community is trying to put a price tag on building projects with .NET. Building "open source" businesses that lock in customers with developer tooling is frankly evil. We should be developing together to make money from end users, not each other.

[@GuillaumeLecomte]

@@fatlumlatifi2897 pass on the licensing cost of your dependencies to your end users, developing paid tooling is not "evil"...

[@rotgertesla]

@@fatlumlatifi2897 Yea! As a user of EPPLUS excel library, I was really mad when they decided to go commercial. Same for QuestPDF. That's not a good trend.

[@hektonian]

I like it when there's a "default implementation" to use. They're usually good enough for getting things done with alright performance, they're free with great long term support, and most importantly, they're unlikely to force me to do the software equivalent of an organ transplant

[@Balgoriusis]

Reminds me the introduction of DI to .NET. It killed Unity DI, but we ended up with really good DI.

[@djchrisi]

Microsoft.Extensions.DependencyInjection ist okay (and fast) for the basic stuff. For more advanced usages I still prefer other solutions.

[@user-tk2jy8xr8b]

We're using SimpleInjector because MS DI doesn't provide enough flexibility

[@gileee]

​@@user-tk2jy8xr8b What specific requirement couldn't you fulfill with mcr.di? Just curious.

[@GirlDadGigaChad]

Meh autofac

[@MaThMaTa1000]

I miss Castle

[@antonmartyniuk]

I really like the idea that Microsoft is creating this kind of Event's Framework so we can finally have a golden standard. For libraries like MediatR, MassTransit, Wolverine - I can only say the old proverb: "You can live and adapt or die with the past". I hope these libraries will catch up and adapt and we'll be using them on top of Microsoft interfaces. I really like these libraries

[@raindev88]

as for someone who works in fintech industry with heavily regulated engineering guidelines. we can't just use these libraries from the get-go without scrutiny. I've never been more excited to be a .NET dev than ever.

[@nec135]

What is there to catch up to for the existing libraries? The pushback revolves around MS being the 500lb gorilla that through sheer mass destroys other higher quality projects.

[@nec135]

@raindev88 wouldn’t you have to apply the same level of scrutiny to MS libs?

[@raindev88]

@@nec135 nope. as long as it is microsoft developed library or part of the .NET SDK we're good.

[@GarethBradley]

​@@raindev88i work in fintech and able to use open source libraries. This "can only trust microsoft" is a cop out.

[@soucianceeqdamrashti8175]

Creating abstractions should be encouraged. I mean that should be a win-win for everyone. If I want to change my logging provider that's much easier now then before. Should be the same with event/messaging provider.

[@reikooters]

I agree the sample code that looks similar to Minimal APIs looks good. I'm also a fan of FastEndpoints approach where you are given the framework to implement the event handlers and persistence in your own way.

[@AlexBroitman]

I like the idea. Yes, it may kill some existing products. It was Newtonsoft with its serialization. Today we have the library from Microsoft. It was Unity for DI. Today we have ServiceCollection from Microsoft. Today we have ILogger abstraction from Microsoft for logging while NLog, SeriLog and other still exist.

[@rty361]

ILogger can be used with serilog, serilog handles the saving/partitioning of the log files, and ILogger provides an interface for creating log messages.

[@markrobinson5420]

Your thumbnails make me want to go live in the woods. But your content is great.

[@nickchapsas]

My thumbnails make me want to go live in the woods mate

[@markrobinson5420]

@@nickchapsas haha 😀

[@jaans3712]

I bet those are generated by Dall-e

[@SkandiaAUS]

I'm not looking forward to when I go camping at my favourite off grid spot and someone has a Star link set up.

[@tree267]

Tbh the thumbnails are clickbaity af and don’t do the channel content justice.

[@chrisowens6670]

I can't wait. Framework integration for this would be awesome. MediatR doesn't go far enough, and it's very hard to get started with MassTransit. Brighter, Wolverine and other libraries/components are exercises in frustration dealing with the author's personal flavors and spice that often make them at least annoying to use if not full of frustration.

[@modernkennnern]

When Microsoft added their DI implementation there were a lot of "losers". It had (and still has) its flaws but practically nobody would say that it's not an improvement over what we had before. I imagine this will have a similar story; I believe in the .Net team to make a solid foundation and more importantly to support it for years to come, as they have with most things.

[@felipealves4856]

I really don't see any problem in creating a standard for existing frameworks. Nobody's saying that Masstransit, MediatR or Wolverine need to disappear, but yes they might need to evolve to something new. ILogger did a good job in creating a standard for logs, and Serilog, Nlog and others still live by today, and I don't see anyone crying because of it. Technology tends to evolve as the time passes, so should do the same as for Frameworks.

[@ashbjorn]

This is a big as the DI discussion way back, but as far as I can remember all the authors of those libraries ended up being involved in decisions making and design direction, similarly how it was done for Json and Logging. It would seem absurd for MS to take a stance now and saw they are going to ignore the established frameworks. Surely they will be involved....right?

[@DevonLehmanJ]

It's a lot easier for our software intake process if it's officially supported by Microsoft

[@metacob]

I'm worried that it'll be like the MS DI - okay enough for lots of libraries to start using it as a dependency, but not nearly as good as the top 3rd party solutions which will be forced to come up with crappy interoperability code.

[@lukegordon4734]

FWIW this happens in other languages/ecosystems as well that have a main player. This isn't just a .NET/Microsoft issue. As a consumer of open source and Microsoft my concern is more about getting something half baked/clunky from Microsoft we have to then workaround that undermines better alternatives at the same time.

[@frostyusername5011]

With Fowler on the lineup I think that won't happen

[@VeNoM0619]

The more native/standard support for things the better. I've been told Python is easy to develop because it has so many libraries that it allows you to do anything quickly. That's what we need: well proven and documented and capable of doing anything.

[@satyayuga0]

All in all, I like it. That makes it a more streamlined developer experience. And in terms of 3rd party support. It's valid that 3rd party libs will still be used, just like Serilog. It is still the defacto standard for the ILogger implementation. Keep coding Microsoft!

[@cjb110]

From my understanding there's quite a lot variation in the space, so I'd imagine an end result like logging, MS has a basic imp, but a good set of abstracts, 3rd parties provide a full feature set using those abstractions. Devs then find it easier to implement and/or replace the 3rd parties with others. MS adding builtin DI, killed the DI frameworks, true, but was that actually bad for the C# codebases overall? I'd say it was almost a 'core' concept/feature that needed to be built in, I don't think Event/Messaging is like that though.

[@killymxi]

A lot of businesses exist simply as ways around inconveniences. In IT, we have the luxury to be able to remove the root of inconvenience and expect people to move on to find other problems to solve. Some industries may have actual legal protection or lobby against it.

[@guy7524]

@nickchapsas Microsoft has said the new eventing framework will only be used for out of process communication so will not be used to replace frameworks that are used for CQRS pattern like MediatR

[@wobuntu]

I'm always a fan of MS libs, always prefer them over 3rd party stuff. They tend to almost never introduce breaking changes, they release most stuff nowadays licensed under the MIT license, they are maintained very well, the apis are thought through, ... Looking forward to it

[@TurntableTV]

Hey Nick, just wanted to say that I'm a big fan of your contents.

[@nickchapsas]

I hate you

[@satyayuga0]

@@nickchapsasnice

[@fabii5555]

​@@nickchapsas How brutal

[@daretsuki6988]

Can't catch up with new features, they're coming so fast. Btw I'd love to see your take on functional programming (OOP forbidden) in C# and use maybe of LanguageExt.Core library. Although less performant, people claim it's so much faster to write, less error-prone and even more readable.

[@pagorbunov]

There was such video already

[@jameshancock]

If they get it so a strongly typed client for these is created automatically as a result of the service definition then this could be a winner. Especially if the transport is hidden. Which may be why MS is also interested in OpenAPI/swagger again. (Which is horrific)

[@SenkusJulius]

I would really like to avoid situations like with hot reload fiasco, that some part would be exclusive for Microsoft, but I do think that this would bring a better standard as others mentioned with DI, leaving old Unity DI implementation.

[@stoic7810]

I think your swift mention of how serilog adapted and is still operating in the logging space is exactly what the developers of messaging libraries should concentrate on. I don't think MS is trying to compete in the space, we will most likely just see better standardization. I'm looking forward to it, cause although mediater and wolverine is awesome, i always find myself missing specific features. Standardizing and abstraction here would go a far way.

[@nickchapsas]

On the other hand, them adding DI did kill all other libraries so there’s that

[@dimitrishadrin]

​@@nickchapsas it killed, but not all. Like autofac is still better in terms of functionality. And some new libraries are created like Scrutor. To me it is evolution not extinction.

[@privatesocialhandle]

If it works good and does the job I am for it. It is unfortunate if it kills thousands of development hours and sweat of independent developers hard work. But anything native (or built-in) that works well is a good thing. You still have the other options.

[@s1kky]

Yes, very useful especially for the upcoming eventing framework thats coming in net9

[@esendrow]

I understand that most people think that competition and choice are good things, but are they? When I need to do messaging, do I really want to go through and evaluate 10 different frameworks that all do essentially the same, but each one has some obscure downsides or problems so I end up min-maxing the framework list by least problems and most compatibility for my project. Do we really want this? Does this really help productivity? I for one just want one solution that does excatly what it is supposed to do.

[@bosegeorge1425]

Can you do a video on semantic kernal, autogen etc

[@amalaljohari9358]

In our company it's not allowed to use libraries that are not supported by Microsoft itself, because no one knows the future or the support of those libraries, I remember when we used identity server 4 in one of our projects and suddenly the situation of the library changed, so we stuck with old .net core 2 project that we can't update anymore. Yes I agree that Microsoft provide these libraries as built in

[@marcobaccaro]

Once they are built-in decently, yes, those frameworks/libraries may die quickly. Like Dependency Injection, there is no reason to work with Ninject, StructureMap, and the other DI frameworks.

[@mtsmithtube]

So does this create a monolithic web app with message queue that you can scale horizontally?

[@redsquarem3369]

What

[@Osirus1156]

It'd be easier for large companies to adopt this stuff. Corporate controls are usually so bloated and convoluted they block usage of a lot of open source libraries.

[@BlTemplar]

So Microsoft is basically looking for new ways to sell Azure and built-in messaging with prod-ready Azure support looks like a good selling factor for them. Making good abstractions and unified contracts seems to be a secondary task for them.

[@MarkCastle]

Yeh that’s the worry.. if they force Azure on people it’ll be a retrograde step tbh

[@BlTemplar]

@@MarkCastle I don’t think they try to force Azure or anything. But it seems that dotnet team will be focused on delivering features tied to Azure. Microsoft will advertise Azure by showing how easy it is to become cloud-native with dotnet.

[@SlackwareNVM]

Looking at what happened with IdentityServer, I prefer to have a MS backed library.

[@garcipat]

A good example was DependencyInjection. I very happy they built that themselfs out of the box I know its suported longterm and I dont have to learn when switching my job. There will always be people sufering because o. These things but that means they just need to give people a good reason still using their stuff. THat should not kill but drive inovation

[@TheCzemike]

I wonder if any of the folks creating a business around open source projects in .NET specifically plan for Microsoft creating something in the framework which makes their library and business obsolete? I'm curious if the creator of Wolverine has a "Microsoft decided to replace us" contingency they can execute, especially regarding what commercial clients they currently have because the growth of the business is now (knee)capped and loss of paid support is only a matter of time as it cannot remain economically feasible.

[@Fred-yq3fs]

I very much like mediator, but a built-in way would be good too... if it's as good: we'll see... I mean their main focus is to push Azure, so I could see the abstractions getting geared towards Azure (more features, less bugs, etc...) than to other providers. In that case, the existing libraries have their new niche: provide viable alternatives to Azure integration.

[@devfric3149]

Here I thought we would have to wait for Jimmy Bogard to pass on for MediatR to not be the default implementation of CQRS.

[@paulkoopmans4620]

This practice of "stealing" or "integrating" something into the main product has been there since the dawn of time. it is everywhere, and here to stay! That goes for many other things as well btw. Back in the day you needed a dedicated video card even if it was a simple one. cars had an open bay where you had to buy and install a separate radio in. To share the internet back in the day I needed a modem and separate computer which was replaced with all-in-one devices. which now even a lot of the times you do not get to choose but your provider enforces. Proprietary devices/connectors that force you to use "theirs" [Fruity company]. On a deep level it is a human desire to want as much as we can have; we are all guilty of it. If you see something or somebody be successful with something... you want it and you are going to try and take a piece of the market share. Or the other reason, why would I pay somebody to do X if I can do it myself. I truly feel for the creators but eventually it's inevitable. Ever since it's conception MS and .NET wants to not be dependent on external projects. Even if they are free.

[@FeistyFugu]

As soneone who worked for several years as a consultant, I love .NET projects because .NET devs tend to stick with the libraries Microsoft provides. This makes moving from one client to another much easier. However, I would NEVER maintain a .NET open source library. Doing so is like being an unpaid R&D intern for Microsoft. If you develop something popular, Microsoft will copy it and all your users will migrate since that's just what .NET devs always do. Not the best strategy if you want to build a vibrant open source community around your products.

[@djp_video]

You know that anything Microsoft adds is going to be supported in the long-term. You can't say that about third party libraries. I, like many who have worked on long-term projects, have been burned more than a few times by using a library that gets abandoned.

[@ljobject]

Luckily some developers made a safe choice and built their backends on WCF using MSMQ and wrote frontend in Silverlight. This stuff will never get abandoned!

[@thiagomatu]

Would not make any sense to switch an existing and working tool for this in an already running project. For new projects? Ah, that's worth to give it a try

[@gert-janvanderkamp3508]

A better strategy would be to let the market decide on the best library/ abstrcations, then MS buying them and integrating. This way they're killing what community they have (which just is a level or two below Java and Python). Not sure if the upside outways the downside, also from the POV of MS themselves..

[@TECHN01200]

I'll just ask, why is this abstraction a good abstraction? I have yet to see the point of these libraries.

[@rozhdov]

I can understand frustration of developers of existing solutions, but I would like implementation from Microsoft. I always avoid 3rd party libraries when possible exactly because of long term support concerns, and because some 3rd party break backwards compatibility more often than I like.

[@metaltyphoon]

MS should definitely do it because they would be building with AOT in mind

[@user-px2oj3dg4c]

Hey sir , how are you ? I just want to discuss with you about computed columns in relating to EF core . So if you have can you reach me ? Thank you sir

[@nordica8942]

As a developer, I don't really give a sh*t. They're just tools. It doesn't matter who makes them. If I'm developing a .NET application, of course I'd prefer the tools that are already provided by .NET Framework. If a third party library does the same job better, or does something else that is more suitable for a particular use case, I'd go for that libary. That's it.

[@eugenestein1629]

It's good to have the default option as long as it doesn't undermine competition

[@Cesar-qi2jb]

This will make switching to their transport seamless

[@mvonballmo]

I think the argument "will be fixed by basically the best in the industry," while not necessarily wrong, might mire you in unfruitful discussions. I think it's better to say that Microsoft has a lot more resources to cover more use cases than an open-source project might. When Microsoft builds something foundational, they tend to take a few iterations, but they also tend to create a very good, generalized API that covers a lot of use cases. An open-source tool will be very good, but will usually be more limited in scope by the very fact that it can't throw as many people or dollars at the problem as MS can. And MS does have very, very good people working on this, who are more likely to be open to covering your use cases in their generalized API and less likely to tell you to add it yourself.

[@AlFasGD]

I've seen people avoiding making their own libraries or solutions for their needs, expecting Microsoft to provide. Others are disliking it when Microsoft themselves are building a solution of their own for something that multiple OSS projects have taken ahold of, with full opinionation to their own in-house ecosystems. Microsoft is doing good. They're doing business, but they're not stripping away from you anything. The fact that those library authors have chosen to do business over a field that .NET didn't cover at one point doesn't mean it's sustainable. Their projects will still be usable, and Microsoft has no authority nor do they intend to actually kill those projects. And as a consumer, I want the least amount of friction when using any feature, much less on a cloud service that I want the highest possible uptime and fastest possible response.

[@JonathanYee]

IMO OSS comes about because the official system/framework doesn't provide the functionality and out of a need people have shared their solutions. This is what drives innovation and growth. When the official team realises the huge adoption of the need and plans to provide it out of the box, I reckon that's a win for all. That's one way to drive developer experience in a certain language/framework. Now, when OSS authors decide to make it their life income and have that taken away by an official product, they either need to innovate and find another problem to solve or provide more value. The kneejerk reaction from OSS authors is understandable but they chose to build their lives off another's. I'm not an OSS author so I maybe totally out of my depth but that's my take on a developer using the ecosystem.

[@jyrikgauldurson8169]

The take that MS shouldn't make it because there are others is insane to me.

[@Talk378]

“I miss ninject!” - nobody It will be fine

[@user-pu9pf3xn4v]

Hi sorry maybe i missed, but the site seems broken, i can not buy the kube course

[@Johno2518]

I wonder if this is being copied from the MVVM CommunityToolkit (in part)

[@junkyardmonkie]

It was never very big, but how does this compare to Microsoft Orleans?

[@fusedqyou]

People should understand this is not suddenly going to kill existing products. You don't just kill something that has been tested and works very well. There will be tools in place where you can still work with these.

[@ConradCreel]

So, integrating DAPR natively

[@Caedin8]

At work I have to jump through hoops to bring in something 3rd party like wolverine, but if it’s Microsoft I can add it without any fuss. For that reason alone I support this change

[@robertmckee9272]

Sorry, but I really like that Microsoft will be including this. I have a lot more faith that this will be around and supported in 10 years than the other packages. Like...Dawn.Guard, just one day the author had more important things and it's now dead. I've gotten bitten too many times by relying on 3rd party packages in my projects, so I'm happy to see this, and it would definitely make me more confident in using it when appropriate.

[@SilentTremor]

Microsoft should fix System.Drawing

[@yuGesreveR]

I think Microsoft can do anything they want. At the end of the day the framework and platform are theirs. And the only way for the authors of the mentioned libraries is just to try to adapt. Really, it's just business, nothing personal. You can't blame someone who does your job better or in a more convenient way

[@SlackwareNVM]

Is Microsoft going to build something better? Then great! Why would I be against that? Either way, no one is forced to use one library or another. So far, Microsoft has done well with providing a built-in abstraction and a default implementation which is very customizable and extensible. If competing libraries share the same abstractions, I'd be more inclined to try new ones out.

[@winchester2581]

I like the direction Microsoft is moving in. Building its own solution for that is a great way to create so-called "out-of-box" experience

[@lordmetzgermeister]

To be entirely honest, I don't care if some libraries will be abandoned because of this. I might be of a different opinion if I was a lib dev myself. Nevertheless, unification and at least basic built-in support for messaging will be very much welcome in .NET. We have DIC, logging and serialization, we should have messaging as well. Any developer trying to start with events and messaging will have much better starting point with a built-in provider rather than having to figure out which of the weird library names actually make sense for them to use.

[@bar10dr]

If its better then the competition then why not

[@nitrovent]

At around 8:50 you say you're not sure Jimmy wants to be known for Automapper. Well at least in the comment you show at 3:10 he writes that MediatR is to promote himself.

[@DarraghJones]

Pretty sure Jimmy was being sarcastic

[@nitrovent]

That may well be ;)

[@konjcek1]

It was a sarcastic response to a comment before, that said OSS libraries like this exist purely for author's self promotion :)

[@Charles-tq9tc]

I dont think that logging and DI show as much possible diversity as the messaging landscape does. So not sure it's the right move to try unify that zoo. As an example from the java world, spring tries to unify messaging abstractions, and imho, beyond trivial examples, it's a dumpster fire. A lot of functionality offered by the various messaging/eventing platforms (cloud or not) is lost in the process or becomes super complicated to use correctly. And the complexity to maintain it all is just insane. The kafka related code in Spring is more lines than the actual kafka lib for example ... compat management also becomes not so fun. And microsoft shouldnt be blindly trusted, MSMQ has been feature frozen for years, and will be dumped soon, that's not what i call great support. (ok it had a long life)

[@JamesOfKS]

every evolution of Microsoft opens door for new open source ideas to break barrier. i welcome the abstractions and then just make connectors for those prior libraries

[@rty361]

I would love to see this. MassTransit can be limiting, and no offense to Chris(one of the founders) but their documentation sucks! Microsoft docs will be a much needed refresher when developing event centric patterns

[@LogicException]

10:00 This statement is nonsense: The companies behind the tool do not provide bug support. They provide development support in the form of consulting. Something Microsoft will never offer you. Try calling Microsoft and getting an answer to the question of how you can realize a complicated use case. You can forget it. If I have a complicated use case, on the other hand, I can call these companies, from the custom libraries, and get technically qualified help there - for cash, of course. That's the point. Not whether MS will maintain something in LTS or not.

[@nklaveren]

normally, the first overengineering library on all dotnet projects.

[@VladMihailescu]

I don't understand the drama here, people mentioned MS will crush the space and already existing OSS tooling. How ? What is stopping people from continuing to use whatever they want at the end of the day. And what is stopping more creators from taking inspiration from what MS will pump out and spin it into their new personal releases (like taking only the best parts).

[@Sayuri998]

There seems to be so much hate against this from what I see in the video. But it just seems selfish. Yes, Microsoft is going to add a new implementation. This is fantastic for everyone. No need to find 3rd party libraries that meets our needs, no need for bloat our binary with nuget packages, free and quick security updates, more exposure, more support, etc. But if it doesn't meet your needs, you can still roll out a 3rd party library. Microsoft's implementation isn't going to kill that. It just sounds like all these library authors are whining that Microsoft is stealing their profits. I know, it sucks. But it's a harsh world we live in: adapt or disappear. Would we rather trade profit for everyone for profit for a few companies? I'd rather not.

[@megadrofan]

I would like to see something that actually provide orchestration on top of event streams. Back in the days Microsoft had a Workflow Foundation framework, but there is no modern alterative for it. In the cloud we have Azure Durable Functions, but they are too tightly coupled with azure services. We need something more infrastructure agnostic and supported from Microsoft

[@user-pd4ru6ww6u]

I can't understand what he says at 7:44. He says "time based events, queues, and ..." what I heard was "Katkavakavee" but I KNOW that is NOT right 😂

[@DisturbedNeo]

He said "Kafka", as in Apache Kafka

[@math1a5]

"... I don't know...Kafka, they can be anything"

[@nmarcel]

IMHO this is a very bad argument: The development of technology X would hurt the monetization of people creating/mantaining technology Y. Yes, of course... so what? the opposite leads to stagnation and no competitive/better tech would have evolved by protecting the previous ones. And finally the point is not the tech, but the solution it provides (welcome AI).

[@user-iw1eo1hr2u]

Lets record a video about Orleans!!! =)

[@fritzfahrmann4730]

aren't they not also killing/killed NancyFx and now NewtonsoftJson?

[@BasyrasCZ]

"Do make it" team here.

[@KvapuJanjalia]

If this _discontinues_ Mediator Cargo Cult, I will be happy. EDIT: I had to use an euphemism and incorrect library name so that KZbin would not delete my comment.

[@dennycrane2938]

Honestly, I'm glad they're finally doing it and I hope they do well enough that those OSS projecs are in jeopardy. Not because it's something I wish upon those projects (I use them) but because the problem domain is so "base" at this point that it's simply something that should be offered by .NET as a first class citizen. I agree though that the key is making it something that can easily built on top of.

[@garcipat]

The minimal api is a bad idea since i think most of the apps are still not using minimal api wven microsoft is pushing it so much. I hope there will be a solution where you dont have to cedine constants to prevent magic strings everywhere.

[@ivcbusinesssystems6613]

Microsoft has been doing eventing for many years, just not widly adopted. *The question is why were any of these libraries ever created? They all started out not to make money.* The goal was to help developers adopt a superior development pattern. Over time they did need money! *However, Microsoft baking this into the system, achieves the original goal! They should still be viable, MS always leaves openings!*

[@shatilomaxim8032]

We're going to mostly say goodbye to Web Api in near future?

[@srivathsaharishvenk]

Fun fact, Mediatr is not a messaging library

[@nickchapsas]

Fun fact, MediatR tag line is "In-process messaging with no dependencies."

[@THE_NE0]

Please @microsoft make it 🙏

[@marcotroster8247]

This is such a basic feature. Shouldn't need 3rd party tools to process a message bus. It's like there's still no YAML parser in C#. So many obvious things are missing in the standard API, but they keep introducing new language syntax to make "modern" C# look like Python. Not so sure what they're doing in Redmond 🤔

[@KieranDevvs]

I cant believe people are actually whining about this. Microsoft builds an open source alternative to other software vendors, and vendors are upset because they're no longer as popular? That's how this has always worked. Are you trying to say that a company cant build a product because it would hurt yours? Don't be ridiculous, compete or collapse, this isn't the USSR.

[@igorsolomatov4743]

.Net team got NIH syndrome

[@kallebysantos5167]

That's awesome. Sometimes we don't want to couple a third party library or just learn it for a specific use case. I'm my last project I had to use a very simple in memory message bus, so instead of coupling my project in some MediatR lib I made a very basic implementation on top of the built-in Channels, and works very well. I wrote a simple interface for message handlers and combine it with a Background Service and Dependency injection. And it took like 30 lines of code and a little time studying the built-in channel class. I always prefer go to Microsoft first instead of coupling my project with extenal libraries. That's why I like the .net ecosystem, they always come with patterns to follow. Differently from Js where you have to learn a new framework every week.

[@dawizze1]

Microsoft was brought back from the dead by opensource. They not only embraced it but used it to bring them back to the modern era. So much so they started to invest in open source heavily. I think now that they are caught up with the industry they are back tracking and taking ownership of stuff and doing stuff their own way. This is a perfect example of it. I think this behavior will push open source development for Microsoft away. I get why they did it but this move seems a bit too different then the others. Not sure I like it but we'll see how it plays out I guess.

[@user-nw7jo5xw9x]

xUnit still win over MSTest... the best would always remain anyway, the more concurrence the better for us developers

[@romanhrytskiv8845]

It’s all good and well that there are libraries but I would prefer MS to do it and not look for a library. As for the fact that that could kill their business, well, who cares lol, it’s life dudes, wake up.

[@nec135]

“who cares lol” - what an ignorant comment

[@mattbilyeu]

Saw the thumbnail, “No more massaging libraries,” and I’m like, “What weirdo is going into libraries and rubbing the books?” -- misread it as massaging…

[@thomaswoods1365]

I worked at MS for 22 years. It is a bad idea to try and make a living building infrastructure unless you make the goal selling your technology to MS. They have an army of developers. When they choose a strategic path to execute on you are toast! They will just do it and you will end up the loser. I would never try and make a living off a utility that a few guys at MS within 6 months can render obsolete. Bad idea. Stick to vertical solutions or horizontals that you believe they would purchase from you.