ProjectReference Platform Negotiation - Platform Not Set

[jhennessey]

I'm trying to make use of the new ProjectReference SetPlatform Negotiation feature. After performing all of the documented steps to enable the feature, I could not get a simplistic two project (non-SDK style) build to work correctly. In this case, NetFx.Library2 (x86/x64) referenced NetFx.Library1 (AnyCPU). When attempting to build, it would result with the following error:

(_CheckForInvalidConfigurationAndPlatform target) -> c:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(820 ,5): error : The BaseOutputPath/OutputPath property is not set for project 'NetFx.Library1.csproj'. Please check to ma ke sure that you have specified a valid combination of Configuration and Platform for this project. Configuration='Debug' Platform='x64'. You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.

After exploring the logs and associated code changes for the feature, I could see that PlatformTarget was being passed to the referenced project here. That doesn't appease the referenced project because it uses Platform for its defined configurations. However, if I change the referenced code to pass Platform (along with PlatformTarget) my build works as expected.

Is there any reason why Platform can't also be passed to the referenced projects?

#5338
#6655

Logs:
error.log
success.log

[benvillalobos]

thanks for filing this! Here's my own analysis (which agrees with yours):

Legacy style projects expect to be built with a Configuration|Platform such that you have some sort of:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
    <PlatformTarget>x64</PlatformTarget>
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\x64\</OutputPath> <======== legacy projects set outputpath based on config|platform
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>

Because x64 isn't a "previously agreed upon" platform for your referenced project, outputpath isn't being defined and thus we're hitting that issue. Presumably sdk style projects define this themselves or use the defaults we supply in common.currentversion.targets.

Some temporary workarounds would be:

• Define outputpath in your project using PlatformTarget
• Set Platform to PlatformTarget (conditioned that PT is defined) in your project file.

Part of the issue here is a distinction between Platform and PlatformTarget, ideally we wouldn't have the two properties.

of course there are many solutions we can consider for MSBuild. To brainstorm some, we could:

• Pass Platform and PlatformTarget in these P2P jumps
  • Not sure this is the right solution.
• Condition this error check such that it doesn't run when we're opted in to this feature and PlatformTarget is set
• Early on in M.B.CurrentVersion.targets, just before lines 136 to 145:

  <PropertyGroup>
    <!-- Example, AnyCPU -->
    <_OriginalPlatform>$(Platform)</_OriginalPlatform>
    <!-- Example, Debug -->
    <_OriginalConfiguration>$(Configuration)</_OriginalConfiguration>
    <!-- Check whether OutputPath was specified for valid Configuration/Platform combination -->
    <_OutputPathWasMissing Condition="'$(_OriginalPlatform)' != '' and '$(_OriginalConfiguration)' != '' and '$(OutputPath)' == ''">true</_OutputPathWasMissing>
    <!-- Check whether BaseOutputPath was specified -->
    <BaseOutputPathWasSpecified Condition="'$(BaseOutputPath)' != ''">true</BaseOutputPathWasSpecified>
  </PropertyGroup>

We can add something like:

  <PropertyGroup>
    <Platform Condition="opted into platform negotiation AND platformtarget is not empty">$(PlatformTarget)</Platform>
  </PropertyGroup>

^ I'm leaning toward this. It also reduces the separation between the two properties. @rainersigwald thoughts?

@AArnott Do you expect to see the VS migration running into this?

[AArnott]

I don't think setting OutputPath based on PlatformTarget is the right approach here in any case. That's just the immediate symptom, but all the properties in that property group need to be set.
I don't know enough project types to be sure, but I'll offer that Platform is the property that I think most/everyone sets, including the Azure Pipelines VSBuild task when you set the platform on one of the task parameters. At the moment, I can't remember why we set the PlatformTarget global property at all if we can set Platform directly. At least for these older style projects, Platform drives PlatformTarget -- not the other way around. So while I like the idea of bringing these two properties closer together, and your proposed fix does that, it leaves Platform now being driven by PlatformTarget which is backwards of precedent.
Also, by adding this proposed PropertyGroup to the common.targets file, Platform is set after the project file in evaluation order which wouldn't cause the right property groups in the project file to be included because by then it's too late. Putting the change into a .props file wouldn't work either because many of these projects don't import anything at the top of their file.

