We were wondering if there are any users out there who are using the WIN32 build support. We are contemplating removing that if nobody is using it, but naturally we’d like to understand if anyone’s using it.
Yes, I’ve been using it for more than 10 years now, but recently mostly only using the fdbclient native library on Win32, while running the Linux build of fdbserver (either in production or in a local Docker image).
My main use case today is developing distributed applications with C# and .NET, using Microsoft’s .NET Aspire. I’ve written an Aspire Integration for FoundationDB that spins up the FoundationDB Docker image locally, similar to how other integrations (Postgres, MongoDB, Redis, …) work.
When working on the applications locally (in dev mode), the Linux build of fdbserver runs in a local docker container. You application components (web server, API backend, microservices, etc.) use the .NET binding and load the `libfdb_c` variant for the local platform to connect to the container: If you are developing on Windows, it will load the Win32 build of libfdb_c.dll. If you are working on a Linux desktop or MacBook laptop, it will load the binary for the corresponding platform, without needing to install anything.
Having the FoundationDB .NET Aspire integration, combined with the NuGet package that redistributes the client library for each platform, makes it very easy to start developing application for FoundationDB. You simply reference a few NuGet packages, use Aspire to orchestrate everything, and with a couple lines of code, your distributed application can talk to a fdb cluster running locally.
.NET Aspire relies on Docker for Desktop - on Windows and macOS - to spin what would normally be external dependencies (like the database or other services), and inject all the required “connection strings” into your local projects so that they can connect to it. In the case of FoundationDB, I inject the fdb.cluster file. When deploying to an actual infrastructure (AWS, Azure, Kubernetes, …) these local dependencies would be replaced with actual hosted databases.
We maintained the Win32 build up to version 7.3 - the latest successful build was for 7.3.52 - but since then we’ve had issues with Boost not playing nicely on Windows. I haven’t had time to try again with a more recent 7.4 versions. I was able to build the fdbclient project, but had issues during linking with some new Boost modules that were referenced in later commits of the 7.3 branch.
Currently, the intended way to use .NET with FoundationDB is:
- Use .NET Aspire and the FoundationDB integration for local dev: easy setup, uses docker to run the official
foundationdb/foundationdbimage (Linux build), and auto-install the correct native client library (up to 7.3.52 on Windows, latest on other platforms). - In the .NET Aspire
AppHostcode (equivalent of the distributed “void main”), you can choose the exact version of the fdb docker image that will be used by all the distributed processes, which means that the version of the fdb dependency is source controlled: you can work on multiple branches and/or projects that target different versions of fdb, even concurrently. Each version will run in its own docker container. This was not possible when runningfdbserver.exeas a Windows Service locally (you would need to uninstall/reinstall to another version, or use an external cluster). - Publish and build the .NET application targeting
linux-x64orlinux-arm64and deploy your application native binaries alongside the linux builld oflibfdb_c.so(usually with docker compose, I would copy the library binaries from the existing fdb docker image).
For this workflow to continue working, we only require to be able to build fdbclient and libfdb_c.dll on Win32 (and possibly fdbcli.exe, usually to be able to test the connectivity from your Windows host to another fdb cluster running on Linux). It would be nice to be able to build the server as well, but if dropping that requirement helps preserve the client build, this wouldn’t significantly impact the .NET developer experience.
Losing the ability to build the Win32 client would make it extremely difficult to develop fdb applications on Windows, using Visual Studio, VS Code or Rider. I’ve experimented with WSL2 as a workaround, but there are severe limitations which make it very impractical.
I’d be happy to help maintain the Win32 build. I would appreciate some assistance from people with deeper knowledge in C++, at least initially to get Boost building and successfully link to it. If anyone has some insight or experience with this, please reach out!
1 Like
Thanks a lot for describing the details of your use case. I’m not really familiar with Win32 or boost per se but hopefully that can be overcome. I think you found our discord server so that would be one place to follow up. In any case, thanks again for all of the details.
Good news, I was able to successfully build a version of both fdb_c.dll and fdbserver.exe for version 7.4.4 (latest commit in the release-7.4 branch as of this writing).
I had to fix a few things, and disable some components that are not needed on Windows (AWS SDK, S3, Swift support, Sphinx documentation, compiling the bindings, …), but overall the project builds fine using clang 19.
There was one single issue related to a linking failure for TLSConfig::loadAsync(…) that I was unable to solve. This is the only actor in the whole project that fails to link, and I suspect that there is some required interop with Swift that is specific to this type and could maybe have some side effects ? This is related to cross-compiling, and I see several “fix-me” comments around this part.
I temporarily worked around this by simply disabling the method that reloads the local client certificates in Net2, which calls TLSConfig.loadAsync(…). This means that the current WIN32 build or the client does support TLS (not needed for purely local development), but if someone has any idea what could be the issue here, I would like to be able to restore TLS support.
1 Like