Search code examples
azure-devopsazure-pipelinesmaui.net-ios

Could upgrade of .NET core task cause build issues with Azure pipeline for MAUI build?


Seemingly out of nowhere, my Azure pipeline that ran the dotnet publish command for a MAUI project is failing with the error Resources/Styles/Colors.xaml : error : The name 'Resources' is reserved and cannot be used.

The target of the project is net8.0-ios. The pipeline installs the .NET 8.0.100 SDK, which it has always done since it was created. It uses mac os 13 and xCode 15.2 - both of which haven't changed either. This builds fine locally on a mac, with the .NET 8.0.100 sdk.

From what I can see the only thing that has changed is the version of the .NET core command line task that runs the publish command - in the last successful build it was 2.242.0 and it is now 2.242.1 (this is not something I have explicitly changed). No code has changed, no nuget packages have been updated or anything of the sort.

After looking at the error I had a look at my csproj and noticed it had a section for compiling Colors.xaml - which some of my other MAUI projects (whose pipelines did run) did not have, so I removed it.

  <ItemGroup>
    <MauiXaml Remove="Resources\Styles\Colors.xaml" />
  </ItemGroup>
  <ItemGroup>
    <BundleResource Include="Resources\Styles\Colors.xaml">
      <Generator>MSBuild:Compile</Generator>
    </BundleResource>
  </ItemGroup>

After making this change, the build now passes. However, upon delivery to app store connect I am faced with the infamous ITMS-90078: Missing Push Notification Entitlement warning. I have read this can be caused by 3rd party libraries, but as I mentioned previously, none of my nuget package versions have updated and there hasn't been any code changes. My best guess is this has come from the AppCenter nuget package (which I will be removing soon, as AppCenter is being retired), but I can't prove this is the case until I remove it. I still don't understand why this happened all of a sudden. Would the change in .NET Core task version be enough to have caused these issues? I'm just trying to understand What has happened here.


Solution

  • I think ultimately I'm going to go down the self hosted agent route, so I can control which maui workload version is installed and only upgrade when we've tested & confirmed everything works. In the short term, I've managed to control which version of maui is installed on the pipeline agent by using dotnet workload install maui --from-rollback-file https://maui.blob.core.windows.net/metadata/rollbacks/8.0.61.json, which solves my issue.

    UPDATE: looks like the maui team have now blocked public access to the rollback url. It seems like there is now an official way to pin maui workload version, but I've not yet tried it: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-workload-sets