dotnet build3: build-time constants work differently than dotnet build

[joelverhagen]

Steps to reproduce

Compare the build-time constants available in dotnet build vs. dotnet build3. It looks like none of the build-time constants set in the .csproj under a TFM condition don't make it to csc.

1. Extract this example project: defines.zip
2. Build it with dotnet build and run.
3. Build it with dotnet build3 and run.
4. Compare the output.

Expected behavior

The output should be the same.

IS_FOO
DEBUG
TRACE
NETCOREAPP1_0

Actual behavior

When running the output of dotnet build:

IS_FOO
DEBUG
TRACE
NETCOREAPP1_0

When running the output of dotnet build3:

DEBUG
TRACE

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview3-003830)

Product Information:
 Version:            1.0.0-preview3-003830
 Commit SHA-1 hash:  90a51bdd00

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

[eerhardt]

The reason IS_FOO isn't defined in your project is because of your condition:

  <PropertyGroup Condition=" '$(TargetFrameworkIdentifier),Version=$(TargetFrameworkVersion)' == '.NETCoreApp,Version=v1.0' ">
    <DefineConstants>$(DefineConstants);IS_FOO;NETCOREAPP1_0</DefineConstants>

You aren't setting the properties $(TargetFrameworkIdentifier) and $(TargetFrameworkVersion). And those properties aren't set until the .targets file is loaded, so you can't use them in conditions. Instead your condition should be '$(TargetFramework)' == 'netcoreapp1.0'.

The reason NETCOREAPP1_0 isn't defined is because of #195.

[joelverhagen]

@brthor, this condition was automatically built by dotnet migrate. Perhaps it's a migrate problem? I think last time we talked, you said these two conditions should be equivalent, right?

[srivatsn]

Yes that's one of the migrate changes that I listed here - https://github.com/dotnet/cli/issues/4330

[joelverhagen]

Make sense. Thanks!

[brthor]

This is a migrate issue. Will fix