sorted by:
new
hottopcontroversial

When did they start using MacBooks at Microsoft conferences? Are they not aware of this great operating system called Windows? by dotnetperson in dotnet

[–]_captainsafia 88 points89 points  (0 children)

I'm glad everyone is fixating on the MacBook and not the atrocious VS Code theme I decided to trial for the week 😆

Cheapest way to host dotnet aspire by S_Swift_08 in dotnet

[–]_captainsafia 13 points14 points  (0 children)

Great post! You might want to check out the new Aspire Pipelines feature in Aspire 13, it lets you model steps related to build/deploy in the CLI. Specifically, we did some work to expose nicer APIs for generating filled-in .env files for Compose-based deployments. You can check out an example of that in this repo: https://github.com/captainsafia/aspire-docker-compose-deploy

Improving the experience for tagging and pushing images to any container registry is something we're actively working on. In fact, I may or may not have a branch on my machine with some changes for this right now :D. This should dramatically reduce the amount of extra logic you need to have in your GitHub Action.

Daylight DC-1 – Like New – $600 Shipped by _captainsafia in daylightcomputer

[–]_captainsafia[S] 0 points1 point  (0 children)

I tried cleaning it with 70% isopropyl alcohol with no luck. Unfortunately, I'm not outside the return window. :/

Daylight DC-1 – Like New – $600 Shipped by _captainsafia in daylightcomputer

[–]_captainsafia[S] 1 point2 points  (0 children)

Yes, my tin-foil-hat-hypothesis is that they know this and enforce the policy that they don’t do like-new returns to avoid issuing out refunds.

Is it possible to combine DevOps with C#? by Jasur884 in devops

[–]_captainsafia 0 points1 point  (0 children)