[benvillalobos]

Thanks for the reply.

Pass Platform and PlatformTarget in these P2P jumps

Sounds like this is the way to go then. I need to re-investigate why I ultimately decided PlatformTarget was the property to pass. I recall it had to do with the SDK and inputs to the csc task.

[benvillalobos]

Investigation notes:

PlatformTarget is passed to the compiler and AL task in M.C.CV.targets and does not define PlatformTarget. PlatformTarget being passed to these tasks has existed for 5+ years now, so PlatformTarget isn't a "recent" concept. The fact that it's defined in these older projects (based on configuration|platform) proves that it needs to be defined either in the project, or in some props/targets file before CoreCompile runs (from the Roslyn targets).

This answers how PlatformTarget is set & used in legacy-style projects: Platform defines the PlatformTarget in the project when building under a particular Configuration|Platform. This means any referenced project in a P2P that's legacy style must define a valid Configuration|Platform propertygroup that defines a value for OutputPath and PlatformTarget, among any other values that are needed that I may be missing.

What about sdk-style projects?

I found this in Microsoft.NET.Sdk.props

  <!--
    NOTE:

     * We cannot compare against $(Platform) directly as that will give VS cause to instantiate extra
       configurations, for each combination, which leads to performance problems and clutter in the sln
       in the common AnyCPU-only case.

     * We cannot just set $(PlatformTarget) to $(Platform) here because $(Platform) can be set to anything
       at the solution level, but there are a fixed set valid $(PlatformTarget) values that can be passed
       to the compiler. It is up to the user to explicitly set PlatformTarget to non-AnyCPU (if desired)
       outside the 1:1 defaults below.
  -->
  <PropertyGroup>
    <_PlatformWithoutConfigurationInference>$(Platform)</_PlatformWithoutConfigurationInference>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(_PlatformWithoutConfigurationInference)' == 'x64' ">
    <PlatformTarget Condition=" '$(PlatformTarget)' == '' ">x64</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(_PlatformWithoutConfigurationInference)' == 'x86' ">
    <PlatformTarget Condition=" '$(PlatformTarget)' == '' ">x86</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(_PlatformWithoutConfigurationInference)' == 'ARM' ">
    <PlatformTarget Condition=" '$(PlatformTarget)' == '' ">ARM</PlatformTarget>
  </PropertyGroup>

It looks like PlatformTarget is set based on Platform, but doesn't have a definition when Platform is AnyCPU. What happens when Platform is AnyCPU then?

The following snippet looks to answer my question. It defaults PlatformTarget in Microsoft.NET.RuntimeIdentifierInference.targets:

  <!-- Determine PlatformTarget (if not already set) from runtime identifier. -->
  <Choose>
    <When Condition="'$(PlatformTarget)' != '' or '$(RuntimeIdentifier)' == ''" />

    <When Condition="$(RuntimeIdentifier.EndsWith('-x86')) or $(RuntimeIdentifier.Contains('-x86-'))">
      <PropertyGroup>
        <PlatformTarget>x86</PlatformTarget>
      </PropertyGroup>
    </When>

    <When Condition="$(RuntimeIdentifier.EndsWith('-x64')) or $(RuntimeIdentifier.Contains('-x64-'))">
      <PropertyGroup>
        <PlatformTarget>x64</PlatformTarget>
      </PropertyGroup>
    </When>

    <When Condition="$(RuntimeIdentifier.EndsWith('-arm')) or $(RuntimeIdentifier.Contains('-arm-'))">
      <PropertyGroup>
        <PlatformTarget>arm</PlatformTarget>
      </PropertyGroup>
    </When>

    <When Condition="$(RuntimeIdentifier.EndsWith('-arm64')) or $(RuntimeIdentifier.Contains('-arm64-'))">
      <PropertyGroup>
        <PlatformTarget>arm64</PlatformTarget>
      </PropertyGroup>
    </When>

    <Otherwise>
      <PropertyGroup>
        <PlatformTarget>AnyCPU</PlatformTarget>
      </PropertyGroup>
    </Otherwise>
  </Choose>

And to confirm order of imports, Microsoft.NET.RuntimeIdentifierInference.targets is imported before M.C.CV.targets

