PublishAOT property causes build failure when used with earlier TFMS in `TargetFrameworks` property

[agocke]

Repro:

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>net6.0;net8.0</TargetFrameworks>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

Now publish with ~/tmp/dn/dotnet.exe publish -r win-x64 -p:PublishAot=true -f net8.0

This should work because PublishAot is valid for net8.0 and we're passing -f net8.0 to only target that TFM. But it appears at least some logic is being executed for net6.0 regardless.

This will also fail if you place PublishAot in the project file unconditionally and then run publish --sc -r win-x64 -f net8.0.

In both of these cases, we should somehow guard against the PublishAot flag being propagated through in unsupported TFMs, or fix framework targeting to run no logic for alternate TFMs when specified with -f.

[agocke]

@jtschuster Could you investigate and figure out the details of exactly why this is failing? My suspicion is that -f somehow doesn't prevent restore from happening for other TFMs, but it would be good to confirm that that is the case.

[jtschuster]

For the first repro:

Restore depends on _GenerateRestoreGraph
which runs _GenerateProjectRestoreGraph as an msbuild task,
which depends on _GenerateRestoreDependencies,
which depend on _GenerateRestoreGraphAllFrameworks (which runs because TargetFrameworks != ''),
which runs _GeneratePorjectRestoreGraphPerFramework with TargetFramework=net6.0 and PublishAOT=true
which runs CollectPackageReferences as a dependency,
which runs ProcessFrameworkReferences target as a dependency
which calls ProcessFrameworkReferences with TFM=6.0 and AOTEnabled=true
which causes the error

The naïve solution would be to add a condition to avoid running _GenerateRestoreGraphAllFrameworks if TargetFramework != '', but I’m not sure if that would break other things.

[sbomer]

It sounds like restore is designed to restore for all TFMs in the project. Since we are restoring parts of ILComplier as a packagereference, maybe the fix is to add a TFM condition on the packagereference here?

sdk/src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs

Lines 694 to 696 in 37d204c

	var buildPackage = new TaskItem(buildPackageName);
	buildPackage.SetMetadata(MetadataKeys.Version, packVersion);
	implicitPackageReferences.Add(buildPackage);

[agocke]

maybe the fix is to add a TFM condition on the packagereference here

I would be OK with this, but it does feel like _GenerateRestoreGraphAllFrameworks shouldn't necessarily be running in this case. I wonder how build works such that it only runs for one TFM.

[sbomer]

Are we sure that build doesn't have the same behavior (restore for all TFMs, even if only one TFM is requested to build)?

[jtschuster]

Don't build and publish just depend on restore? And the same behavior should happen for restore regardless of whether you're building or publishing?

Restore will still error for 'dotnet build' in this repro at least

[agocke]

Are we sure that build doesn't have the same behavior (restore for all TFMs, even if only one TFM is requested to build)?

Right, I'm sure they do -- but why doesn't build run for every TFM when -f is passed? I assume there's some conditional logic somewhere, but I don't know what it is. If we could find it and replicate it in restore, it might naturally solve this problem, and potentially other problems related to multi-target restore.

[sbomer]

If we could find it and replicate it in restore, it might naturally solve this problem, and potentially other problems related to multi-target restore.

Ah, now I see what you're asking. I am assuming that restore-for-all-TFMs is by design (perhaps it helps with restore, followed by offline development+build). I would check with SDK owners before trying to change that.

@dsplaisted maybe you know - is it by design that restoring as part of build/publish for a particular TFM restores for all TFMs? And what's the reason for this behavior?

[dsplaisted]

The behavior is by design. The idea is that you could have multiple TargetFrameworks in the project file indicating all the possible frameworks you could target, but during build or publish you might want to only select one (indeed, for publish I believe you have to specify a target framework for multi-targeted projects). If restore were to use the specified TargetFramework, then a full restore would have to run each time you built or published for a different target framework. To avoid that, the implicit restore ignores the -f parameter.

This does not always lead to desirable behavior, so we might think about changing the design. I believe this is related to #21877. Also, I couldn't find the issue right now, but it prevents you from specifying a TargetFramework via the -f parameter if that TargetFramework isn't already listed in the project file.