Conditional expression using a string variable set in my Burn bundle?

[michaelgburton]

I'm not sure exactly where I'm going wrong with this, so let me lay out my components and maybe someone can spot the gap in my understanding. It shouldn't be hard to find, as the gaps are larger than the understanding ;)

What I'm trying to do is the classic "clean up ProgramData" scenario. There are a number of solutions online for older versions of Wix, but I'm in Wix 5, and it's possible that's part of the disconnect.

First, my MSI package defines a property called CleanupFolder that acts as a yes/no flag for doing the cleanup, based on the user's decision within my custom bootstrapper.

<PropertyGroup>
    ...
    <CleanupFolder>0</CleanupFolder>
</PropertyGroup>

I use a similar mechanism for populating INI file settings with user-inputted data from my custom bootstrapper, so I feel reasonably certain that definition, by itself, is not my issue here.

In my Package.wxs file, I have the following fragment:

<DirectoryRef Id="BaseDataFolder">
	<Component Id="CleanupProgramDataOnUninstall" Guid="some-guid-that-works">
		<util:RemoveFolderEx Property="BaseDataFolder" Condition="[CLEANUPFOLDER]='1'" On="uninstall" />
	</Component>
</DirectoryRef>

When I ask msbuild to build my project, however, it throws this lovely red text at me:
error WIX0204: ICE03: Bad conditional string; Table: Wix4RemoveFolderEx, Column: Condition

Is there something really obvious I'm doing wrong here? I'll note that I'm trying to follow the guidance not to run my bootstrapper as admin, so I can't just delete the folder from that process. My next thought would be a custom action, but I'm not sure that will fare any better if I can't get this condition figured out.

[robmen]

Yeah, this catches users who are new to Conditions. You don't dereference Properties in Conditions, so drop the square brackets. I'm pretty sure I talk about when to dereference Properties in the Deployment Dojo somewhere (maybe S1:E14).

[michaelgburton]

That did it, thanks. Didn't help that I had a malformed property (don't put values in the property attribute, apparently!) that was throwing a second error and I was missing the difference.