MSBuild fails with missing target for 'net461/win7-x64'

[deonberlin]

Description

With the latest update of the Windows Runner Image Image: windows-2019 Version: 20241125.1.0

a previously running pipeline now fails with the following error for all projects creating an executable (here WinExe net473, x64)

##[error]C:\Program Files\dotnet\sdk\6.0.203\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5): Error NETSDK1047: Assets file 'D:\a\1\s\WpfApp\obj\project.assets.json' doesn't have a target for 'net461/win7-x64'. Ensure that restore has run and that you have included 'net461' in the TargetFrameworks for your project. You may also need to include 'win7-x64' in your project's RuntimeIdentifiers.

the same worked fine with Image: windows-2019 Version: 20241021.1.0

the only workaround seams to be to specify <RuntimeIdentifier>win7-x64</RuntimeIdentifier> within the project. This was not necessary before.

See also: https://developercommunity.visualstudio.com/t/Build-failes-with-missing-RuntimeIdentif/10801032?viewtype=all

Platforms affected

• [X] Azure DevOps
• [ ] GitHub Actions - Standard Runners
• [ ] GitHub Actions - Larger Runners

Runner images affected

• [ ] Ubuntu 20.04
• [ ] Ubuntu 22.04
• [ ] Ubuntu 24.04
• [ ] macOS 12
• [ ] macOS 13
• [ ] macOS 13 Arm64
• [ ] macOS 14
• [ ] macOS 14 Arm64
• [ ] macOS 15
• [ ] macOS 15 Arm64
• [X] Windows Server 2019
• [ ] Windows Server 2022

Image version and build link

Image: windows-2019 Version: 20241125.1.0

Is it regression?

Yes, working with 20241021.1.0

Expected behavior

Projects with an output type of WinExe should build successfully.

Actual behavior

Projects with an output type of WinExe fail to build with:

Files\dotnet\sdk\6.0.203\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5): Error NETSDK1047: Assets file 'D:\a\1\s\WpfApp\obj\project.assets.json' doesn't have a target for 'net461/win7-x64'. Ensure that restore has run and that you have included 'net461' in the TargetFrameworks for your project. You may also need to include 'win7-x64' in your project's RuntimeIdentifiers.

Repro steps

Run the attached yaml pipeline for the project. AzurePipelineIssue.zip

[RaviAkshintala]

Hi @deonberlin Thank you for bringing this issue to our attention. We are looking into this issue and will update you on this issue after investigating

[Prabhatkumar59]

Hi @deonberlin - As I can observe from your issue description that the issue is mainly caused by the runtime identifier win7-x64.

For the above, could you please try to:- Add <RuntimeIdentifiers>win7-x64</RuntimeIdentifiers> to the .csproj file:-

<PropertyGroup>
  <RuntimeIdentifiers>win7-x64</RuntimeIdentifiers>
</PropertyGroup>

It gives the required runtime (win7-x64) which is explicitly included during the restore phase.

Also, could you please try to update the YAML pipeline to pass --runtime win7-x64 in the restore step and check if it works with below:-

- task: DotNetCoreCLI@2
  displayName: 'dotnet restore with RuntimeIdentifier'
  inputs:
    command: restore
    projects: '$(solution)'
    verbosityRestore: 'Minimal'
    arguments: '--runtime win7-x64'

It provides the required runtime identifier which is included for all projects during the restore phase. Please trying this once and feel free to update me, in mean time i will check more into this. Thanks!

[deonberlin]

@Prabhatkumar59 As I've already stated in the description of the issue

the only workaround seams to be to specify win7-x64 within the project. This was not necessary before.

So, yes this is how we workaround currently.

I reported the issue, as this seams to be a breaking change for older piplines. I was not able to find a breaking change note in that regard on the .Net 9.0 release notes, but may have missed it.

[Prabhatkumar59]

Hi @deonberlin - Thank you for clarifying. Based on your input, this behavior does appear to be a breaking change introduced either by the new runner image or the .NET SDK. We will check on this and will update you soon.

[Prabhatkumar59]

Hi @deonberlin - As the latest image version has been rolled out. Please update your sync process and try using the new version(20241211.1) and check once. Let us know if you encounter any further issues. Thanks!


[Prabhatkumar59]

Hi @deonberlin - Since we haven't heard back, we'll assume your issue is resolved and will close this issue for now. Feel free to reach out to us for any other queries. Thanks.