Swagger is Going Away in .NET 9!

[@rozhdov]

Microsoft libraries are of high quality and stability, so as a developer I welcome them. But I would prefer if Microsoft looked less to replace great free libraries, and looked more on typically paid products, like PDF and text document creation and conversion tool.

[@ihnatklimchuk1018]

Looking for: - Azure docker emulator, to stop creating Service Bus with my name for local development. - Azure alternative for AWS CDK is done? - Replacement for paid nuger packages are all done already? And many more areas that really need attention, but nuh. Yet another open and free library has to be copy-pasted under a different name.

[@JollyGiant19]

@@panbotukHuh?

[@SpaceShot]

I think as said in the video it looks like the team was concerned they were including an unmaintained project in templates. That also invites criticism. The reality is it's still just a template. You can add swashbuckle right back or use something else. Sure the templates make a huge impression on the developers, but in the end it's your code.

[@Zutraxi]

Paid packages are maintained at least. We have seen so many supply chain attacks popping up lately. Was it x something, that barely missed going into Linux core. But was found out by one curious Ms employee that noticed it took a few Ms longer than usual. This is a very serious threat, also look at what moq did. I welcome this change. Less dubious dependencies means more certified companies get to use the features.

[@CreativeB34ST]

@@SpaceShot People tend to run with whatever the templates come. Especially beginner devs don't know any better as they don't know what's out there. Senior devs will more rapidly swap packages in and out.

[@geniustrash]

Nick: Get ready to be blinded Also nick: gives us 5 microseconds to prepare

[@eziitis8]

Any more latency we're gonna have to bring out the span.

[@slowjocrow6451]

Hello everybody I'm naked and get ready to be blinded

[@KieranFoot]

The project is indeed active, raised an issue a couple of weeks ago and got a response from the dev within a couple of hours.

[@erynmacdonald]

It's essentially the same functionality, just a separation of concern that sits better with MS, i.e. you can use any UI generator you want and that's as far as core responsibility lies. Thanks for the video

[@fusedqyou]

I never understood why it was part of .NET anyway. If I want API documentation I should just have to download and set it up like any other library. Making it a build in library and providing it like it's something special is weird.

[@sunefred]

I had the same though back when .NET5 was released.

[@RandallEike]

But the thing is all APIs should have documentation, it would be a special case to not want it.

[@Elyrinnnn]

@@RandallEike the OpenAPI json should be industry standard - yes. But which HTML renderer you use should be up to you.

[@fusedqyou]

@@RandallEike OpenAPI is a perfect solution for that. I don't see what Swagger contributes specifically that makes it part of the pipeline.

[@nec135]

Swashbuckle has multiple components, they're literally called out in the issue that Nick is showing on screen for a 1/3 of the video. The UI generation is JUST ONE one (albeit visible) of those components. Are you complaining that the mentioned swashbuckle packages were added to the web api templates? What do you mean by "making it a built in library" or "part of .NET"? It's a package like every other .net package out there, but it was added to the web TEMPLATE.

[@MagicNumberArg]

For something this fundamental, API metadata - deffinitely it should be built into the web framework itself. Outsourcing the UI is a perfect border.

[@vyteniskajackas7579]

I think the open source projects could just provide UI. You download a package, let's say swagger UI, add that as you do jow with app.AddSwaggerUI and bam, you have the current UI, but it would use the new Microsoft created OpenApi stuff. I think that's a decent compromise

[@winchester2581]

Honestly, Scalar feels like a fresh air, so I would use an approach shown in the video

[@allinvanguard]

Sounds like a good decision. I feel like the UI wasn't really useful. The openapi is usually just generated and then goes straight into a generator or into Postman, because let's be honest, Swagger "try out" was always hard to get right with jwt tokens etc

[@MaQy]

I use the UI a lot. It integrates fine with OpenID, specifically with Microsoft Entra (former Azure AD), so the authentication part is just clicking a button.

[@the-niker]

