/AZP run

3.0-nanoserver-1809-arm32v7 CI failure needs investigating.

Executing: docker run --name 3.0-pwsh-132040527741407978 --rm -p 80 mcr.microsoft.com/dotnet/core-nightly/sdk:3.0-nanoserver-1809-arm32v7 pwsh -c (Get-Childitem env:DOTNET_RUNNING_IN_CONTAINER).Value
It was not possible to find any compatible framework version
The specified framework 'Microsoft.WindowsDesktop.App', version '3.0.0-preview5-27626-15' was not found.

• No frameworks were found.

@MichaelSimons Is there any action on my part? We do not directly reference the package.

@adityapatwardhan - Can you update the PR to pull in latest? @mthalman, if CI is still failing can you help investigate?

@MichaelSimons just rebased and pushed, can you restart CI please.

/azp run

@mthalman AzP did not start the CI due to branch triggers. Can you check.

/azp run

@mthalman AzP did not start the CI due to branch triggers. Can you check.

Working on it

@adityapatwardhan - Working through some issues with the build pipeline due to some recent changes. I'll keep working on it.

/azp run

@adityapatwardhan - The test is still failing with the same error. It's specifically failing on the nanoserver ARM test. After looking at the corresponding NuGet package you have for that platform, I found this in the pwsh.runtimeconfig.json file:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.0",
    "framework": {
      "name": "Microsoft.WindowsDesktop.App",
      "version": "3.0.0-preview5-27626-15"
    },
    "rollForwardOnNoCandidateFx": 2,
    "configProperties": {
      "System.Runtime.TieredCompilation": true,
      "System.Runtime.TieredCompilation.QuickJit": true
    }
  }
}

Comparing this to the same file in other platform configurations, it would seem that the framework name should instead be Microsoft.NETCore.App.

Can you please make that change?

@mthalman the framework part of the runtimeconfig.json is auto generated by the build. I downloaded the other nuget package for win-x64 and it has identical runtimeconfig.json. Only the linux packages have Microsoft.NETCore.App. There is a runtime package for win-arm for Microsoft.WindowsDesktop.App so it should work, right?

Adding @livarcocc to see if he can offer any insight.

Here's the summary:
A new drop of PowerShell is being included in the 3.0 SDK Docker images. This new drop is causing a failure in our tests when attempting to execute a PowerShell command on NanoServer ARM. The test runs fine on NanoServer AMD. The test failure is The specified framework 'Microsoft.WindowsDesktop.App', version '3.0.0-preview5-27626-15' was not found.

The previous version of PowerShell referenced by the SDK image was built off of 2.1 so it obviously didn't encounter this issue.

The relevant PowerShell NuGet package being included in the image can be found here: https://pwshtool.blob.core.windows.net/tool/7.0.0-preview.1/PowerShell.Windows.arm32.7.0.0-preview.1.nupkg. In that package, you can see there's a dependency on preview5. But our SDK image has preview7 installed. Again, this behaves correctly when running on the AMD architecture.

We also had seen this same behavior when the SDK image was installed with preview6.

WindowsDesktop is not supported in arm. So, that shared runtime is not going to be available there.

The only entry we have in runtimeconfig.template.json is for "rollForwardOnNoCandidateFx": 2. Everything else is generated through the build. Is there any workaround for this?

@livarcocc - How are customers supposed to handle this? If the build produces something that can't be run on Windows ARM, then that's not good unless there's a way for them to change that default behavior. Is there a way?

@mthalman cross compilation was always a feature supported by the SDK and as the SDK sees it, that's what you are doing. You are producing an application for which the platform you are running the build on does not have a runtime to.

What you need to do is change your app to not target the WindowsDesktop shared framework. If your app is not a GUI app (WinForms/WPF) why are you referencing that shared framework?

@adityapatwardhan - You made it sound like you weren't explicitly targeting WindowsDesktop. Is that correct? Can you share you project configuration with @livarcocc to resolve this?

@adityapatwardhan - Friendly poke. Did you get a chance to validate if the PS projects are targeting WindowsDesktop as @mthalman asked? .NET Core Preview 7 is rapidly approaching and getting PowerShell to v7.0.0 is a requirement.

Sorry for the late reply. We are not explicitly referencing the Microsoft.WindowsDesktop.App package.

Here is our csproj: https://github.com/PowerShell/PowerShell/blob/master/src/powershell-win-core/powershell-win-core.csproj

(Caveat - I have no experience in your repo.) It looks like it could be bought in here. Are you certain the conditions are working as expected and the rid is getting flown in when building https://pwshtool.blob.core.windows.net/tool/7.0.0-preview.1/PowerShell.Windows.arm32.7.0.0-preview.1.nupkg? Where is the code that produced the nupkgs?

Ok, we have understood the root cause of the issue. We have the following logic for deciding the SDK we want to use.

<Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" Condition="'$(RuntimeIdentifier)' == 
'win-arm' or '$(RuntimeIdentifier)' == 'win-arm64'" />
  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk" Condition="'$(RuntimeIdentifier)' == 'win-arm' or '$(RuntimeIdentifier)' == 'win-arm64'" />

  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk.WindowsDesktop" Condition="'$(RuntimeIdentifier)' != 'win-arm' and '$(RuntimeIdentifier)' != 'win-arm64'" />
  <Import Project="Sdk.targets" Sdk="Microsoft.NET.Sdk.WindowsDesktop" Condition="'$(RuntimeIdentifier)' != 'win-arm' and '$(RuntimeIdentifier)' != 'win-arm64'" />

When we build a framework dependent package, we have no specified RuntimeIdentifier, hence we select Microsoft.NET.Sdk.WindowsDesktop. We can only fix this in the next release for PowerShell.

@adityapatwardhan - thinking about this, I think we should update PS to v7 everywhere except Windows arm32 (e.g. drop the Windows arm32 Dockerfile changes from this PR). This would help flush out any issues with v7. An issue should then be logged to track the issue of the Windows arm32 images not being able to uptake v7 because of the PS issue. Once the next preview of PS v7 is available, we will uptake it and be able to resolve that issue.

cc @mthalman, @dleeapho, @richlander

@MichaelSimons I have made the changes and am waiting for the CI to finish.

@adityapatwardhan - It doesn't look like you actually made any changes. 3.0/sdk/nanoserver-1809/arm32v7/Dockerfile is still targeting 7.0.0-preview.1.

@mthalman Actually fixed it now.