Get the renamed Platform passed in from command-line

[goyzhang]

Steps to reproduce

It is allowed to renamed a platform from "AnyCPU, x86, x64" to a customized name for a solution, such that we can build with a specific platform with command like:

msbuild MSBuildTests.sln -p:Platform=MyPlatform1;Configuration=MyConfig1

We can get MyConfig1 from $(Configuration) in a .csproj, However, there is no way to get the MyPlatform1 argument from $(Platform) as it is overwritten by x64 (assume it is renamed from x64).

There should be a way to get the renamed platform that passed in from command-line when we build on a .sln. Or we already have it?

Project file

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <Platforms>AnyCPU;x64</Platforms>
  </PropertyGroup>

  <Target Name="GetRenamedPlatform">
    <Message Text="$(Platform)" /> <!--this will print x64-->
  </Target>

</Project>

Directory contents:

/
- MSBuildTests.sln
- MSbuildTests/
     - c.cs
     - MSBuildTests.csproj

Command line

`msbuild MSbuildTests.sln -p:platform=MyPlatform1 -t:GetRenamedPlatform`

Expected behavior

Print "MyPlatform1"

Actual behavior

Print "x64"

Environment data

msbuild /version output:
Microsoft (R) Build Engine version 16.2.37902+b5aaefc9f for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.2.37902.0

[livarcocc]

Can you share what your solution looks like? I imagine that's where you did the platform customization?

[goyzhang]

Can you share what your solution looks like? I imagine that's where you did the platform customization?

Sure, actually I rename the platform from VS:

