Thrift client library for Microsoft .NET Standard
The library ships as two packages so that non-web projects no longer pull in the ASP.NET Core stack:
ApacheThrift – the core library (protocols, transports, processors and the TSimpleAsyncServer/TThreadPoolAsyncServer servers). It only depends on Microsoft.Extensions.Logging.Abstractions and has no ASP.NET Core dependency.ApacheThrift.AspNetCore – the ASP.NET Core HTTP server middleware (THttpServerTransport, namespace Thrift.Transport.Server). Reference this package in addition to ApacheThrift only when you host Thrift over ASP.NET Core. Existing code keeps compiling unchanged once the package reference is added../ bootstrap && ./ configure && makeIf you are migrating your code from netcore library, you will have to:
thrift -gen netstdhashcode is now standard, while nullable is no longer supported.Thrift.Transport and Thrift.Protocol namespaces now use the singular formusing Thrift.Processor; in the server code where appropriateT*ClientTransport to T*TransportTBaseServer occurrences in your code to TServerSingletonTProcessorFactory is now called TSingletonProcessorFactoryAsyncBaseServer is now the TSimpleAsyncServerYou may wonder why we changed so many names. The naming scheme has been revised for two reasons: First, we want to get back the established, well-known naming consistency across the Thrift libraries which the netcore library did not fully respect. Second, by achieving that first objective, we get the additional benefit of making migration at least a bit easier for C# projects.
Because of the different environment requirements, migration from C# takes slightly more efforts. While the code changes related to Thrift itself are moderate, you may need to upgrade certain dependencies, components or even modules to more recent versions.
thrift -gen netstd. The following compiler flags are no longer needed or supported: hashcode and async are now standard, while nullable is no longer supported.async/await model, if you have not already done so. As netstd does not support ISync anymore, async is mandatory. The synchronous model is simply no longer available (that‘s also the reason why we don’t need the async flag anymore).cancellationToken parameters. They are optional but may be quite helpful.using Thrift.Processor; in the server code where appropriateTServerSocket is now called TServerSocketTransportIProtocolFactory into ITProtocolFactoryTSimpleServer, try TSimpleAsyncServer insteadTThreadPoolServer is now a TThreadPoolAsyncServerServe() method does now ServeAsync()SetEventHandler method now starts with an uppercase letterTServerEventHandler descendants you have in your codeWe use SharpFuzz (and its libfuzzer variant) to fuzz the Thrift protocol parsers. This is not integrated with oss-fuzz, so all fuzzing must be run locally. Supported platform: Linux only.
make check compiles the 12 fuzzer variants without SharpFuzz IL instrumentation, so changes that break the fuzzer build will fail CI. Full, instrumented builds suitable for actually running a fuzzer remain opt-in: run make build-fuzzers (or ./buildfuzzers.sh), which additionally requires the SharpFuzz.CommandLine global tool and the libfuzzer-dotnet native driver as described below.
A .NET 10 SDK (same one used for the rest of lib/netstd).
The SharpFuzz IL-rewriter CLI, installed as a .NET global tool:
dotnet tool install --global SharpFuzz.CommandLine export PATH="$PATH:$HOME/.dotnet/tools"
Add the PATH export to your shell rc if you want it to persist.
The native libfuzzer-dotnet driver binary. Grab a prebuilt release from the Metalnem/libfuzzer-dotnet releases page (or build it from source). Place it in a directory of your choice and point SHARPFUZZ_DIR at that directory:
export SHARPFUZZ_DIR=/path/to/libfuzzer-dotnet-dir
buildfuzzers.sh and runfuzzer.sh expect to find $SHARPFUZZ_DIR/libfuzzer-dotnet.
DOTNET_ROLL_FORWARDAs of SharpFuzz.CommandLine 2.2.0, the global tool's runtimeconfig.json pins the tool to .NET 9, which prevents it from running under a .NET 10-only host. Both buildfuzzers.sh and runfuzzer.sh therefore export DOTNET_ROLL_FORWARD=Major at the top of the script as a workaround. Upstream fix: SharpFuzz PR #72 (merged, pending release as SharpFuzz 2.3.0). Once that release ships, remove the DOTNET_ROLL_FORWARD exports from both shell drivers and update the SharpFuzz package pin in Tests/Thrift.FuzzTests/Thrift.FuzzTests.csproj.
Build all twelve fuzzer assemblies (3 protocols x 2 fuzzer types x 2 engines) and instrument them with SharpFuzz:
./buildfuzzers.sh
Run one fuzzer:
./runfuzzer.sh <fuzzer-name> <engine> [extra-fuzzer-args...]
Where <fuzzer-name> is one of binary, compact, json, binary-roundtrip, compact-roundtrip, json-roundtrip, and <engine> is libfuzzer or afl. Any additional arguments are passed through to the underlying fuzzer engine, e.g.:
./runfuzzer.sh binary libfuzzer -runs=10000