Yaakov

We tend to make breaking changes fairly regularly. 😢

I bet someone is using that as a DB key somewhere... but we did already break the default to render Steam3 instead of Steam2.

Revisiting this. We could just ignore it, or: - Remove `EUniverse` from `SetFromString`, and infer it from the first digit. - Drop the boolean parameter from `Render()`, only render Steam3....

- Why do we need to reconfigure it? - What is a "reasonable" timeout? - Are you trying to _lower_ or _raise_ the timeout? ConnectionTimeout seems to be much lower....

SteamDirectory owns it, and has a SteamConfiguration instance, so I'm tempted to add `SteamConfiguration.WebApiTimeout` so that it's not just some big static that people have to mutate. Any thoughts on...

If we split DLLs we should probably also have a NuGet package per game, at which point we may have to be a little more careful about bincompat.

With an actually-working version of .NET trimming, the trimming solves the problem for apps that make use of trimming. Unfortunately at the moment trimming breaks everything - #1057

We may have to switch to the Google.Protobuf library which isn't reflection-based in order to (a) get this working properly, and (b) be able to run in an AOT environment...

I've never heard of `BufferBlock`. If something exposes a wait handle you can asynchronously wait for it with `ThreadPool. RegisterWaitForSingleObject`. Could we maybe signal an automatically-resetting `EventWaitHandle`? Another option -...

> I also noticed sending packets is done on the main thread, and not the thread created for the socket polling/reading. Pretty sure that's intentional, it's done on whatever thread...