Frequently Asked Questions - Project related
How do I remove the PRJ0018 : The following environment variables were not found: "$(STLPORT_ROOT)"
This environment variable is used to locate the version of STLPort that you are using. If you are not using STLPort then you can open the project properties for each project, select the C++/General tab and change the value for the "Additional Include Directories" setting from "..\..\;$(STLPORT_ROOT)\stlport" to "..\..\". Likewise in any projects that build executables or dlls, open the project properties, select Linker and remove the "$(STLPORT_ROOT)\lib" value from the "Additional Library Directories" setting. You might find it easiest to do this by opening the project files in a text editor and doing a search and replace for the appropriate values.
Why do I get a C4068: unknown pragma warning for "#pragma JETBYTE_TODO" lines in your header files?
You MUST always start ANY of your cpp files which use ANY of our library headers with an include of the Admin Library's Admin.h file. This ensures that all files are using the same preprocessor definitions and that they're all set up to compile correctly with our tools libraries.
How can I link with the dynamic C Runtime?
At present (6.2) the JetByte Tools Libraries do not have build configurations for using the DLL versions of the C Runtime Libraries. This is because we recommend that you always build server applications using static linkage, see
here for our reasoning behind this. However if you really must link against the DLL version of the C Runtime Libraries all you need to do is to adjust the project properties (C/C++, Code Generation, Runtime Library) from "Multi-Threaded Debug" to "Multi-threaded Debug DLL" and, likewise, from "Multi-threaded" to "Multi-threaded DLL".
Why has the versioning gone from 5.1, 5.2 to 5.2.1, 5.2.2, 5.2.3, 5.2.4, 5.2.5, 6.0 and not to 5.3
We started work on the 5.3 release and began to do the work on a branch. 5.3 accumulated a lot of 'nice to have' and reasonably complex features that were on the TODO list but weren't actually required by any clients. Since the work on 5.3 started we've had some bug fixes that we've needed to release and some fixes that were complete and were actually needed and wanted by some clients. Rather than confuse our version control branch labels, we decided to 'just slip out' a 5.2.1 release. And then the pattern repeated itself with 5.2.2, 5.2.3, 5.2.4 and 5.2.5. Eventually we moved the source code repository from CVS to Subversion and the 5.3 branch vanished and the various unfinished features were split off onto their own development branches. It then seemed that the 5.x releases had accumulated enough major changes for a 6.0 release and this was the first release to come from the new source code repository and the first to have a completely new structure for the server examples.