As a dev that's working with 3rd party APIs all the time I like the simplicity of typing /swagger and getting the complete documentation, examples and ability to do a quick and dirty test without any other tools. For a well commented API you don't really need actual docs to understand it and use it and swagger is frictionless and beter than mucking about in intellisense of a generated client or firing up yet another app like Insomnia.

[@kooraiber]

UI is plenty useful. Mostly to see what kinds of requests and responses are valid.

[@CabbageYe]

Wym it's really easy to get it to work with jwt

[@allinvanguard]

@@CabbageYe Once you got a token, it's easy. But other api client tools also offer built in ways to get to the token in the first place, which always feels more useful since the token is short lived usually

[@gearsiborg]

This is very scarry. As a developer's point of view, you don't want to go back and forth to do what you're doing. We simply need to start a new project and BANG. Swagger had everything in place for you. This would be insane to do everything manually to have 10% of what Swagger offered.

[@tridy7893]

is there a way to explicitly set `info. title` and `info. version`?

[@zzzzz3649]

but what about nswag code generator? is there already a way to generate typescript APIs that are reflecting .NET API calls?

[@xmesaj2]

NSwag is broken since v14 & net8. I think Kiota could have more attention as well, looks nice. Scalar on the other hand will be probably most common replacement, seems very simple and easy to replace swashbuckle.

[@jameshancock]

You can also just put in the static library for the UI if you want. Also NSwag is deeply behind as well and doesn't support basic things like enums done properly, generics etc. so claiming that it isn't being worked on because of this decision is a little dishonest since these tickets have been open for years.

[@JoeIrizarry88]

It is as much a logical discussion as an emotional discussion. Both perspectives are valid. For me, at the end of the day as long as it’s done thoughtfully and over time proves to add more value to the ecosystem, language, and dotnet as a whole, it is ok. Progress requires change, and change is always hard and uncomfortable. I also can’t imagine Microsoft wants to take on a bunch of additional code and maintenance responsibilities and then kill their own ecosystem. So I’m sure they are indeed doing it thoughtfully.

[@juliendebache8330]

I would hope that Microsoft reached out to the Swashbuckle team to see if they could move their project under the umbrella of the .NET Foundation before developing their own. At least that would have been a decent thing to do. If they did and somehow they couldn't make it work, assuming they really tried, then I don't see this move as a problem. Generating Open API specs for your API is almost a must-have, and, by doing this, Microsoft ensures that you will almost certainly always have this capability, without taking the risk of having a dependency on a third party. The Swashbuckle team might have the best intentions, but sh*** out of their control happens, license terms change, people just disappear for a wide variety of reasons, etc...

[@SeanWilliams2112]

Does the OpenApi package support extension, like Swashbuckle filters? Do you know about YAML output?

[@PhantomPhobos]

I wonder why there is no mention of AsyncApi, I mean we are long past the days of HTTP 1, REST. Streaming messaging APIs should be a common thing, what need is there to change swagger if not for AsyncApi?

[@queenstownswords]

IMO, you need to think of ANY changes as to how it might fit in MS's AI strategy. Are they setting up for co-pilot to automatically create integration tests?.. maybe...

[@Punkologist]

I feel like this will be like how we (my company) used to use autofac and now Microsoft's own DI is so good there is no need for it.

[@alexbarac]

Sad to hear. Won't give up on using Swagger, the interface is much more user friendly, everything is on one page and it's also easy to call requests sequentially. I'd prefer if Microsoft acquired Swagger in one way or another and improve on it instead of giving it up.

[@mikejg101]

This seems like the right direction for Microsoft and dotnet. We should get better documentation now. I support it and look forward to seeing what the community can do with the new way of doing things.

[@SanKum7]

They can implement function to Mege two System.Text JsonObject, which was available in Newtonsoft instead. Also alternative for Merging , Please let me know? Thanks

[@vorontsovru270895]

Regarding OpenAPI and the recently sensational Microsoft proposal regarding working with events, I am more for than against. Because in the microservice architecture, these are necessary things that are now implemented in a million different ways. I personally would like more unification, so that there is one industry standard (for each of the areas), and not 50 different options. In addition, given that Microsoft is now actively promoting NativeAOT, which, for example, does not support Swagger right now, and the probability of its support, in my opinion, is not so great, I think Microsoft is going in the right direction. IMHO

