I can’t seem to get MSBUILD to pay attention to the ConditionalDefines property.

MSBUILD /nologo D:\Oxygene\Oxy006\Oxy006.oxygene /verbosity:minimal /target:Clean,Build /clp:ErrorsOnly -property:ConditionalDefines=DAVE

If “DAVE” is defined in the “Conditional Defines” of the application properties in the .oxygene file, then all is well.

  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">

Anything I put on the command line is seemingly ignored, with whatever is defined (or not) in the property group being used.

I can work around this by building manually for now (or updating the .oxygene file directly), but am I missing something obvious on the command line ?

ConditionalDefines is an EBuild-speciifc setting name, MSBuuld does not know about it. If you want to use MSBuild (you really shouldn’t) and have the defines recognized on MSBuild level (not just in the compiler), you have to use the old legacy “DefineConstants” name for this setting.

Thanks Marc. I came via DefineConstants before trying ConditionalDefines. I couldn’t get it to recognize that either. I’ve just tried again after your message, but still no joy.

MSBUILD /nologo D:\Oxygene\Oxy006\Oxy006.oxygene /verbosity:minimal /target:Clean,Build /clp:ErrorsOnly /p:DefineConstants=DAVE

Is there anything I need switch on in the project to get MSBUILD to recognize the legacy “DefineConstants” ?

At some point I will have to address the technical debt and try switching to EBUILD, but it’s not today, or probably the next 6 months to be honest.

Not as far as I know, but MSBuild really is out of our control. In what kind of places/scenarios are you using thje defines and dont see them working?

Out of curiosity, what keeps your project from building on EBuild?


Not as far as I know, but MSBuild really is out of our control. In what kind of places/scenarios are you using thje defines and dont see them working?

We largely use them in classes for switching between live / test / development logic paths etc. Some / all of which could be done with Git branches, but that’s another story. Most of the time it’s just short term and they never need to make it in to a live delivery. We have one case now though (not the one below) where a compiler directive would need to make it to live. Basically to compile in or out code dependent on the target customer.

method TDiagramS.GetBagMaster : TBagMasterBase;
	if fBagMaster = nil then
		fBagMaster := new TBagMasterS(self); //the constructor will populate the list
	result := fBagMaster;

method TDiagramS.GetBagItems : TBagItemBase;
	if fBagItems = nil then
		fBagItems := new TBagItemS(self); //the constructor will populate the list
	result := fBagItems;

Out of curiosity, what keeps your project from building on EBuild?

Time… I think we did look at EBuild a good few years ago and ran into some roadblock, never pushed past it and have not returned since. I have a hope that we can find time later this summer to pay off a few chunks of the technical debt and get some upgrading done (with renewal of RemObjects licensing!)

Oh, so from inside code? that should work fine, using either setting. very strange.

So the project sees the ConditionalDefined (or DefinedConstants) as they are in the project file, rather than the ones you’re passing from the command line? Does this project use RemObjects.Elements.Echoes.Legacy.targets, or regular RemObjects.Elements.Echoes.targets (which would host EBuild internally)…

If you;re not using Legacy, id suggest to literally just try

ebuild D:\Oxygene\Oxy006\Oxy006.oxygene --verbosity:minimal --rebuild --setting:ConditionalDefines=DAVE

and see what happens. there’s really no reason that should work worse than MSBuild (again, for no -Legacy). If it doesn’t i’d love to hear how it fails.


ebuild D:\Oxygene\Oxy006\Oxy006.oxygene

Well that worked, a successful build. I then tried adding --setting:ConditionalDefines=DAVE

Am I right in thinking those ConditionalDefines are additive ? In MSBUILD I believe whatever you specify overwrites what is in the project ? For Ebuild, it looks like the project setting defines are kept and to those are added what you’ve put on the command line ? In my case, trying DAVE seemed to leave in place what I had in the project file i.e. i got the project file plus DAVE. If I took my specific conditional out of the project, but just used it on the command line instead of DAVE, it was noted and used. Either way, it worked for me. Did I see an old posting (from a few years ago) where you said you were going to add an override conditional defines property (I can’t remember the actual name but it was similar to that) ?

And confirmation of the target. Looking in the project file I think you’re referring to the highlight below ? Can that be seen within VS, or would I need to edit it in the project file. If we switch to EBuild, I’ll need to be a little more aware than I am about what I’m looking for!

And finally , thanks. It always seems to be last thing on a Friday when I post these questions. Cider time in a couple of hours. Cheers!

They are not. All project settings are “highest level wins”, per-project, per-configuration/targte, -.user file, command line.

I am pretty sure that is not how it works (as this has actually been requested kin the past, but would take a considerable amount of infrastructure changes to supper. But just in case, I will have a look and see.

There is a separate ExtraConditionalDefines setting you can set, and it will be combined with ConditionalDefines. Similarly for ImpliedConditionalDefines, which is set ignternally by EBuild, and I suggest to not mess with.

Yes. that bottom line. If it does not say Legacy.targets, then you should be good with EBuild.

Same here :tumbler_glass:.

PS: seems to be working as expected for me:

A and B are defined in the project, so those hints hit when I build from the IDE. When I pass --setting:ConditionalDefines=C, that replaces A and B, and only the C define is hit.

if I pass --setting:ExtraConditionalDefines=C, then all three hit.