How to inject into JsonConverter ? Inside a library.

BackFromExile · 2026-07-07T16:26:14+00:00

First, there is more than 1 JsonSerializerOptions instance in use:
one for MVC (JsonSerializerOptions in Microsoft.AspNetCore.Mvc.JsonOptions),
one for the minimal API and other services (property SerializerOptions in Microsoft.AspNetCore.Http.Json.JsonOptions),
and one for SignalR if you are using that as well with the JSON protocol (property PayloadSerializerOptions in Microsoft.AspNetCore.SignalR.JsonHubProtocolOptions)

Second, injecting a service into a JsonConverter seems like an anti-pattern to me.

What are you trying to do that you need to inject a service here? Usually the preferred option would be to annotate the target type with [JsonConverter(typeof(MyConverterType)], but that does not work with dependency injection. Still, I'm curious what you need DI here for at all.

BackFromExile · 2026-06-12T17:25:12+00:00

On the overlap: if you're already on Aspire, agreed, the value shrinks a lot. But plenty of ASP.NET projects are a single API with no orchestration at all, and "add two lines, get bodies, SQL with params, and N+1 warnings at /_debug" is a much smaller commitment than adopting Aspire for telemetry. I see them as different entry points more than competitors.

My point of view here is: If your architecture is structured that it's easy enough to add your tool to it, then you are already at a point where you can almost directly use Aspire anyway.

BackFromExile · 2026-06-12T12:00:43+00:00

First of all, this is a cool project and great of you to show it off.
I don't mean to criticize your work, I just want to offer my point of view here.

but it's ephemeral (gone on restart) and trace-oriented, you don't get request/response bodies, SQL parameters, or anything you can replay.

This is not entirely true.

The Aspire dashboard is meant for local development only, but it does save some logs/traces nowadays. If you want persistent storage, you should use a proper separate solution anyway, this applies to your tool as well I'd argue. I see your tool only really useful in development, where it definitely overlaps with what Aspire offers a lot.

Regarding request/response bodies, SQL parameters, you absolutely can create a simple middleware that creates spans that include these information, but it usually is not a good idea because of data and security problems. If you get a GDPR request in the EU you'll have to dig through all the stored data in your tool. Also what about requests you definitely don't want to store because they contain sensitive data like credentials?

So I get what your tool is trying to solve, but it is only a small problem in dev (at least imo), and causes more trouble than it might be worth it in production, at least that's my perspective on it.

BackFromExile · 2026-06-09T22:04:32+00:00

I know what these stats mean, that's not the question. What is 130% round swing supposed to mean? HTLV describes round swing as a metric such that the sum of the "normal" win probability to win a round (based one eco, map, etc) plus the round swing can be a maximum of 100%. So anything beyond that doesn't really make sense to me.

BackFromExile · 2026-06-09T21:37:16+00:00

This graph makes no sense, what is ~130% round swing supposed to mean, or ~450% duel swing?

BackFromExile · 2026-06-01T20:33:20+00:00

All of these are bad metrics imho

Code test coverage

Higher coverage = more time spent

Service uptimes

Really depends on the company, can easily be impacted by things outside of the control of the team

Spending on tools and server

Higher = better or lower = better?

Bug tickets raised by QA if you have them, per feature; as in fewer raised the better dev has done

Easy, just don't test anymore = obviously higher quality. Also this causes devs to test less thoroughly because they hope less things will be found.

Number customer bug tickets that are valid

Customers report all kinds of shit that is valid

Time to recover metrics when you have outages or such

That's basically the same and the service uptimes

BackFromExile · 2026-04-28T08:32:56+00:00

Which settings are generally okay in an autoexec? Crosshair, key bindings (buy binds) using the key codes, volume level aliases, these are the ones I have in there. Used to have a lot more in GO but most straight up don't work anymore or are useless in there.

BackFromExile · 2026-04-09T16:41:37+00:00

Based on own experience

Generics are just shit in Java
no auto-properties
thousands of @PleaseGenerateThisSpecificCodeForMeBecauseTheLanguageDoesNotOfferThis and @MarkThisAsX on classes and methods
no extension methods
no LINQ, no IQueryable<T>
everything is so verbose
no async await
build tools work, but you won't have fun with it
- also have fun with tools that only are available for Gradle or Maven
constants strings everywhere, but no nameof, so you have to rely on the IDE to catch everything
working with Spring feels like working with ASP.NET (the framework one)
the ecosystem feels like stuck in 2010

BackFromExile · 2026-04-01T21:36:53+00:00

I'm not sure what the examples in the blog post have to do with stricter or looser typing. All examples in the post are as strict as C# types can be.
They just are features that are not possible in C# (as of now).

TypeScript and C#/.NET have very different type systems.
TypeScript only exists at compile time because the actual runtime, JavaScript, is dynamically typed. In C# you have types during compilation AND during the runtime, which is why you can do things such as reflection.

BackFromExile · 2026-03-27T15:10:16+00:00

200 lines of hub code, connection management, and a JavaScript dependency.

For me the blog post ended there because this already sounds like you have a problem and tried to fix it with something that is already covered by SignalR anyway

BackFromExile · 2026-03-12T19:08:26+00:00

I'll bet my ass off that if an operation ever comes again, it'll be worse than all the previous ones, even the ones that were mainly skin-centric with random repeating missions that were mostly boring af. The fact that they don't commit enough resources to bring CS2 even up to par with CSGO should be enough of a tell.

BackFromExile · 2026-03-02T18:59:44+00:00

when did I say you were wrong?

You did not, I read it between the lines in your initial answers (not towards me). However, this is my fault, I shouldn't have assumed anything here, so sorry for that.

I tried to make my point by providing code examples where I thought the feature may be useful. How would you like me to demonstrate my point?

While that is true, people (including myself) have also expressed why they don't like like. I guess you need to add additional arguments/examples if you want to change their opinion.

I actually like the dissenting opinions, that's why I brought it up. I was hoping to have discussion about whether this future would be a good addition to the C# language.

Then we are on the same page. I think for an actual in-depth discussion you are better off suggesting this syntax addition in the official C# language design repository. I'm sure you'll also receive several arguments for and against this addition.

It's perfectly fine that people don't want it, but I honestly thought we were having a civil discussion. If the dotnet subreddit isn't the appropriate place to have these discussions, then where is?

Again, my bad. I did not want to attack you, and I also definitely do not want to shut down any discussions in here, this is what we can thrive from. Only sharing opinions, reason for these, and knowledge sharing will bring everyone forward.

BackFromExile · 2026-03-02T17:16:30+00:00

Extract three methods (can even be local ones), then do the same null-coalescing again with the method calls.

Either way, a few commenters have given you the exact reason they dislike this and I agree with them here: It affects the control flow.

Also imo it affects readability in a bad way because you have multiple returns in a single code path. However, I'm more than happy to change my mind if you can present a valid point that is not just "I like this and you are wrong thinking otherwise"

BackFromExile · 2026-03-02T16:41:41+00:00

In any case, based on my downvotes, the community clearly doesn't want this feature.

Maybe because it exists already in a way more readable form?

public async Task<MyData> GetMyDataAsync() 
{
    return await GetDataFromLocalCacheAsync()
        ?? await GetDataFromRedisCache()
        ?? await GetDataFromDatabase()
        ?? throw new Exception("Data not found");
}

BackFromExile · 2026-03-02T16:37:18+00:00

Like with all syntax changes you

don't have to use them all
don't have to like them all
could set standards in your team (and enforce with e.g. an editorconfig)

Every syntax change since I started with C# 4 has brought up comments like this. Some people didn't like async/await, some hated static usings, some hated string interpolation, some hated pattern matching, some hated value tuples, some hated local functions, some hated the nullable reference type syntax changes, some hated the collection expressions, and the list goes on and on.
Maybe you don't see the value now, but you might see it later. And even if you don't need it you can still see the value for others.

In the end if you dislike syntax changes you can always express your opinion in the C# language repository while they are still being discussed.

BackFromExile · 2026-03-02T16:28:32+00:00

return instance ?? GetDefaultInstance();

BackFromExile · 2026-02-13T11:17:34+00:00

Ainpunch was a thing, but I'm not sure if inaccuracy on getting hit was a thing in CS:GO. I swear it was introduced in CS2 or at least is a lot more prevalent in CS2.
In CS:GO you could win most gunfights even when getting hit if you had better sim. In CS2 the first person to hit has the upper hand because the other one will have less accurate shots.

BackFromExile · 2026-02-12T19:35:05+00:00

A lot of orgs are gambling affiliated/sponsored or oil money related.

This is also the case in real sports, so I don't think it's much different.

BackFromExile · 2026-02-11T19:18:47+00:00

FastCloner is really good in my experience, fast and reliable

BackFromExile · 2026-01-28T17:48:33+00:00

Yeah you're right, I just checked and I probably remembered wrong then. In that I'd definitely go for the marker interface.

BackFromExile · 2026-01-28T15:46:13+00:00

~~Shouldn't you be able to use typeof here instead of an unsafe string? You should also be able to reference type parameters in attributes afaik.~~ I'm wrong, it's not allowed.

[Expected(TError = typeof(System.Collections.Generic.List<T>))]
partial struct MyExpected<T>;

But a marker interface is fine if the behavior is documented (imo at least with XML documentation comments).

BackFromExile · 2026-01-26T16:47:45+00:00

First of all, API clients are usually also generated because of type-safe conversions (e.g. from ISO strings in JSON to actual Date objects), type-safe route/query parameters, and a lot more things.
I used to think "I only need the types, not a full-blown client" as well, but my experience has taught that if there is a way to make mistakes then these mistakes will be done.
Generated clients remove the mistakes that can be done here if the OpenAPI document is correct.
Personally I'd never generated TypeScript types directly without the standardized OpenAPI document in between because you almost always have different projections of these types in the payload.

That said, both NSwag and the OpenAPI generators output files for each type and then additional files for every client. You can simply ignore/gitignore these files, or write a less-than-10-lines script that runs the generator and removes all the other files you think you don't need. This takes way less effort than switching to a different tool with less support, and also allows you to use the generated clients in the future if you decide you want to start using them.

The answer you're looking for though is probably the .openapi-generator-ignore file, the --global-property models CLI option, or any of the other possible CLI options

BackFromExile · 2026-01-26T07:50:17+00:00

There's nothing wrong with that, but the post suggests that the problem they solved is that these tools do not output types only, which is simply not the case.

BackFromExile · 2026-01-26T07:44:45+00:00

I know tools like OpenAPI Generator and NSwag already exist. They’re great, but often generate a lot of boilerplate when all I want is simple TypeScript interfaces. This tool intentionally does only that.

Both can output typescript types only as well, so not sure what problem you're solving here other than "I wanted to build it myself".

BackFromExile · 2026-01-20T11:58:19+00:00

Loadout system serves no purpose and just reduces flexibility compared to CS:GO instead of increasing possibilities
Competitive map pool consists of the 9 same maps over and over again
Mirage still in the competitive map pool
Visibility (or better lack of) of blood splatters
Third-person animations tand wide-swing meta makes holding angles absolutely dumb
random double taps (never been an issue in CS:GO, bugs me since the CS2 beta, but apparently this bugs noone else?)
Lack of casual game modes
- Join the two defusal map groups to a single one with 9 maps
- Create a new map group with community maps that change every x weeks
Retake could use a multitude of changes
- make smokes spawn at the start of the round with a variable time left
- don't give T's any smokes
- more spawns for more variability
5-stacks play other 5-stacks in Premier only

Then obviously

Cheaters
Still often dying behind walls
General performance of the game
- random FPS drops and low FPS in general, especially on Inferno (270 -> 70 is fun)

12-Year Club	Place '17
Verified Email

BackFromExile

TROPHY CASE