My last question at this point: If PlatformTarget is defined based off of RuntimeIdentifier at this point, where is RuntimeIdentifier defined? I couldn't find it easily. @dsplaisted do you know more about how it's defined? And does my analysis check out with how things work today?

Regardless, I think this answers my question for sdk-style projects: PlatformTarget is defined based on specific values of Platform and RuntimeIdentifier. And defaulted to AnyCPU when Platform isn't a predetermined value, or it couldn't be parsed from the RID.

Thanks for coming to my TED talk :)

[dsplaisted]

Your analysis looks correct.

RuntimeIdentifier is usually set in the project file, or as a command-line parameter to a dotnet command. There may be some cases where it is also set implicitly (I think WASM, iOS, and Android might do this).

[AArnott]

RuntimeIdentifier is usually set in the project file

I would suggest a slight alteration: it is usually not set anywhere. But some projects (usually apps) set RuntimeIdentifier (or RuntimeIdentifiers plural) in the project file.
At least, that's been my experience.

In fact I've seen some otherwise "Platform: anycpu" projects use RuntimeIdentifier to target a specific CPU architecture without changing Platform from AnyCPU at all. I don't feel great about that pattern, but it's in use. So that would mean Platform is AnyCPU and PlatformTarget is x64/x86/etc when these projects build today. Maybe we call that illegal when you opt-in to platform negotiation. Any better ideas?

[benvillalobos]

@jhennessey can you confirm that adding <Platform Condition="'$(Platform)' == '' and '$(PlatformTarget)' != ''">$(PlatformTarget)</Platform> in a Directory.Build.props file at the root of your repo works as a temporary workaround for you? That, or adding it near the top of your failing project file.

[jhennessey]

I figured it would be worth mentioning that I was able to successfully build a very large project (150+ projects) containing a mix of non-SDK and SDK-style projects by only passing Platform (and NOT PlatformTarget). The main project is an ASP.NET (legacy, not Core) application. It was really cool to be able to build it without a solution file!

(Also, I appreciate all the time and thoughts people have contributed thus far...thanks :)).

Edit:
I should note that in order to accomplish this without directly modifying Microsoft.Common.CurrentVersion.targets, I added a target to a Directory.Build.targets file with the following target:

  <Target Name="SetProjectReferencePlatformsEx" AfterTargets="_GetProjectReferencePlatformProperties" 
          Condition="'$(EnableDynamicPlatformResolution)' == 'true'
                     and '$(BuildingInsideVisualStudio)' != 'true'
                     and '@(_MSBuildProjectReferenceExistent)' != ''">
    <ItemGroup>
      <_MSBuildProjectReferenceExistent Condition="'%(_MSBuildProjectReferenceExistent.SkipGetPlatformProperties)' != 'true' And '%(NearestPlatform)' != ''">
        <SetPlatform>Platform=%(_MSBuildProjectReferenceExistent.NearestPlatform)</SetPlatform>
      </_MSBuildProjectReferenceExistent>
    </ItemGroup>
  </Target>

The reason I chose not to pass PlatformTarget was just incase any of the projects were doing anything funky with that property. But everything worked just fine when including both.

[benvillalobos]

The issue is that I am passing Platform=x64 on the command-line
Gotcha, and that would be a fairly common scenario for users. I'll be working on a fix that will start passing Platform= instead of PlatformTarget=.

I figured it would be worth mentioning that I was able to successfully build a very large project (150+ projects) containing a mix of non-SDK and SDK-style projects by only passing Platform (and NOT PlatformTarget)

❤️❤️❤️❤️ yes!!! Great to know that it works! I'd say a 150+ project build that only modifies passing Platform= instead of PlatformTarget= is a good test suite 😁

Edit:

Thanks for including your workaround. That should be sufficient for other users running into this.

[jhennessey]

I'll be working on a fix that will start passing Platform= instead of PlatformTarget=.

Awesome, looking forward to testing it :). Many thanks!

[jhennessey]

@benvillalobos - Should I just create an issue from this discussion or did you have one already?

[benvillalobos]

I'll go ahead and hit the button.

[jhennessey]

This problem is being addressed by issue #6887. See discussion above for a work-around in the meantime.