[@blackpaw29]

I'm guessing there will be some way to include generating a client side library as part of the build process? Currently I do this using swagger command line.

[@devpitch]

Swagger has some minor issues like client modal generation and security, but it's still a good tool. Now it depends on how well of a job MS does trying to replace it.

[@TheNeozas]

I don't see a problem in "competion" or maybe I did not get a point - Microsoft has maintained the most popular swagger lib, now they don't, but have (maybe) the lib built in. Othe third party libs existed previously in the same situation almost With DI libs it's other topic - there was no Microsoft realisation of the pattern in-built (how ever they did have public interfaces for it from the 4.x versions, I believe) and they just added (or made public) there version witch happened to be very fast and very convenient - this I can say as a long time user of third party DI conteiners, I have only once used better code-generated solution for DI (using Fody, I believe) that can compete or be even faster than Microsoft one

[@rreiter]

Maybe they're also afraid of liability surrounding something they don't control, say for an incremental long term attack along the lines of what happened in ssh. If you include the package yourself, it's your problem.

[@youtube-is-cringe]

getting microsoft support means better documentation and all that, totally like this thing

[@PatrickMageez]

Only been using something like that for local development. In a large org, well at least my one, we build the YAML Documents ourselves and they usually get hosted by an API Platform which also may configure proxies, traffic behaviour etc, an example of this is Googles APIGEE X solution. However, I do like the idea of having a .NET API generated Spec and have it compared against our YAML Documents Pipeline (because we build shared yaml components for Error models, and Common filter components, which is where the power of building the OpenAPI YAML Specs in tooling specific to building APIs is preferred. You can handle and better create those documents with a more rich experience. But would like to still compare endpoints, HTTP Response codes with the generated .NET one maybe as a sanity check. Plus, the company I work for has teams who work in different languages, not a polyglot company but we share Spec Pipelines to Publish the OpenAPI documents... so we need to be language agnostic in some places to maintain consistency across APIs that may be developed in go, .NET, java

[@fifty-plus]

MSFT should stick to publishing the specification from the API host easy and let others create tooling around that and a UI that sits on it. Most of the existing tooling already supports importing a spec file.

[@Meryovi]

My thoughts exactly. Swagger (or any other OpenApi UI Provider) can still handle the presentation based on the spec file.

[@codecomposer88]

Maybe I'd misunderstood the video, but that's excatly what is going to happen, isn't it?

[@fifty-plus]

Let's hope so. If they don't stay in their own lane they're going to annoy some more OSS devs.

[@uxmaanali2711]

Can we use this json file directly to be imported in some applications like postman or rest client etc ? If we can do that so that's will be gona be lot of help to test api's.

[@AlFasGD]

Swagger was just the de facto package for that purpose. It wasn't anything great, and definitely not related to Microsoft. All Microsoft did was help users that were already defaulting to Swagger default to it, while they would plan into adding their own solution for that.

[@codecomposer88]

A very good choice. The framework should indeed be able to produce the metadata but should not come with a third party UI of the box. Official .NET templates shouldn't have third party dependencies at all.

[@EricOnYouTube]

I am relatively new to your channel. Did you say you were making this code available? If so, where would I find it? Thanks!!! :)

[@emmanuelgenga7421]

It's in the description of the post under the Get source code option.

[@EricOnYouTube]

@@emmanuelgenga7421 thank you for this. I thought that was a typo... I was looking for a github link. lol

[@Thorarin]

Swagger-UI is separate from Swashbuckle, no? You should be able to use it, as long as you can provide it an OpenAPI JSON file, which Microsoft will support generating.

[@dennycrane2938]

does anyone happen to know if this new stuff can give me the spec as a file as part of a build process?

[@stefanivovic]

what do you think about video explaining how to generate client side (angular) request and response models and api calls

[@klex3905]