And the .sln, it feels like the platform passed in is mapped by some build target and I have no way to get it back:

Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio Version 16
VisualStudioVersion = 16.0.29306.81
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MSBuildFwTests", "MSBuildFwTests\MSBuildFwTests.csproj", "{5BA681DD-D19F-46EE-BB9C-469D3728F81B}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "MSbuildTests", "MSbuildTests\MSbuildTests.csproj", "{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}"
EndProject
Global
	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Any CPU = Debug|Any CPU
		Debug|MyPlatform1 = Debug|MyPlatform1
		Release|Any CPU = Release|Any CPU
		Release|MyPlatform1 = Release|MyPlatform1
	EndGlobalSection
	GlobalSection(ProjectConfigurationPlatforms) = postSolution
		{5BA681DD-D19F-46EE-BB9C-469D3728F81B}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
		{5BA681DD-D19F-46EE-BB9C-469D3728F81B}.Debug|Any CPU.Build.0 = Debug|Any CPU
		{5BA681DD-D19F-46EE-BB9C-469D3728F81B}.Debug|MyPlatform1.ActiveCfg = Debug|Any CPU
		{5BA681DD-D19F-46EE-BB9C-469D3728F81B}.Release|Any CPU.ActiveCfg = Release|Any CPU
		{5BA681DD-D19F-46EE-BB9C-469D3728F81B}.Release|Any CPU.Build.0 = Release|Any CPU
		{5BA681DD-D19F-46EE-BB9C-469D3728F81B}.Release|MyPlatform1.ActiveCfg = Release|Any CPU
		{5BA681DD-D19F-46EE-BB9C-469D3728F81B}.Release|MyPlatform1.Build.0 = Release|Any CPU
		{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
		{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}.Debug|Any CPU.Build.0 = Debug|Any CPU
		{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}.Debug|MyPlatform1.ActiveCfg = Debug|x64
		{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}.Debug|MyPlatform1.Build.0 = Debug|x64
		{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}.Release|Any CPU.ActiveCfg = Release|Any CPU
		{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}.Release|Any CPU.Build.0 = Release|Any CPU
		{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}.Release|MyPlatform1.ActiveCfg = Release|x64
		{7BA15D6D-C27F-4F98-B6A2-A53CDF150223}.Release|MyPlatform1.Build.0 = Release|x64
	EndGlobalSection
	GlobalSection(SolutionProperties) = preSolution
		HideSolutionNode = FALSE
	EndGlobalSection
	GlobalSection(ExtensibilityGlobals) = postSolution
		SolutionGuid = {E3CCA812-786C-4A45-BD6B-F4C8D79DA7F0}
	EndGlobalSection
EndGlobal

[kaylumah]

Any update on this?

[wouterroos]

@goyzhang @kaylumah If I remember correctly from past endeavours, the $(Platform) argument points to the active project platform and not the solution platform (which are two different things) when used in a project file. The way MSBuild works when building a solution from the command line is that it will build every project with the project platform selected for the active solution platform (Specified in the *.sln file and can be configured using the Configuration Manager in Visual Studio, see images below for examples). It is possible to create solution platforms with custom names, this is not true for project platforms.

I agree that it is very confusing that the /p:Platform argument is used to specify the solution platform when invoking msbuild.exe and would love to see a proper solution that fixes this issue and allows you to use both the project and solution configuration names in a project file.

A property called $(SolutionPlatform) comes to mind as an obvious solution, but should be assumed optional since a project can also be built outside the context of a solution.

[kaylumah]

@rainersigwald @cdmihai apologies for this direct approach, but according to https://github.com/dotnet/msbuild/graphs/contributors you are the top contributors to this repo and might help route this issue to the appropriate people :-)

As a workaround can you perhaps suggest a way that works via both the command line and visual studio?
For example, when building via command line I can do msbuild mysln.sln /p:CustomProp=MyPlatform but this would not work in Visual Studio

[kaylumah]

Interestingly enough using before.slnname.sln.targets I get the correct platform, but again that is a version that does not work in both scenarios :(

<Project InitialTargets="CaptureCustomPlatform">
<Project>
    <Target Name="CaptureCustomPlatform">
        <Message Importance="High" Text="CaptureCustomPlatform-Platform:$(Platform)" />
        <PropertyGroup>
            <CustomPlatform>$(Platform)</CustomPlatform>
        </PropertyGroup>
        <Message Importance="High" Text="CaptureCustomPlatform-CustomPlatform: $(CustomPlatform)" />
    </Target>
</Project>

PS
Used set MSBuildEmitSolution=1 && dotnet build Demo.sln to figure this out. It creates a file that shows how MSBuild imports the sln. It showed that very briefly the Platform is my custom value before its rewritten later in that file

[kaylumah]

After a quick chat with @KirillOsenkov via Twitter here is our sample case.
Note: sln will not build because it contains nuget packages that are not publicly available but the concept will be clear without building.

So from Visual Studio you can see the following configuration:

Which matches our sln file

	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug|Azure.ServiceFabric = Debug|Azure.ServiceFabric
		Debug|DotNet.ServiceFabric = Debug|DotNet.ServiceFabric
		Release|Azure.ServiceFabric = Release|Azure.ServiceFabric
		Release|DotNet.ServiceFabric = Release|DotNet.ServiceFabric

Building with set MSBuildEmitSolution=1 && dotnet build Demo.sln I got which actually captures

  <PropertyGroup Condition=" '$(Platform)' == '' ">
    <Platform>Azure.ServiceFabric</Platform>
  </PropertyGroup>

So I attempted to capture the value with the use of

Directory.Solution.props

<Project InitialTargets="CapturePlatformBeforeRewrite">
    <Target Name="CapturePlatformBeforeRewrite">
        <Message Importance="High" Text="Initial Platform $(Platform)" />
        <PropertyGroup>
            <CopperPlatform>$(Platform)</CopperPlatform>
        </PropertyGroup>
        <Message Importance="High" Text="Captured Platform $(CopperPlatform)" />
    </Target>
</Project>

Which works, but does not make CopperPlatform available for use in other projects.

Finally when looking for example at Demo\Component\Access\Solution\Hosting\Demo.Access.Solution.Hosting.csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework Condition="'$(Platform)' == 'x64'">netcoreapp3.1</TargetFramework>
    <TargetFrameworks>netcoreapp3.1</TargetFrameworks>
    <IsPackable>false</IsPackable>
    <Platforms>AnyCPU;x64</Platforms>
    <Configurations>Debug;Release</Configurations>
    <OutputType Condition="'$(Platform)' == 'x64'">Exe</OutputType>
    <DefaultItemExcludes Condition="'$(Platform)' == 'AnyCPU'">PackageRoot/**</DefaultItemExcludes>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Copper.Conventions.Method.Service.DotNet.ServiceFabric" Version="3.0.512" Condition="'$(Platform)' == 'AnyCPU'" />
    <PackageReference Include="Copper.Conventions.Method.Service.Azure.ServiceFabric" Version="3.0.512" Condition="'$(Platform)' == 'x64'" />
  </ItemGroup>
  <ItemGroup>
    <ProjectReference Include="..\Service\Demo.Access.Solution.Service.csproj" />
    <ProjectReference Include="..\..\..\..\Utilities\Demo.Utilities.csproj" />
  </ItemGroup>
  <ItemGroup>
    <Content Include="V1\Demo.Access.Solution.Local_RabbitMQ.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
  </ItemGroup>
  <UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" Condition="'$(Platform)' == 'x64'" />
  <Target Name="TransformServiceManifest" AfterTargets="Build" Condition="'$(Platform)' == 'x64'">
    <TransformXml Source="PackageRoot\ServiceManifest.xml" Transform="PackageRoot\ServiceManifest.Local.1Node.Transform.xml" Destination="PackageRoot\ServiceManifest.Local.1Node.xml" />
    <TransformXml Source="PackageRoot\ServiceManifest.xml" Transform="PackageRoot\ServiceManifest.Local.5Node.Transform.xml" Destination="PackageRoot\ServiceManifest.Local.5Node.xml" />
  </Target>
  <Target Name="ECM" AfterTargets="Build">
    <Message Importance="high" Text="$(Platform)" />
  </Target>
</Project>

I know do things based on $(Platform) which works currently in our model because we support one x64 model and one anycpu model. This is going to change to 3 different variants.

So ideally something like Wouter proposes SolutionPlatform would work great, and only be applied in context of building SLN.

Not sure if VS also generates that metaproj file, but perhaps it is a way to capture it.

So I guess main issue is to get it working in VisualStudio since MSBuild via commandline would also work by passing a variable. So if you have any suggestions regarding a workaround for that, or can help me route this to the proper team that would be of great help.

Demo.zip

Please hit me up with any questions.
@goyzhang do you still have your repo case? Problem seems similar and usecase less complex then ours. Perhaps ou can share it too?

[KirillOsenkov]

I suggest filing an issue at https://github.com/dotnet/project-system/issues/new and linking here, that would be for Visual Studio support. You can ask them what are the current limitations to support this scenario.

[KirillOsenkov]

Keep this issue for MSBuild support

[rainersigwald]

I don't think I understand the use case here. Why do you care about the solution platform when you're inside a project?

It's generally a bad idea to have behavior inside a project that differs based on solution-level details. It means that building the project directly will have different behavior to the should-be-identical build through a solution.

[kaylumah]

@rainersigwald 99% of our project it does not matter indeed. We do have a small bit that determines how we can run (for example locally vs as a service fabric application).

The original point of goyzhang is still valid though msbuild MSbuildTests.sln -p:platform=MyPlatform1 -t:GetRenamedPlatform should not overwrite it to AnyCPU.

If you have other suggestions to tackle this I am al ears.
Should:

• Ideally, be single solution so users have single entry point
• build via commandline (passing argument like -p:platform or something custom is acceptable
• build in visualstudio.

In our case, we generally don't build single projects and only solutions. But you are of course correct that would impact single project build and that we would then need for example to pass extra arguments :)

[KirillOsenkov]

I'm guessing they want a custom dimension, such as a TargetFramework? I think @jasonmalinowski was asking about a similar thing the other day.