* Good start
* Misc
* Make ApiAuthenticationMiddleware use new json
* Remove first newtonsoft dependency
* Pull latest ASFB json enhancements
* Start reimplementing newtonsoft!
* One thing at a time
* Keep doing all kind of breaking changes which need to be tested later
* Add back ShouldSerialize() support
* Misc
* Eradicate remaining parts of newtonsoft
* WIP
* Workaround STJ stupidity in regards to derived types
STJ can't serialize derived type properties by default, so we'll use another approach in our serializable file function
* Make CI happy
* Bunch of further fixes
* Fix AddFreeLicense() after rewrite
* Add full support for JsonDisallowNullAttribute
* Optimize our json utilities even further
* Misc
* Add support for fields in disallow null
* Misc optimization
* Fix deserialization of GlobalCache in STD
* Fix non-public [JsonExtensionData]
* Fix IM missing method exception, correct db storage helpers
* Fix saving into generic databases
Thanks STJ
* Make Save() function abstract to force inheritors to implement it properly
* Correct ShouldSerializeAdditionalProperties to be a method
* Misc cleanup
* Code review
* Allow JSON comments in configs, among other
* Allow trailing commas in configs
Users very often add them accidentally, no reason to throw on them
* Fix confirmation ID
Probably needs further fixes, will need to check later
* Correct confirmations deserialization
* Use JsonNumberHandling
* Misc
* Misc
* [JsonDisallowNull] corrections
* Forbid [JsonDisallowNull] on non-nullable structs
* Not really but okay
* Add and use ToJson() helpers
* Misc
* Misc
Okay, I wish we had uncovered it earlier as part of V5.2 but it has bitten us in the back just now, so I'm addressing it as part of monthly cycle instead.
Previously used void methods did not allow async operations in plugins in a "nice way". If plugin didn't require synchronization with the ASF and just minded its own business, it wasn't half bad as it could use async void signature. However, if plugin by any chance had to do something BEFORE ASF continued with the rest of the logic, it had to explicitly leave non-async void signature and call its async-capable stuff in synchronous manner (usually with Wait() or .Result), which is vastly suboptimal.
This was visible even in our STD plugin, which previously had (and still has) GlobalCache initialization in OnASFInit(). If that cache initialization took a bit longer time, STD would hit InvalidOperationException() in OnLicenseList() callback as global cache didn't load yet while we were already long past OnASFInit().
Therefore, I've decided to make a breaking change for a very good reason - all previous methods were converted to tasks, which allows from plugin to do one of three things:
- If plugin is async and requires synchronization (like STD), it can declare itself as async await, and do its awaits as-needed, and ASF will wait for those.
- If plugin is truly synchronous (and not just a synchronous signature with awful Wait() or .Result, see above), it can simply return Task.CompletedTask and has exactly the same logic.
- Finally, if plugin calls some async stuff but doesn't need ASF synchronization, it can "offload" itself from it by calling e.g. ASF's Utilities.InBackground() with whole logic, while returning Task.CompletedTask from the main method. This will allow it to effectively do what async void previously did, by just hooking into the process without intention of slowing it down.
All in all I'm confident this approach, while a bit counter-intuitive at first, will result in better compatibility between ASF and the plugins, as if I wanted to fix my STD issue right now without that breaking change, I'd have to actually call .Result on my async global cache loader function, which is utterly stupid if we can fix ASF to do the right thing instead.
This "approach" can be commonly found in some other libs with similar to ASF's event-hook behaviour, e.g. Discord.Net.
You'll sadly need to do some method signature changes in all of your plugins, as the core OnLoaded() was also changed. See the ones I did in SteamTokenDumperPlugin.cs if you need a practical example, and see ExamplePlugin.cs if you need further explanation.
* Implement basic plugin system
* The dawn of new era
* Add plugins warning
* Move more members to PublicAPI
* Open commands for the plugins
* Add IBotHackNewChat
* Run plugin events in parallel
* Use properties in IPlugin
* Hook our custom plugin into CI to ensure it compiles
* Fix dotnet brain damage
* Add IBotsComparer
* Add code documentation
* Add IBotTradeOffer
* Add IBotTradeOffer example
* Add IBotTradeOfferResults
* Final bulletproofing
* Final renaming
