message serialization only uses in-built DD about quickfixn HOT 7 OPEN

At the moment, to work-around you can re-build QF/n (effectively changing the in-build DD to be what you need).

To regenerate QF/n source:

1. Make your alterations to spec\fix\FIX44.xml (or which ever version's file that you require)
2. run generate.bat (requires ruby, and ruby gem "nokogiri")
3. rebuild the project

See the README.md file or the homepage for more information about rebuilding.

from quickfixn.

QF/C++ and QF/J actually have this same behavior. At the moment, this is not something that seems to be in high demand, so I'm tagging it low priority.

from quickfixn.

Any change to get a T4 in place for the generate.bat?

from quickfixn.

I'm gonna be honest, this is the first I've ever heard of T4. We (Connamara) like Ruby a lot, so that's what we used when we started the project.

We're open to it, but such a change will probably need to come from an outside contributor. When we have time to work on QF/n, we're more focused on fixing bugs and adding features than replacing things that aren't broken.

Is there some advantage to using T4? Note: generating code takes a minute or two; you probably don't want to have generation occur as a build step every time you compile.

from quickfixn.

Well, T4 is standard in Visual Studio since IIRC 2008 or so, so - the advantage is not having another technology stack in.

On top, it is "run on demand" only - with a switch per project to turn it to run on every build, and it has a nice button in visual studio to run all T4 in a solution. Personally I just hate adding foreign technologies to a stack without real advantages.

On top, a minute or two? You joke? That little XML code generation should not take more than 15 seconds on a decent machine. You do not generate so much stuff.

from quickfixn.

On my machine (which is a Windows VM), it takes about 1:50. I think the bottleneck is the file-writes - we write a lot of small files. And, of course, a VM is slower than a non-VM.

If T4 is standard in Visual Studio (Express too?), then that's definitely a selling point. I think generation might be our only Ruby dependency. Even though we like Ruby, there's no reason to keep it if another built-in can do the job.

If you want to take a whack at it, please open another issue. These past few comments aren't really on topic for issue #12.

from quickfixn.

Just final note - T4 + express: no ;) Before 2010 supportsly - http://stackoverflow.com/questions/2533821/does-visual-studio-2008-express-support-t4. . 2010 express forward - yes: http://stackoverflow.com/questions/3309551/does-vs-2010-express-edition-support-t4-preprocessed-templates, so - the naswer is yes for the current and future stack. The file extension is "tt".

Also, T4 generates one file - per defined approach (one xml to one .net file) - that is in line with how .net fcode generation should work (noone should modify those anyway, if necessary make them partial in generation allowing extension).

from quickfixn.