QuickFIX/n is the .NET FIX engine, and its repository is the build guide

The README is about setting up a machine to work on the protocol

The readme in this repository is not a user guide, and it says so in its first line: it is about setting up your system to do QuickFIX/n development. That distinction matters before anything else, because QuickFIX/n is a FIX protocol engine for the .NET platform and the interesting documentation for using it lives elsewhere. The readme points tutorials for how to use QuickFIX/n at the project website, and it links a separate tutorial page on creating an application. So if you arrive here looking for how to accept a session or send an order, you are in the wrong repository, and this one is about the development environment instead. The project home is quickfixn.org, the source is written in C#, the default branch is master, and the repository publishes no GitHub releases.

One runtime version and one shell for the scripts

Two setup facts are stated plainly, and both of them decide whether your machine is ready. The project uses .NET 8 starting with version 1.13, so a machine with an older .NET SDK cannot build the current tree at all. And all the scripts are in Powershell, and should work on both Windows and Unix-based platforms, which is a deliberate choice to avoid maintaining two sets of build scripts for the two operating systems. The readme assumes developers know how to use the dotnet cli tools or the IDE of their choice, which tells you the project expects a working .NET toolchain rather than providing one. The repository carries a QuickFIXn.sln at the root, so the whole thing opens as a single solution in an IDE.

DDTool regenerates the message classes from the data dictionary

The part of the build that is specific to FIX rather than generic .NET is the code generation, and the readme describes it as DDTool, a C#-based tool for analyzing DataDictionary files and regenerating the source for message and field classes. The workflow is that you check out the DDTool directory to learn more, or you just run the script.

pwsh scripts\Generate-Message-Sources.ps1

The DDTool directory at the top level of the repository is where that tool lives, and the Messages directory is the counterpart, holding the message and field sources. The reason this exists at all is a property of FIX itself: the specification defines messages and fields in a data dictionary, and a strongly typed engine needs classes for them. Regenerating rather than hand-editing keeps the two in step, and it means that when the specification changes the sources can be rebuilt from the dictionary. The readme frames this as one of the two steps a developer has to perform on a fresh checkout, alongside building and testing.

Build and test with the dotnet cli, and filter to one suite

The build and test section is a list of dotnet commands, and it is worth reading because the separation between unit and acceptance tests is the useful part. The simplest spin-up instructions are a build followed by a test run that covers all unit and acceptance tests, and those acceptance tests use NUnit.

dotnet build
dotnet test

The two suites can be run on their own, which matters when you are iterating on one kind of test.

dotnet test UnitTests
dotnet test AcceptanceTests

There is a verbosity switch for more detail in the output, and the readme points out that the acceptance test names in the example are slightly off from the directory names, since the command is written as dotnet test -l "console;verbosity=detailed" AcceptanceTest and as dotnet test --filter Fix44Test AcceptanceTest. A specific suite is selected with the --filter option, and Fix44Test is given as the example of a TestCaseSource function in Fix44.cs. The logs from the acceptance tests are written to bin/Debug/net<NN>/log, with the numeric part standing in for the target framework number. Two things follow from that layout: the acceptance tests talk to something real enough to produce logs, and the path depends on the framework version, so a script that reads them has to be told the number.

The repository layout is the shape of a FIX engine

The top level of the tree is a map of the protocol itself. The solution file QuickFIXn.sln sits at the root beside QuickFIXn/, which is the engine library, and Messages/, which holds the generated message and field classes. DDTool/ is the generator for those classes, and spec/ is where the specification files live. The two test directories, UnitTests/ and AcceptanceTest/, sit next to each other as separate projects, and Examples/ holds the sample applications. Then there are the supporting directories: scripts/ for the Powershell helpers, config/ for configuration, GenerateKeys/ for key generation, nuget-enclosures/ for packaging metadata, and the dotfiles plus .github/ for the workflows, including the build status badge in the readme that points at a dotnet.yml workflow. There are also CONTRIBUTING.md and RELEASE_NOTES.md, and a second readme named RELEASE_README.md, which suggests the project publishes release notes as part of its process even though it does not use GitHub releases.