It makes sense for Microsoft, they are foreseeing changes to their API structures, swagger wasn't being supported. So they roll their own. If I understand correctly their offer will be open source too.. so swagger will absolutely survive as there are enough "anti Microsoft because Microsoft" people. Also if swagger are back up. It's good for Microsoft competition.

[@techman6713]

In my humble opinion, it's not a bad idea for Microsoft to implement its own solution, and I believe it's also OK to leave the choice to developers. It would be great if future versions of IDEs included an "Add OpenAPI implementation" option, allowing us to choose implementation from existing options.

[@RandallEike]

Microsoft should implement replacements for key free libraries. They often do them very well, fix problems with existing projects, and provide a better and more supported solution in the long run. While I feel bad for those library developers, they can know that they did something that turned out to be important. They can be relieved of their burden of maintenance and go off an do something new.

[@cipherw0lf]

To be honest the first time I heard of what-buckle(??!) - it just felt out of place for a new project. Open-source projects have their risks as well as we discovered recently. Barebones is the way to go for new built-in projects... IMHO

[@HeathInHeath]

Swagger has had a nice run. I wish that MS had chosen to include a default viewer in the new template.

[@magicspider8]

Nick: "You can have a blind mode", Me: "Lost my eyesight so now it turn this into a podcast ". lol

[@Soliber]

I’m in the camp of writing the openapi spec yourself. I found that, once you get serious about openapi and want to produce comprehensive docs with markup, images, etc, the code you have to write to get Swashbuckle to generate the corresponding openapi quickly explodes, if you can get there at all. In my opinion things likes Swashbuckle are only viable if nobody really cares about the docs.

[@marcotroster8247]

Interesting take. What's missing that you needed to add manually?

[@QuantumMechanic343]

I’m not OP, but I like to write the spec myself and use it for code generation.

[@andersborum9267]

Was waiting for Microsoft to take over the OpenAPI generation and leave the UI side to the community. It's a natural step and one that should sit nicely with community.

[@dfcolem]

I would like to hear your thoughts on API first vs API generated and how there could be a happy middle ground. I see the advantages to both.

[@ml_serenity]

The less libraries - the better. Going from project to project having to learn all the different libraries that essentially doing the same thing can be really overwhelming. Modern programmers are jacks of all trades.

[@d34d10ck]

I'm already dreading having to rewrite all my custom swashbuckle filters, of which I have quite a few.

[@robadobdob]

If you work in an environment where every package needs to be scrutinised, it’s a lot easier to get an out-of-the-box Microsoft package approved.

[@blackpaw29]

Scalar looked quite nice - can it integrate OAuth2 authentication, such as Azure B2C?

[@MatthijsWagemakers]

Not yet but they are working on it

[@aleksandardevic4426]

Hi, thanks for the content, it is beneficial. Please can you cover in one of the next videos how now to set up versioning?

[@kaiserbergin]

They really need to consider their original desire to have a frictionless developer experience for new devs. If it releases without a default front end to try the API out, this feels like a huge misstep.

[@RubenALopes]

Honestly I could see this coming from the moment I saw an update to visual studio that incorporated endpoint testing… I guess it was just a matter of time

[@q1337]

It's sad but also it makes sense. It allows for more modularity. But I'd rather it didn't change since I think swagger is sufficient.

[@abouttimebrewing3215]

I've always used Postman and I can't imagine developing an API without it.

[@exec.producer2566]

I like the .NET dev, but can they please make Authorization endpoints easier. It’s a total nightmare having a .NET Web Api then using something like NextJS with the app router on the frontend and handling JWTs back and forth. MSAL doesn’t have the best documentation.

[@kRySt4LGaMeR]

When swashbuckle was abandoned we found some problems and couldn't get it fixed. The issue is that we HAD to have a swagger UI (internal requirement) but the issue raised was a blocker. The end result was to ditch it, to be honest I'd prefer to have first party support Microsoft than any thrid-party library.

[@fatlumlatifi2897]

