search

dotnet / msbuild

The Microsoft Build Engine (MSBuild) is the build platform for .NET and Visual Studio.
https://docs.microsoft.com/visualstudio/msbuild/msbuild
MIT License
5.21k stars 1.35k forks source link

Disambiguate TargetFrameworkVersion and TargetFamework in help #1805

Open am11 opened 7 years ago

am11 commented 7 years ago

(moved from dotnet/cli#5921)

The command line help suggests:

:: v1.6 is .NET Standard TFM
dotnet pack /p:TargetFrameworkVersion=v1.6 .

should work, however it errors out. Whereas TargetFramework switch does work:

dotnet pack /p:TargetFramework=v1.6 .

The ask is to clarify the difference in help (perhaps with a core-specific example):

dotnet msbuild -h
[snip]
        MSBuild MyApp.csproj /t:Clean
                             /p:Configuration=Debug;TargetFrameworkVersion=v3.5
::                                                   ^^^^^^^^^^  this one
rainersigwald commented 7 years ago

Oh, that is confusing: one of the command-line examples given in MSBuild's help uses TargetFrameworkVersion, which was fine for non-Core Sdk projects building only for versions of the full framework, but is definitely confusing in the new world (and when passed out through dotnet msbuild -h, for example).

I think the best thing to do is just not use TargetFramework{anything} in the example. It's useful to specify two properties to show the syntax for that, though. Maybe go fully generic and specify something like EnableFeatureX=true?

am11 commented 7 years ago

@rainersigwald, I agree that it should probably be a neutral property such as EnableFeatureX=true or perhaps even more templated form:

/p:Configuration=Debug;<key1>=<value1>;<key2>=<value2>

I tried to find some project-type-neutral property besides Configuration at https://msdn.microsoft.com/en-us/library/bb629394.aspx, but AFAIK -- as opposed what is documented there, OutputPath has no affect in vcxproj, whereas OutDir works there. Similarly OutDir is privately set in case of typical csproj and has no affect if we set it later (unless we re-invoke all the targets etc. - jeffkl/MSBuild-NetCore#2). So it's a no go. :(