Sdk: dotnet build3: case of -f (framework) parameter defines case, not project

[joelverhagen]

Steps to reproduce

1. dotnet new
2. dotnet restore3
3. dotnet build3 -f NETCOREAPP1.0
   

   Expected

Artifacts on disk should match TFM case in the project file.

Actual

 Volume in drive C has no label.
 Volume Serial Number is 3487-F055

 Directory of C:\Users\jver\Desktop\reprocase\bin\Debug

10/17/2016  07:28 PM    <DIR>          .
10/17/2016  07:28 PM    <DIR>          ..
10/17/2016  07:28 PM    <DIR>          NETCOREAPP1.0
               0 File(s)              0 bytes

Environment

Microsoft.NET.Sdk/1.0.0-alpha-20161012-3

dotnet --info

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

Product Information:
 Version:            1.0.0-preview3-003857
 Commit SHA-1 hash:  060762090d

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

[nguerrera]

This is not easy to fix. -f X is just /p:TargetFramework=X and then in msbuild we can't distinguish between user having spelled it that way or it having been supplied as global property.

I think the easiest thing would be to handle it in the CLI:

• -f [anything] would be deemed invalid if project has only singluar TargetFramework
• -f X would be invalid if it doesn't match one of the plural TargetFrameworks (ignoring case)
• -f X would adjust the case of TargetFramework to match plural TargetFrameworks if there's a casing difference

Handling this in msbuild is very tough because we have to set the output path statically in the inner build.

Another approach would be for -f to pass the desired target framework using a different property and then still have an outer build that validated the property, normalized the case and dispatched to an inner build with the normalized TargetFramework. This would still not catch errors if someone used msbuild /p:TargetFramework=X instead msbuild /p:SomeOtherWayToSayWhichTargetFramework=X so I'm not sure it buys anything.

[nguerrera]

@piotrpMSFT @livarcocc What do you think about handling this validation and normalization of case in the CLI layer?

@joelverhagen Would you be satisfied if msbuild /p:TargetFramework=X had the current behaviour but dotnet -f X did what you want?

[TheRealPiotrP]

This seems like it would be a big perf hit for the CLI. It would mean that any command which accepts a framework would require a design-time evaluation of the project. It also would not address the generalized case. As @nguerrera says, CLI just passes through to msbuild /p:TargetFramework which can be invoked directly from the cmd line, etc...

/cc @blackdwarf

[nguerrera]

I'm not seeing an msbuild solution that's efficient or even robust. Can we just live with this?

[blackdwarf]

Guys, why don't we just ToLower the -f parameter? We know that TFMs are mostly lower-case, right?

[nguerrera]

Lol, ya. That works.

[nguerrera]

We can tolower the target framework portion of the output dir in msbuild, then everybody gets sane behaviour.

[blackdwarf]

This seems like the easiest solution without impacting the perf (doing an eval build). We all agreed? :)