FIX Engine supports dialects in the QuickFIX XML format, so you can use it as it is. However, there are some details:

• FIX Engine generates an identifier (id) when a QuickFIX data dictionary is used. This id is equal to the dialect file name without extension. Therefore, the QuickFIX data dictionary becomes a session level dialect, so the mentioned id should be used to create the dialect object which should be specified in the session constructor:
  Example
  C#

  Copy

  using FIXForge.NET.FIX;
  
  EngineSettings settings = new EngineSettings();
  settings.Dialect = "QuickFixDictionary.xml";
  Engine.Init(settings);
  
  Dialect quickFixDictionary = new Dialect("QuickFixDictionary");
  Session sessionWithQuickFixDictionary = new Session("Sender", "Target", quickFixDictionary);

• QuickFIX data dictionary files can include duplicates of the "field" node (explicitly or via the "component" node) in the "message" node. This leads to the ambiguity between the "require" attribute of duplicates because there is no way to detect which the attribute is actually correct. The wrong "require" attribute can lead to errors during the message validation. However, the QuickFIX Engine processes the duplicates silently, without exceptions/warnings. In order to simplify the migration from the QuickFIX Engine, the OnixS FIX Engine processes the duplicates also without exceptions, but writes warnings to the Engine's log. In this case, one can use existent QuickFIX data dictionaries, worked with the QuickFIX Engine, in the OnixS FIX Engine and at the same time can detect/correct mistakes in dialect files.