DDTool generates invalid field type for SEQNUM (SeqNumFieldType / SeqNumType not found)

[artzlite]

Describe the bug

When generating FIX message classes using DDTool, the SEQNUM type is mapped to SeqNumFieldType / SeqNumType.
These classes do not exist in the current QuickFIX/n codebase, which results in compile errors like:

QuickFix.Fields SeqNumFieldType SeqNumType not found

Steps to reproduce

1. Run DDTool with any DataDictionary (e.g. FIX42.xml or a custom FIX42-CUSTOM.xml).
2. Include the generated files in a project that only references QuickFIXn.Core.
3. Build → errors appear for missing SeqNumFieldType and SeqNumType.

Expected behavior

SEQNUM should be generated as ULongField with base type ulong (consistent with QuickFIX/n core definitions).

Workaround

In DDField.DeriveTypeInfo, modify case mapping:

case "SEQNUM": 
    csClass = "ULongField";
    baseType = "ulong";
    return;

After regenerating, the code compiles and works as expected.

Environment

QuickFIX/n version: 1.13.1
.NET: 8.0
OS: Windows 11

[gbirchmeier]

Looking into your issue, I see some problems with the DDTool generator that I never had to notice before.

DDTool is a C#-based reimplementation of the generator that was previously written in Ruby. My primary aim was to get rid of the Ruby dependency, and I succeeded.

However, like its predecessor, DDTool has an in-built expectation that it will always be writing into the already-existing <reporoot>/Messages/ folders. Because of that, it's more accurately a _re_generator, not a generator.

So now I see these problems if you generate to new directory:

1. DDTool may attempt to write files to a non-existing folder, and fail out. I fixed this in a branch whIch I will PR soon.

2. The new DD project will not have a csproj file. I will fix this too-- I'll make it write a new csproj file if one doesn't already exist.

   2a. Because of the files Fields.cs and FieldTags.cs that are generated into QuickFIX core, the newly-generated DD project will still have to reference it (and users will still need to custom build the QF core project). I need to clarify this situation in docs.

Regarding your specific situation, @artzlite :

You baffled me a little in Step 2: "Include the generated files in a project that only references QuickFIXn.Core."

I guess this has to do with the fact that, as mentioned above in my bullet 2, the generated DD folder is not actually a project and doesn't have a csproj file. Because of that and my not-good-enough documentation, you are trying something else.

I'm going to try to fix all this confusion. Hopefully within the next few days if something doesn't pull me away.

[gbirchmeier]

I made some DDTool improvements in PR #982, but they don't specifically address your problem, though they're a little inspired by it. You can see the PR details for that.

Looking over your issue, I think I finally get it. The files in question must be Fields.cs, which is typically generated INTO the QuickFIX core library which you should rebuild also.

It probably seems stupid that you can generate a whole "separate" message library but some of that generation must go into the "core" library also. I agree with you actually. QF/n has always been this way, which is not a satisfying or good answer.

I'm going to think on how to maybe resolve this without radically changing QF/n, but II cannot promise any timeline on such a fix.

For now, I recommend you generate your lib into Messages/ like the others, and build both QF/n Core /and/ your custom messags lib, and use them in your new project together.