Please keep making content on the relationship of .NET with its community. It's critical that the .NET team fundamentally changes the way it interacts with well established libraries, but they have to start with their own internal teams. Worst example is the Azure team that does not contribute a single useful library to a "cloud-native" .NET ecosystem while fully contaminating an amazing open source framework with an SDK that makes .NET seem like a Customer Acquisition Platform and us .NET Developers to be sales agents of Microsoft's rented machines.

[@ChrisonSimtian]

I think its good to have first class citizen experience. Worked out pretty well for json so far (and many other things) I mean there are smart ways around those integrations by providing standardised interfaces (#ilogger) that allow a 3rd party ecosystem to co-exist with a bare-minimum built in solution maintained by microsoft. Hence why there is no need for a MS-swagger-UI, who ever needs/wants this can use swagger ui or any of the other libs out there but having native open api support in .Net is the right step forward 🙂

[@lyrion0815]

Where are all the DI frameworks? Well, Autofac is still lightyears ahead.

[@Sergio_Loureiro]

Source?

[@emerynoel567]

Personally I've never really liked swagger, but that aside, I'm fine with MS bringing things in house. Ideally, the MS version will be super-simple and feature-lite, maybe not even have a UI, which will force you to install the tool of your choice if you want one. If you like swagger, then go for it! EDIT: I was also happy when they excised newtonsoft.

I really dislike Swagger's UI and UX. I did some research in the past to find an alternative. BUT Scalar is not an alternative. Scalar is not free. MS definitely should stop us from pushing paid tools. This is a deal breaker for small companies like software houses or startups.

[@DavidPipes]

I hated this at first but then thought about all the problems auto binding gave me in the past. It's going to be a learning experience but I think is the right choice by MS. I hated nothing more than writing customer filter and attributes to support the api explorer.

[@ApacheGamingUK]

I have no problem with Microsoft creating their own in-house libraries. And, as for what the author's of alternative libraries should do? They should write, and release high-quality alternative libraries. Just as they should be doing now.

[@marcotroster8247]

Can't compete with Microsoft though if their in-house package is any good.

[@ApacheGamingUK]

@@marcotroster8247Then stop treating it as a competition. Just produce damn good software... as they should be doing anyway.

[@SeymourRu]

Swagger is some kind of non-official standard, so, I think that in first place, you should respect it and then, if you are trying to catch it up, you should provide at least the same functionality. Untill then, no need to break something that already done and works just fine

[@codecomposer88]

Nothing is going to break. You can still use Swagger as much as you want.

[@SeymourRu]

@@codecomposer88 Sorry, if I have to make additional effort to achieve already existing features, then this is degradation anyway.

[@codecomposer88]

@@SeymourRu Nah, you only think that way because you like Swagger. As of now you'll have to do extra work to get rid of it. It is wrong on so many levels that an official framework template depends on a random third party library (that could be abandonded at any given time). The correct solution would be for you to set up your own templates with your favorite go-to libraries.

[@SeymourRu]

​@@codecomposer88 >because you like Swagger Well, why should I not? It provides required functionality without additional fuss, so, I see nothing wrong with it here. >It is wrong on so many levels that an official framework template depends on a random third party library This is not really important, unless the source code of framework becomes closed. Oh, wait...it was once already. I think you know, what happened next >that could be abandonded at any given time Anything can be abandonded at any time, this does not matter at all. Just count how many times Google\MS\whatever company abandoned something that was `official` and `original`. If you will check my initial comment, may be you will catch up an idea that before removing anything it is always expected thar something equivalent in return will be given, not only provision of basic stuff. Way more better idea is to do some kind of customization process during project initial creature. May be just add one another template with pre-configured swagger - it is still much better than just remove something good. Then, one who does not need it - will not get it, one who require it - will not spend time for this preparation stuff. Ofc you can not customize everything, but some things could be just like this.

[@fatihcihanhizlikan1427]

Where are the built-in pdf, image, video file manipulation libraries Microsoft provides? All they do is going after free industry standard libraries.

[@mihailmojsoski4202]

PDFs, images and video files are hard and subjective.

[@fatihcihanhizlikan1427]

@@mihailmojsoski4202 Which means they would benefit even more from abstraction. 😄

[@ironsm4sh]

Swagger is one of the features I always removed because I, and many other suers, do not need it. There are plenty of (subjective) superious solutions to test an HTTP api.

[@StefanHanrath]

I dont like the model where we generate the spec from the code, feels like the spec should come first, then generate plumbing to back it, like we do for client code.

[@NickSteffen]

Swagger isn’t a design specification it’s an as built document for your api consumers. It doesn’t stop you from writing a spec before coding, it just generates docs for your api consumers from your code… which is honestly more important than writing a spec in the first place as often user documents match specifications but not what’s really implemented in an api. Often times specs are written before the true requirements of an application are fully known, when reality disagrees with them, the api is unceremoniously forced to meet reality and diverges from the spec, then often no one goes back and updates the spec, and the api documents that were generated from it are thus faulty. To be honest detailed specs are problematic, usually there are only a few things that are truly critical, after that they often tie your hands preventing good api design that requires the ability to be flexible especially in the initial release (before you have a bunch of api users). You could argue that the spec writer should be a good api designer in the first place, but even in that case, they have much less time to write the spec than the api and they still know less than they will during implementation. Repeatedly iterating on overly detailed spec wastes time. It’s better to stay generic and let a tool like this generate detailed docs.

[@browny99]

If microsoft would not include a lot of things into asp net core we might end up in JavaScript npm dependency hell Nobody is forcing you to use Microsoft’s (built in) packages, but if they are high quality, well supported and work for most usecases I welcome it and it makes it so much simpler to agree as a team on which library to use. I just had to revive a dotnet framework 3 ASP project and with their migration tools it was so easy, I only had to re-do the views in razor and fix some odd issues and that was it. That project was done the „Microsoft“ way with EF etc and most if not all functionality and tests worked without touching a thing.

[@SM-tj4jc]

Oh, no! They removed something so important for the bookworms! Real developers will not even notice this.

[@softwaretechnologyengineering]

The UI looks a lot better. Swagger will eventually become unmaintained and we will have to eventually switch over to this new thing which is a pain in the arse frankly. We will be moving from one thing that was working fine for us to something else that will also hopefully work fine, so really just a bunch of work across a number of APIs for no great benefit.

[@ryankueter9488]

Microsoft supporting a community project like swagger as much as they did was surprising. It's not a terrible idea to encourage the use of alternative options. In the future, many popular projects may become abandonware and may have to be replaced by newer libraries. I'm not saying swagger is abandonware. I'm sure many Rest developers would have a panic attack and would require immediate therapy if that ever happened. But it will inevitably happen, it's just a matter of time. Lol...

[@АндрейЧепкунов-и3н]

I prefer Microsoft focus on smth that has not been covered by 3rd party developers already. This is good. But swashbuckle and nswag are good enough too. It is not a kill-feature. MS just building their own bicycle. May be it will be a better bicycle, but we have already some and this is just another one. How many bicycles do we need?

[@LogicException]

I hope MS will integrate all the features of swagger like automatic import from xml documentation etc.

[@rand0mtv660]

I think Microsoft should provide as much as possible out of the box because then the expectation that things work and are nicely integrated together should be there. It would be great if they hired or funded these developers to assist with these packages because they have a lot of knowledge in those domains. .NET should go more in Laravel's direction. Provide as much useful stuff out of the box to build actual proper modern applications. Also provide actual nice looking UI templates as defaults when starting a web project. This default Bootstrap counter + weather data stuff is useless crap. First impression matters.

[@kyrylovagabond9172]

So, instead of creating new useful libraries (for example mocking library which can mock static methods) Microsoft decided to replace good-working projects and everybody seems to be happy about it in the comment section, right?

[@emerynoel567]

Doesn't seem like everyone likes swagger, to me; this is the first comment that I saw that expressed disappointment. But nothing's stopping you from using it. This decision also gives other devs a chance to shine. Just like swagger doesn't want to compete with MS, other devs don't want to compete with swagger.

[@bhanuchhabra7634]

​@@emerynoel567 this should be the pinned comment for the whole saga. Why ship a dependency that is not used by all. Liked or not liked is another question. So many projects don't outright have a need for swagger UI

[@promant6458]

Why would you want to mock static methods?

[@FelipeV3444]

I have never had the need to mock a static method. In fact, I try to stay away from mocking as much as possible. I see it as a bad practice.

[@rapzid3536]

Swashbuckle wasn't a "good working" project so maybe that's just the difference between an informed and uninformed opinion.

[@vitskr1]

I have no idea why started this NSwag is better maintained thing goin, but it is just stupid. It tooks them months to add .net 8 support after .net8 release. NSwag litterellay has 1700 open issues and 100 PRs noone ever looked at.

[@niwadev]

With the OpenAPI documentation it’ll be easier to integrate it into Azure API Management.

[@mbusokotobe9793]

Nick: You can call this document anything, like SWAGGER Nick: But Don't call it SWAGGER!!! 🤣🤣🤣

[@dharanish.]

It would be great if you could make a video on breaking changes of graph service client upgrading from v4 to v5

[@melnor82]

"We're removing Swagger so that you can choose your own UI for your api".. First thing people will do is add Swagger Nuget Package 😆Thanks for NOT saving us time

[@GGGStalker]

I think it's the time to create something on your own using much smarter ui and the flexibility of Microsoft abilities. I think MS on the great way to the future and it's scalability through the OS community.

[@nyonor7314]

Thank You Nick

[@codeforme8860]

Uhhh I will have to reimplment something that already works and does what I need during the upgraded process for a project with 15 dependent projects!

[@FelipeV3444]

You can just keep using the package. It's actively maintained and all. It's just not part of the official template, you don't have to remove it or stop using it.

[@MRApht]

I think you have misunderstood, you don't have to do anything. Swagger just won't come out of the box in new projects anymore.

[@ВладиславДараган-ш3ф]

I'm totally supporting Microsoft in doing that. 3rd party library can't guarantee any quality or compatibility standards and they prone to abandonment or deprecation. Haters gonna hate LOL

[@mojizze]

This shouldn't be controversial at all. It's welcome change

[@BonBaisers]

Having the OpenAPI definition autogenerated is essential and relying on 3rd parties is a not a long term safe bet.

[@bondarenkodf]

never liked Swagger UI. It's ok for small API, but when you have 100+ endpoints, using it is a huge pain.

[@CodeCraftedNext]

Thank you for this publish

[@PlerbyMcFlerb]

Top Notch job baiting that click

[@EwanDobsonFan]

They did this with Newton, but they just hired him and brought the code into the ecosystem. I am not clear why they are doing it, but now seems we have to do a lot of work to achieve something that’s already done. But overtime they will catch up quickly and I think it’s a good decision in the long run.

[@duramirez]

"do a lot of work" you want to be replaced by AI that can do your job in 5 seconds? stop complaining about having to do just a tiny bit of work, when you risk losing it all together. 😆

[@SingleTrackMind207]

Open vs Closed source is so hard. We're a microsoft shop so I'm biased.

[@lavshyak9640]

all my homies export json from swagger into postman. And swagger seems more convenient for me (backender) to fast test my endpoints

[@Milk-gw1zl]

"We have a dark mode or like a swagger a blind mode"🤣

[@simonegiuliani4913]

They always liked to copy and paste, it's in their culture...

[@aksous9084]

I trust Microsoft and I'm sure we will get facilities more than the swagger made

[@isnotnull]

I won't miss this package :)

[@the-niker]

Looks like in near future putting /swagger after a 3rd party API BaseURL won't always give you all the info you need to interact with it, that sucks. Now everyone will have their own little path convention and we will go back to sending openapi jsons and pdfs with actual documentation over emails. Or more likely scenario - Microsoft removed a nuget package and we just add it back and call it a day.

[@bjmmedeiros13]

The spoken ad is no longer synced with the video I see what you did there 👀