MSBuild failing in Cpp.Targets searching for 'True.dpr', with a new XE4 project

Question

I am encountering some odd msbuild errors with a project in RAD Studio XE4, and am seeking help to diagnose what's going on. I've been encountering this for a couple of weeks now but have not succeeded in solving it myself - time to ask more widely. Symptoms are:

• With a project that has been built and run from within the IDE, msbuild Project.cbproj appears to work
• Running msbuild Project.cbproj /t:Clean works, and deletes intermediate files fine. A visual scan of the output doesn't show any unusual files being deleted - just .obj files, linker state files, the final EXE, etc.
• But running msbuild Project.cbproj /t:Build or just plain msbuild Project.cbproj after either cleaning or on a clean checkout fails with the following error message:

Microsoft (R) Build Engine Version 3.5.30729.5420 [Microsoft .NET Framework, Version 2.0.50727.5472] Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 12/09/2013 10:35:03. Project "C:\\projects\\Project.cbproj" on node 0 (default targets).

_PasDepCheck: Modified: Source\\Common\\resample.pas _PasCoreCompile: Embarcadero Delphi for Win32 compiler version 25.0 Copyright (c) 1983,2013 Embarcadero Technologies, Inc. C:\\Program Files (x86)\\Embarcadero\\RAD Studio\\11.0\\Bin\\CodeGear.Cpp.Targets(191 1,5): error F1026: File not found: 'True.dpr' Done Building Project "C:\\projects\\Project.cbproj" (default targets) -- FAILED.

Build FAILED.

"C:\\projects\\Project.cbproj" (default target) (1) -> (_PasCoreCompile target) -> C:\\Program Files (x86)\\Embarcadero\\RAD Studio\\11.0\\Bin\\CodeGear.Cpp.Targets(1 911,5): error F1026: File not found: 'True.dpr'

 0 Warning(s) 1 Error(s) 

Some things strike me about this:

• It lists two versions of .Net at the top, an older one in square brackets. Could it be loading or using parts of two frameworks?
• True.dpr does not exist, nor can I find an entry manually searching the .cbproj file for a True.dpr , or for a True entry that looks (to me) like it could be misinterpreted as a project name. (If you are not familiar with Delphi, a .dpr file is an old-fashioned project file - it contains the entry point. Building one may imply msbuild is finding a source or project entry somewhere. 'True' seems to me like the .cbproj file is being misinterpreted or is corrupted - but it's brand new, so shouldn't be, and it works from within the IDE.)

Other information about the system and projects:

• The project is being upgraded from RAD Studio 2010. However, the project file was created in XE4 from scratch , ie it's brand new, by creating a new project in the IDE and adding the existing units (Delphi and C++ files.)
• The project is a C++ project with one or two Delphi units. You can see it is falling over when compiling a Delphi unit at the start of the compilation. For those not familiar with mixing C++ and Delphi, typically in mixed-source projects the IDE or msbuild would compile the Delphi units first (doing so can create / update C++ headers to interface with the Delphi code.)
• The project is one of a group, but should compile stand-alone.
• I have RAD Studio XE4 installed with Update 1.
• msbuild is being launched from the RAD Studio XE4 command line, ie one which uses the rsvars.bat file to set up the paths etc.
• In the above output, I have changed our real project name to Project because I don't want to identify it. However, the rest of the output is exact.

Any ideas? I've been trying to solve it for ages, and am stumped.

Answer 1

I just had this same error in Delphi XE5. Running MSBUILD with /v:diag outputs the complete commandline for DCC32, which had a rogue true amongst the parameters.

The following page pointed to the solution: http://wiert.me/2013/11/20/when-the-delphi-xe5-commandline-compiler-fails-with/

In this case I was passing the parameter /p:DCC_DebugInformation=true , but this could also be in the .dproj file. Changing true to 2 fixed the problem - ie

MSBBUILD /p:DCC_DebugInformation=2 project.dproj

Answer 2

Answering my own question, in the hope it will be useful to future readers.

This comment was key:

It lists two versions of .Net at the top, an older one in square brackets. Could it be loading or using parts of two frameworks?

It turned out not to be the project name after all. Instead, we had a custom build logger written to use with the msbuild version shipped with RS2010. It was built with a different version of .Net, and loading the logger DLL seemed to cause major problems inside msbuild - understandable since I guess it meant it was loading two different versions of the .Net runtime.

Why this answer might be wrong: I did try command lines without the custom logger (slowly trimming down our old working command lines bit by bit and then working up again to find the problem.) Those sans -logger builds failed too, which leaves me a bit puzzled. It's possible some intermediate output from a crashing instance of msbuild confused subsequent runs, or something in the .Net runtime cached the use of the DLL or the different loaded runtimes. I do know that the custom logger did cause problems for sure, and deleting the DLL itself (which was when everything really began working) as well as just removing it from the command line fixed the problem.

Answer 3

A similar answer to that of @michael-g, only using the GUI, can be found at this link: https://blog.spreendigital.de/2014/03/14/w1030_warning_xe5/

(ie go to Delphi debugging settings and change "Debugging information" to something else other than the existing "True".