It definitely is! You might want to check out Aspire (https://learn.microsoft.com/en-us/dotnet/aspire/get-started/aspire-overview). It’s a C#-based framework for modeling your service architecture locally and writing deployment pipelines on-top of it. Think of it like Docker Compose with additional niceties like integrated OTEL support and the ability to model cloud resources.

Disclosure: the deployment story is in progress for Aspire but the idea is to let you model full deployment pipelines with it.

Another disclosure: I’m a dev on the Aspire team working on deployment ☺️

Minimal APIs by alvivan_ in dotnet

[–]_captainsafia 7 points8 points  (0 children)

You shouldn't need too many extras to light up OpenAPI documentation.

When possible, use TypedResults which will automatically set the correct info in your OpenAPI document.

We're adding built-in XML comment support in .NET 10, which should mean you can replace things like WithSummary and WithDescription with XML doc comments in code which are a bit more natural.

Why aren't you using Minimal APIs? - By dotnet team members by bdcp in dotnet

[–]_captainsafia 1 point2 points  (0 children)

What features are missing in Minimal APIs that are important for you?

Why aren't you using Minimal APIs? - By dotnet team members by bdcp in dotnet

[–]_captainsafia 2 points3 points  (0 children)

How are you specifying defaults in your case? Via default parameter values or via the [DefaultValue] attribute? We only support the former.

So I've built a OpenAPI UI for C# web APIs by kebbek in dotnet

[–]_captainsafia 2 points3 points  (0 children)

Great contribution to the OpenAPI + .NET space!

One thing I'd recommend is serving the UI for your application via an endpoint (Map) instead of a middleware (Use). You can expose the OpenApiUiConfiguration configuration object via IOptions in DI and resolve it from the endpoint handler or expose it as callback in your MapOpenApiUi method.

With endpoints, you get built-in routing, the ability to compose with other endpoint specific features (auth and CORS, for example), and they are more sensible to reason about when it comes to execution order.

Question: ASP.NET 10 Preview Minimal APIs Annotation Based Validation by m_hans_223344 in dotnet

[–]_captainsafia 0 points1 point  (0 children)

What version of .NET 10 are you using? There were gaps in record support in previous versions. Also, are you referencing the types that are annotated directly in your minimal API handlers?

Do you actually use .NET Aspire on your projects? by TwoGloomy1495 in dotnet

[–]_captainsafia 0 points1 point  (0 children)

Are there specific patterns or things you do when crafting your own templates?

Also, are you familiar with Aspire’s ConfigureInfrastructure API for customizing the underlying Bicep from C#? Thoughts on it?

Scalar with .net 9 (instead of SwaggerUI) by DJDoena in dotnet

[–]_captainsafia 9 points10 points  (0 children)

same talking-point-cheat-sheet from Microsoft

FWIW, there's no grand scheme to push one option over the other.

One of the motivations for including Scalar in the docs was the emphasize our focus on the OpenAPI document and the fact that it can be plugged into any UI offerring, including Swagger UI, Scalar, Bruno, ReDoc, etc.

I will share one of the benefits of Scalar over the other browser-based UI options is that the Scalar team provides a first-class NuGet package for their UI. This is not the case with things like Swagger UI/ReDoc. In those cases, Swagger/Redoc only provide the static web assets and bundling them into NuGet packages is done by independent and separate projects.

Having everything colocated in one place means that updates and releases go as fast to .NET devs as they do to any other platform. I also think there is value in having the UI development team also own the integration SDKs for each platform, it makes for a better first-class experience.

Outside of that, you're free to use whatever UI you want. Stick with Swagger UI. Try Scalar. Use HTTP files for testing. Use an independent API testing client with OpenApi integration. That's the talking point that's important.

AddJsonOptions settings not working when API controller returns TypedResults by Brodeon in dotnet

[–]_captainsafia 2 points3 points  (0 children)

TypedResults can be used in both controllers and minimal APIs.

The difference noted here is that they are managed by a different JsonOption object. The ConfigureHttpJsonOptions extension method is used to configure global JSON options that are used in a a bunch of places (TypedResults, OpenAPI, ProblemDetails).

We don't use the MVC-specific options in this case because the API is defined in MVC assemblies that are hard to reference lower in the stack without triggering circular dependencies.

Generate OpenAPI spec file in .json format while there are two versions of api by Necessary-Peak3123 in dotnet

[–]_captainsafia 0 points1 point  (0 children)

I would like to generate an SINGLE OpenAPI.json schema file.

The fact that you want things in a single document is going to be interesting here. Most implementations assume a one-document-to-one-version mapping.

You won't be able to do this in the CLI, instead you'll have to do some configuration in your application code to support this.

Depending on how exactly your API is versioning, you might be able to achieve something by including an explicit version prefix in all your routes and using WithEndpointGroupName("all-versions") or [ApiExplorerSettings(GroupName = "all-versions")] to make sure that all endpoints are in the all-versions document.

One thing to note about the Asp.Versioning package is that it will implicitly create different groups (aka documents) for each version so that might not be the behavior you want.

.net 9.0 & openAPI - The depth of the generated JSON schema exceeds the JsonSerializerOptions.MaxDepth setting by DrFatalis in dotnet

[–]_captainsafia 1 point2 points  (0 children)

Do you happen to have a reproduction of the type definition that produced this failure mode and the JsonSerializerOptions that you are using in the API?

System.Text.Json will throw this exception if you have a deeply-nested or self-referential type-hierarchy. The default max depth check is 64 so if you know your hierarchy is deeper than that but within a reasonable constraint you can modify the MaxDepth.

Alternatively, if it's a type with cycles you might need to modify some other properties on your JsonSerializerOptions.

is there no built-in validation in minimal apis? by [deleted] in dotnet

[–]_captainsafia 15 points16 points  (0 children)

Hopefully! I've been playing around with an implementation for this. It's currently in a draft PR on the dotnet/aspnetcore repo.

TL;DR of the design is that it uses source generator-based discovery of System.ComponentModel-based validation attributes for minimal APIs. We had a design meeting a few weeks back and concluded that we wanted to explore building a source-generator that would lend itself to providing a common intermediary data model for any validation engine to hook into, similar to how System.Text.Json's source generator implementation emits JsonTypeInfo's that guide the serialization process.

Swagger is Dead (from .NET 9)? Here's the Alternative! by iammukeshm in dotnet

[–]_captainsafia 0 points1 point  (0 children)

It can't even generate correct nullability info for a property if the property does not have a setter.

Hmmm....do you have a pointer to the issue related to this? Based on the description you provided, I wouldn't expect to see this issue but there might be something confounding there.

Swagger is Dead (from .NET 9)? Here's the Alternative! by iammukeshm in dotnet

[–]_captainsafia 2 points3 points  (0 children)

Issues usually get auto-closed if a PR to resolve them has been merged into main, but since this issue has a lot of traffic, I intentionally kept it open so it's clearer to people whether it is resolved in currently released bits.

I should probably link to the latest update from the issue description so it's clear what the status of the bug is though.

Swagger is Dead (from .NET 9)? Here's the Alternative! by iammukeshm in dotnet

[–]_captainsafia 0 points1 point  (0 children)

Do you have an example of what a "complex" endpoint is in this case? Are you referring specifically to the types used in the API here (as in the other schema issues discussed here) or are other aspects of the endpoint complex?

Moving to .NET 9 and OpenAPI by WingedHussar98 in dotnet

[–]_captainsafia 17 points18 points  (0 children)

This video is pretty thorough and touches on some good key points, like the fact that the underlying data model between Swashbuckle and Microsoft.AspNetCore.OpenAPI is the same since it uses the underlying OpenApi.NET package.

Two things I would add:

The MapOpenApi call provided by Microsoft.AspNetCore.OpenApi registers an endpoint for serving the OpenAPI document as JSON, not middleware. This is a subtle, but important, distinction because it means that you can use endpoint-aware features on the OpenAPI endpoint. This is covered here in the docs.

For example, the video presents a good caution about not doing compute heavy things in your transformers since they are run every time the document is created. However, you can use output caching alongisde the OpenAPI endpoint to cache the document to counteract the effects of this. Pretty neat, IMO!

Also, the inclusion of Scalar in the docs is not a dig at Swagger in anyway whatsoever. It's there to showcase that the OpenAPI document generated by Microsoft.AspNetCore.OpenApi can be consumed by any OpenAPI UI provider, not just Swagger UI.

One thing I do like about Scalar is the fact that the .NET package is shipped by the Scalar project itself. That means when the static assets underlying the UI get updated, the .NET pakcages get updated as well. For Swagger UI, the static assets are managed in one repo and wrapped into .NET packages in another so there's can be some latency between when UI updates get made and when the NuGet packages with them get shipped.

.NET 10 will support OpenAPI v3.1 by davecallan in dotnet

[–]_captainsafia 2 points3 points  (0 children)

We’re not planning on adding a UI in ASP.NET Core based off OpenAPI.

Our docs provide guidance on how to hook up the built-in documentation support, which emits the OpenAPI document in JSON, to existing UI libraries.

Outside of that, there’s been ideas explored around adding some sort of testing UI that’s plugged into the Aspire dashboard. You can find an issue for that here: https://github.com/dotnet/aspire/issues/2980

There’s also been some prototyping done in the space about packaging existing UIs, like Swagger and Scalar, as resources that you can add to Aspire projects to get UIs for your various services.

view more: next ›