The Examples directory covers the shapes an application actually takes

The example projects are the fastest way to see the range of ways a FIX application is put together, and the directory listing is unusually varied. There is SimpleAcceptor, which is the minimal server side, and TradeClient, the matching client. Standalone is the case where both ends live in one process. Executor is the application that processes inbound messages against a business logic, and it is the one most real integrations resemble. Then there are two conversion examples, FixToJson and JsonToFix, which convert between a FIX representation and JSON, and their presence says something about how the project expects FIX to be integrated with modern service stacks. The Examples directory also carries certificate and key files for local testing, with a QuickFixn-TestCA.cer and QuickFixn-TestClient.pfx and QuickFixn-TestServer.pfx, plus its own README. Those files exist so the sample projects and the acceptance tests can talk to each other over a secured session without anybody having to generate keys first.

Maintenance and funding sit with Connamara, and the licence is QuickFIX's own

The credits section states that QuickFIXn is maintained and funded by Connamara, and that the names and logos for Connamara are trademarks of Connamara Systems, LLC. That is the commercial reality behind the project: this is not a volunteer effort that happens to have a NuGet package, it is a product with a vendor behind it, and the vendor's own site carries the tutorials. The licensing section is also specific. The software is available under the QuickFIX Software License, and the readme points at the LICENSE file for the terms, and the licence is recorded as a custom one that GitHub cannot classify rather than one of the standard open source licences. That is worth understanding before you build on it, because a custom licence means you have to read the file rather than assume permissive terms, and it is the single largest difference between this engine and an ordinary open source dependency. The NuGet package referenced by the version badge is QuickFIXn.Core.

Where QuickFIX/n is the wrong choice

The first wrong case is a team whose FIX requirement is a single message type received occasionally, because running a session engine for that is a large amount of protocol machinery to carry, and the sessions, the sequence numbers and the recovery behaviour all have to be operated. The second is a team that needs a permissive open source licence, since the QuickFIX Software License is a custom one and a procurement process that expects MIT or Apache terms will need the file reviewed rather than assumed. The third is a project on .NET before version 8, because the project uses .NET 8 from version 1.13 onwards, so an older target is not a configuration choice but a different version of the library. The fourth is a team that wants a general purpose messaging abstraction, since this is an engine for one protocol with a long history of industry-specific behaviour, and the value comes from that specificity rather than from abstraction. The fifth is a team that wants server side rendering of FIX data without maintaining a FIX engine, which is what the FixToJson and JsonToFix examples hint at, and those are illustrations rather than a product you can depend on. The sixth is anyone expecting the readme to teach the protocol, since it explicitly redirects to the website for tutorials and concentrates on the development setup, the code generation and the test commands.

Editorial conclusion

Engineering teams in finance or market infrastructure that already speak FIX and want the .NET implementation, with a vendor behind it and tutorials and support available, are the people QuickFIX/n serves. It is the wrong choice for a project that treats FIX as a detail rather than a core competence, since a session engine brings sequence numbers, recovery and message dictionaries with it, and it is the wrong choice for a team that needs an OSI approved open source licence, because the QuickFIX Software License is a custom one that has to be read rather than assumed. Check three things before you commit: that your target is .NET 8, since the project uses .NET 8 from version 1.13 onwards, that your build environment can run the Powershell scripts, since all of them are written in Powershell and are meant to work on both Windows and Unix-based platforms, and that you have regenerated the message sources after changing anything in the data dictionary, because the DDTool generator exists to keep those classes in step with the specification. The default branch is master, the repository publishes no GitHub releases, the last push was on 2026-09-28, and maintenance and funding sit with Connamara.

Frequently asked questions

Official sources

1. connamara/quickfixn on GitHub
2. Issues
3. Project website
4. README