Problems with visual studio solution.

[papaathome]

Dear Sir,

Usually I just stick tinyxml2.h and tinyxml2.cpp in my project and use it that way. But for testing and learning I like to use the test.exe tool that comes with the solution.

I found a number of issues with the solution:

1. The platform toolset is v140, which is for VS2015 (while the solution is in a folder named VS2010).
2. All output for each configuration goes to the same folder.
3. Output does not include the debug information database at a logical location.
4. The code assumes #define DEBUG while VS is using #define _DEBUG (note the leading _)

I tried to solve the isssues (and I think I succeeded in that), see the solution and project files in the zip file below.

At 1. toolset is 140. Not really a big issue, but I'm using VS2010 and VS2015. For convenience I changed it back to toolset v100 for VS2010.

At 2. all output/temp file to the same directories irregard the platform or target. This is a potential dangerous issue. Assume you build a debug version of tinyxml2.cpp and then build a release version of test.exe. This last build can link against the debug version which migth generate some strange warnings/errors (such as ITERATOR_DEBUG_LEVEL = 2 and not 0). It is relative easy to change the build configuration, $(Outdir) and $(Intdir) to include $(Platform) and $(Configuration) resulting in the following build and output paths:

// temporary directories. ./build/test/Win32/Debug-Dll/ ./build/test/Win32/Debug-Lib/ ./build/test/Win32/Release/ ...

// output directories ./Win32/Debug-Dll ./Win32/Debug-Lib ./Win32/Release-Dll ./Win32/Release-Lib ./x64/Debug-Dll ./x64/Debug-Lib ./x64/Release-Dll ./x64/Release-Lib

Each platform an configuration has its own build and output area. Just a seperation of concerns, no files with the same name from other builds.

At 3. De 'Progam Debug Database' (.pdb file) is realy important, very important while debugging! I changed the project configuration so that the .pdb file is placed in the output directory with the .exe, .dll or .lib file.

At 4. The code checks for preprocessor macro 'DEBUG' but visual studio is using macro '_DEBUG'. I fixed this by including both macros in the configuration for each Debug-* configuration.

Edit: Oh, and I forgot to thank you for tinyxml2, it saves me huge amounts of time!

Kind regards,

Zip file with solution and project files included. tinyxml2-solution.zip

[papaathome]

Ad 4. Did see the line #if defined( _DEBUG ) || defined (__DEBUG__) in tinyxml2.h (line 56) too late. Point 4 is not a relevant issue.

kind regards,/

[leethomason]

Yeah, I'm no super happy with the VS files myself. Generally speaking, I'd like to 1) move the VS project to 2017 (I know this is counter to your needs, but it's way behind at this point), and 2) clean up the directories.

What I haven't tried is generating VS files with cmake. If that works pretty well, that may be a better solution. If it works well enough, I would make a note of it and check in the VS2017 files.

[leethomason]

See #594

[papaathome]

One of the main reasons why I choose for tinyxml2 is that it has a VS solution. I do not want to install all kind of extra tools to build just a package.

Having (at least one) solotion for VS available is a strong point for tinyxml2 in my opinion. When you switch to another community version of VS you can just freeze the previous solution and copy/start a new one. You dont need to keep all solutions up to date but having them available will help the common VS studio user a lot.

Kind regards,