Need some assistance with TFS2010 + an automated Build + 'Configurations to Build = Debug'

Question

really. weird. shiz.

When I do a TFS Team Build (with Remote Deploy), some #if DEBUG preprocessor directives code I have on a web page does not get called. When i manually one-click deploy (remote deploy) the preprocessor directive code works. When I debug locally, the code also works.

So - problem looks to be related to my configuration settings for the Build Template i have (I think??). So, this is what I have :-

Nothing too hard. That says ... Please kind Compiler. Build my project (read: project, NOT solution) in 'DEBUG' mode.

The code i have is the following :-

#if DEBUG
    Log.Debug("We are in DEBUG mode.");
#else
    Log.Debug("We are _NOT_ in DEBUG mode.");   
#endif

So when this code (in some aspx page) is called, it prints out "We are in DEBUG mode." when it's

• Localhost (Localhost Configuration: Debug)
• Remote server with manual One-click reploy (Localhost Configuration: Debug)

But not when i let TFS's continuous intergration kick in.

FML.

I've tried to see if it was a CASING situation (ie #if debug or #if Debug) but it still doesn't work.

I then even tried to explicitly tell MSBuild the configuration....

Still no love.

Oh .. but this is the corker! I ALSO have some web.config transformations

• web.config
• web.debug.config
• web.release.config

... and can u guess which file get's transformed ?? Winner if u guessed web.debug.config for all scenario's ... even the team build which is erroring in the code! So it's like the build process and workflow knows it's a DEBUG configuration .. kewl! but the compiled code doesn't???

Lastly, changing debug="true" or debug="false" makes no difference.

Can someone please help before I jump out of this building? It kills me when, constantly, these weird ass issues pop up in my life. sigh

Please help!

NOTE: I cannot accept anymore donations for the world's smallest violin - I have been given plenty already. Cheers :)

Answer 1

Well, I found the answer, but I'm not too happy with it. I'll make a video of this bug and email it off to Vishal @ MS ... to see what he thinks :)

Anyways, if you look carefully at the default configuration everywhere it is this...

DEBUG | Any Cpu

nothing unusual there...

Now, when I change the platform to AnyCpu (notice how i removed the space....) it now works fine.

eg..

What made me think about that was when i checked out the .proj file... .. here's a snippet of that....

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>9.0.30729</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
... snip for brevity ...
    <SccProvider>SAK</SccProvider>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
... snip for brevity ...
    <DesktopBuildPackageLocation />
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
... snip for brevity ...          
    <CodeAnalysisRuleSet>AllRules.ruleset</CodeAnalysisRuleSet>
  </PropertyGroup>

so yeah .. i fixed it but i'm not sure if that is acceptable or just a fluke. I'll need to get some real answers from the MS team :)

Answer 2

I can confirm this behavior as well as the work-around. It looks like VS2010 will automagically remove the space when it either a) saves the Platform value to the solution/project files, or b) removes it when it invokes MSBuild.

Either way, the TFS Build engine does not follow this pattern and it is imperative to remove the space manually if you are selecting specific Platform|Configuration values.

On interesting side note, the TFS Build Definition dialog permits you to enter just the Configuration. It will complain but then accept the input. The advantage of this approach is that the Microsoft.Common.targets file gracefully handles an empty Platform input value by defaulting to "AnyCPU".