Skip to content

[msbuild] Remote build from Windows fails in ReadAppManifest with ArgumentNullException (path2) on 27.0.10722 #26847

Closed
Bug
#26904
Closed
[msbuild] Remote build from Windows fails in ReadAppManifest with ArgumentNullException (path2) on 27.0.10722#26847
Bug
#26904
Labels
windows-onlyThe issue only occur on Windows
Milestone
Future

Description

@ChrisLi-Bear
ChrisLi-Bear
opened on Oct 13, 2026

Description

Publishing an iOS app from Windows with a remote Mac build (ServerAddress, Pair to Mac) fails since we moved to workload set 10.0.401.1 / Microsoft.iOS.Sdk 27.0.10722 and Xcode 27.0. Compile, linking and AOT on the Mac succeed; the build fails about 12 minutes in, after the archive is created, in the remote ReadAppManifest task:

Xamarin.Shared.targets(3642,3): warning : [xma][err]: Exception in task "ReadAppManifest".
Xamarin.Shared.targets(3642,3): error : MessagingRemoteException: An error occurred on client Build18111529654 while executing a reply for topic xvs/build/18.11.15.29654/execute-task/{AppName}/8e767bf002fReadAppManifest
Xamarin.Shared.targets(3642,3): error : ArgumentNullException: Value cannot be null. (Parameter 'Value cannot be null. (Parameter 'path2')')

Client-side stack:

at Xamarin.Messaging.Client.MessagingClient.PostAsync[TRequest,TResponse](...)
at Xamarin.Messaging.Ssh.MessagingRunnerPro.ExecuteWithRetryAsync[TResult](...)
at Xamarin.Messaging.Ssh.MessagingClientPro.PostAsync[TMessage,TResult](...)
at Xamarin.Messaging.Build.Client.BuildClient.ExecuteTaskAsync(String task, String inputs)
at Xamarin.Messaging.Build.Client.TaskRunner.RunAsync(Task task)

The same project built fine every night with workload set 10.0.300.3 (Microsoft.iOS.Sdk 26.5.10284) and Xcode 26.5, until the Mac was upgraded to macOS 27 / Xcode 27. This looks like the same problem as dotnet/maui#39033, which has no response yet; filing here since the failing task lives in this repo.

Steps to reproduce

On a Windows machine, with a Mac reachable over SSH:

dotnet publish App.csproj -f net10.0-ios -c Release -p:ArchiveOnBuild=true -p:RuntimeIdentifier=ios-arm64 -p:CodesignKey="..." -p:CodesignProvision="..." -p:ServerAddress=<mac> -p:ServerUser=<user> -p:ServerPassword=<pw> -p:TcpPort=58181 -p:_DotNetRootRemoteDirectory=/Users/<user>/Library/Caches/maui/PairToMac/SDKs/dotnet/

Environment

  • Windows: .NET SDK 10.0.401, workload set 10.0.401.1, Microsoft.iOS.Sdk.net10.0_27.0 27.0.10722, Xamarin.Messaging 18.11.15.29654 (from the topic name)
  • Mac: macOS 27.0 (Darwin 27.0.0, Apple Silicon), Xcode 27.0; PairToMac .NET SDK 10.0.401 with the same workload set
  • Not using Visual Studio; plain dotnet publish on a build agent

What we looked at

_AddAppleApplicationArtifactMetadata is new in 27.0 (it is not in Microsoft.iOS.Sdk 26.5.10301). It calls ReadAppManifest with AppManifest="$(_AppBundleManifestPath)", and its condition explicitly allows the manifest not to exist locally when IsRemoteBuild is true. With ArchiveOnBuild=true, the comment in _CollectAppleArchiveOutput says CopyArchiveFromMac sets $(ArchivePath) to the local Windows path, and _GenerateBundleName derives _AppContainerDir from $(ArchivePath) for app distribution. Our guess is that _AppBundleManifestPath ends up as a Windows-local (or partly empty) path when the task is executed on the Mac. We have not verified this.

Not tested yet: whether ArchiveOnBuild=false avoids the failure.

Is there a supported way to skip the artifact metadata step for remote builds until this is fixed?

Activity

  1. rolfbjarne commented on Oct 14, 2026

    @rolfbjarne
    rolfbjarne
    on Oct 14, 2026
    Member

    Steps to reproduce

    On a Windows machine, with a Mac reachable over SSH:

    dotnet publish App.csproj -f net10.0-ios -c Release -p:ArchiveOnBuild=true -p:RuntimeIdentifier=ios-arm64 -p:CodesignKey="..." -p:CodesignProvision="..." -p:ServerAddress=<mac> -p:ServerUser=<user> -p:ServerPassword=<pw> -p:TcpPort=58181 -p:_DotNetRootRemoteDirectory=/Users/<user>/Library/Caches/maui/PairToMac/SDKs/dotnet/

    Could you add -bl:msbuild.binlog to this command, and then attach the resulting msbuild.binlog file here?

    See https://github.com/dotnet/macios/wiki/Provide-confidential-information if you don't want to attach the file to a public issue.

  2. rolfbjarne
    added
    need-infoWaiting for more information before the bug can be investigated
    on Oct 14, 2026
  3. rolfbjarne
    added this to the Future milestone on Oct 14, 2026
  4. rolfbjarne
    added
    windows-onlyThe issue only occur on Windows
    on Oct 14, 2026

  5. dotnet-policy-service commented on Oct 14, 2026

    @dotnet-policy-service
    dotnet-policy-serviceBot
    on Oct 14, 2026 – with Dotnet Policy Service

    Hi @ChrisLi-Bear. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

  6. rolfbjarne
    added the
    Bug
    issue type on Oct 14, 2026

  7. iEWngKvR67 commented on Oct 14, 2026

    @iEWngKvR67
    iEWngKvR67
    on Oct 14, 2026

    Same team as the reporter, adding what we found after digging through the targets and the messaging client. The suspicion in the description was close, but the manifest path itself is fine; the problem is the session client being torn down before the Publish-only target runs:

    1. Publish depends on GetApplicationArtifacts, which depends on Build; _AddAppleApplicationArtifactMetadata. So the new metadata target runs after Build has finished.
    2. On a remote build, Build ends with _SayGoodbye (from Xamarin.Messaging.Build.targets), which disconnects and calls BuildConnection.RemoveClient(sessionId).
    3. The condition of _AddAppleApplicationArtifactMetadata contains Or '$(IsRemoteBuild)' == 'true', so it runs even though Info.plist does not exist on Windows, and sends ReadAppManifest to the Mac.
    4. TaskRunner asks BuildConnection.GetClient(sessionId) for a client. Because the old one was removed, it creates a brand-new BuildClient. Only SayHello calls AssociateApp, so the new client has AppName == null.
    5. The ExecuteTaskMessage therefore goes out with a null AppName. You can see it in the error: the topic still contains the unresolved placeholder, execute-task/{AppName}/<sessionid>ReadAppManifest. On the Mac side the session path is built from builds root + app name + session id, and the null app name is the path2 of that Path.Combine.

    Workaround that works for us (csproj):

    <!-- keep the Mac connection open during publish, see dotnet/macios#26847 -->
