Can only specify the first target in .sln with -target:

[mensinda]

Issue Description

Manually selecting all targets (with -target:<tgt>), except the first defined in the .sln file, fails. Here is the relevant part of the .sln file of our test case:

Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2019
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "mylib@sha", "mylib@sha.vcxproj", "{8EFF312E-4085-49DC-86FA-49BEEE91A62D}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "prog@exe", "prog@exe.vcxproj", "{C1DFC6DA-2639-4F2A-8A24-F8954D1A0B14}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "mycpplib@sha", "mycpplib@sha.vcxproj", "{9ABCE8FB-2DA3-42AC-87B1-5B5D7E8E8445}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "cppprog@exe", "cppprog@exe.vcxproj", "{EBFC5EC3-8620-4B68-BADD-33A5D68FDD5F}"
EndProject
# Some more lines ...

Steps to Reproduce

Our failing test case: 6 linkshared.zip.

Run:

msbuild -target:mylib_sha    '.\build\shared library linking test.sln'   # Works
msbuild -target:mycpplib_sha '.\build\shared library linking test.sln'   # Fails

Expected Behavior

Both commands succeed.

Actual Behavior

Only the first command works. Running the second command generates error MSB4057: The target "mycpplib_sha" does not exist in the project. errors.

Analysis

Removing the first two Project() calls causes the second msbuild call to suddenly work, thus it is likely that the first target in the .sln file can be specified with -target.

Versions & Configurations

• msbuild -version: 16.10.0.26302

The .sln file was generated by meson in our Azure CI. See mesonbuild/meson#8512 (comment) for some more details.

[jimporter]

I see this issue too (interestingly enough, meson and my project are doing about the same thing: testing generated project files from a higher-level build system).

After debugging this for a while, it seems that this issue only applies to the command-line invocation of msbuild. Running from within Visual Studio works as expected in all cases (at least, all the cases I could think of). From some searching, I gather this is because VS doesn't actually use the command-line msbuild, and instead invokes it programmatically (via a library).

[VonOgre]

I'm seeing this too, and it seems possibly related to #5722 as well.

You get pretty wildly different Metaproj generation when specifying either the first target, as noted in this issue, or no target at all

<Target Name="Installer\Project_Product" Outputs="@(Installer_Project_ProductBuildOutput)">
    <MSBuild Condition="'%(ProjectReference.Identity)' == 'C:\Projects\Product\Tools\Project.Product.HQ\Project.Product.HQ.CustomAction\Project.Product.HQ.CustomAction.csproj'" ToolsVersion="$(ProjectToolsVersion)" BuildInParallel="True" Projects="@(ProjectReference)" Properties="Configuration=Debug; Platform=x86;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)">
      <Output TaskParameter="TargetOutputs" ItemName="Installer_Project_ProductBuildOutput" />
    </MSBuild>
</Target>

vs if you specify any of the later targets (e.g. msbuild project.sln /t:Installer\Project_Product):

<Target Name="Installer\Project_Product">
	<MSBuild BuildInParallel="True" SkipNonexistentProjects="%(ProjectReference.SkipNonexistentProjects)" Projects="@(ProjectReference)" Targets="Installer\Project_Product" Properties="BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)" />
</Target>

I referenced #5722 because, interestingly enough, msbuild project.sln /t:Installer\Project_Product:Clean and msbuild project.sln /t:Installer\Project_Product:Rebuild still function just fine

[rainersigwald]

I think this is a more interesting manifestation of the bug behind #6373. The fix will go out with VS 16.10.1 ASAP.