Problems upgrading from xtp9.81 to xtp11.1.3

Hello,
I have some problems upgrading from XTP9.81 to XTP11.1.3.
When compiling our project with the new version, several warnings (more than 19.000!) and a linker error occur. Most of the warnings are of type C4514, for example:

c:\programme\codejock software\mfc\xtreme toolkitpro v11.1.3\source\common\xtpsmartptrinternalt.h(110) : warning C4514: '=' : unreferenced inline/local function has been removed

together with C4511 (copy constructor could not be generated), C4512 (assignment operator could not be generated) and C4127 (conditional expression is constant).
The linker error gives a duplicate resource:

CVTRES : fatal error CVT1100: duplicate resource -- type:BITMAP, name:9500, language:0x0000

Well, in my project there is no such resource.
The same project compiled with XTP9.81 gives no errors and no warnings.
I am using Visual Studio 6.0 (with SP6, warnlevel set to 4) and link XTP statically.

What's going wrong?
Best regards,
   Holger

Hi Oleg,
the warnings occurred due to the include order in my stdafx.h. After sorting the includes a bit (moving the include of XToolkitPro.h to the end of the list) they were gone.

The other problem regarding the duplicate resource was because of including both the english and the german resources provided by the toolkit. In 9.81 that was no problem and works without an error.
What is the best way to compile with english and german resources together in one project and without using external dll-(or xml-) files as shown in the scribble example?

Best regards,
   Holger

Hi Oleg,

the "#define _XTP_NO_BINARY_RESOURCES" was missing in my code. Now the application compiles and links fine. Thanks:-)

But I have a problem using external files that hold language information. My application consists of a main program that loads about 400 user DLLs at startup. Each DLL has some resource strings available in two languages. That means about 800 additional language files to load at startup or is it better just to have two language files that hold the strings for all DLLs (which will lead to problems when a user creates an own DLL and wants to use it with my program)?

What is a good solution in my case?

Best regards,
   Holger