<PropertyGroup Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios' and '$(_IsPublishing)' == 'true'">
  <ShouldDisconnect>false</ShouldDisconnect>
</PropertyGroup>

<!-- ...and close it ourselves after Publish, so the build signature is still written -->
<Target Name="DisconnectFromMacAfterPublish"
        AfterTargets="Publish"
        DependsOnTargets="_SayGoodbye"
        Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios' and '$(_IsPublishing)' == 'true' and '$(IsRemoteBuild)' == 'true'" />

    Note that ShouldDisconnect=false alone is not enough: without the explicit _SayGoodbye, dotnet publish keeps the SSH session open and the process does not exit, and the build signature is never written, so every following build starts with a Clean.

  8. dotnet-policy-service
    added
    need-attentionAn issue requires our attention/response
    and removed
    need-infoWaiting for more information before the bug can be investigated
    on Oct 14, 2026

  9. ChrisLi-Bear commented on Oct 14, 2026

    @ChrisLi-Bear
    ChrisLi-Bear
    on Oct 14, 2026
    Author

    The binlog is attached privately to this Developer Community report: https://developercommunity.microsoft.com/t/Private-binlog-for-dotnetmacios26847-/11165990

    It's from a clean build (bin/obj deleted) without the workaround from the comment above, and shows the same ReadAppManifest / path2 failure with the {AppName} placeholder in the topic.

  10. rolfbjarne commented on Oct 16, 2026

    @rolfbjarne
    rolfbjarne
    on Oct 16, 2026
    Member

    I haven't tested this, but I believe that adding this to your csproj will work around the error:

    <Target Name="_AddAppleApplicationArtifactMetadata" />

    basically overriding the ="_AddAppleApplicationArtifactMetadata target (which is the one causing the problem) with an empty target.

  11. rolfbjarne
    marked Error building iOS app from Windows using dotnet publish after updating to workload 10.0.401.1 maui#39033 as a duplicate of this issue on Oct 19, 2026

  12. rolfbjarne commented on Oct 19, 2026

    @rolfbjarne
    rolfbjarne
    on Oct 19, 2026
    Member

    Thanks for the binlog, I've investigated and a few fixes are on the way.

    Let me know if the workaround I suggested earlier works; if not please provide another binlog and I'll have a look.

  13. rolfbjarne
    removed
    need-attentionAn issue requires our attention/response
    on Oct 19, 2026
  14. rolfbjarne
    added a commit that references this issue on Oct 20, 2026

    [publish] Copy dSYMs before disconnecting remote builds (#26905)

    159f7aa
  15. rolfbjarne
    closed this as completedin #26904on Oct 21, 2026
  16. rolfbjarne
    added 2 commits that reference this issue on Oct 21, 2026

    [msbuild] Diagnose remote task requests without an application name (#…

    37561b2

    [release/11.0.1xx] [msbuild] Read artifact metadata locally on Windows.

    578f190

  17. JSWANS0N commented on Oct 26, 2026

    @JSWANS0N
    JSWANS0N
    on Oct 26, 2026

    Could #26904 and #26905 be backported to release/10.0.1xx too, since .NET 10 (iOS 27.1.10018) still hits this?

  18. BrzVlad
    added a commit that references this issue on Oct 27, 2026

    [msbuild] Read artifact metadata locally on Windows. Fixes dotnet#26847…

    f597407

  19. rolfbjarne commented on Oct 27, 2026

    @rolfbjarne
    rolfbjarne
    on Oct 27, 2026
    Member

    23. Could #26904 and #26905 be backported to release/10.0.1xx too, since .NET 10 (iOS 27.1.10018) still hits this?

    Yes, they will be.

  20. rolfbjarne
    added 5 commits that reference this issue on Oct 27, 2026

    [release/11.0.1xx] [publish] Copy dSYMs before disconnecting remote b…

    e4989e0

    [release/10.0.1xx] [publish] Copy dSYMs before disconnecting remote b…

    2582544

    [release/10.0.1xx] [msbuild] Diagnose remote task requests without an…

    0e5a381

    [release/10.0.1xx] [msbuild] Read artifact metadata locally on Windows.

    357f0ca

    [release/11.0.1xx] [msbuild] Diagnose remote task requests without an…

    791fa70
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    windows-onlyThe issue only occur on Windows

    Type

    Bug

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions