Unable to build .NET MAUI iOS project on Windows

[brunck]

Steps to Reproduce

1. Use VS 2022 Preview
2. Open reproduction sample solution, connect to remote Mac
3. Build project

Expected Behavior

The solution builds on Windows, remoting to the Mac

Actual Behavior

Build fails with error: MessagingRemoteException: An error occurred on client Build1648525net8p5 while executing a reply for topic...
If you remove the Directory.build.props file and delete the artifacts folder along with any bin or obj folders and then rebuild, it works.

Environment

.NET 8 on Windows, workload maui-ios - 8.0.0-preview.5.8529/8.0.100-preview.5, iOS - 16.4.8525-net8-p5/8.0.100-preview.5

Version information

Microsoft Visual Studio Enterprise 2022
Version 17.7.0 Preview 2.0
VisualStudio.17.Preview/17.7.0-pre.2.0+33808.371
Microsoft .NET Framework
Version 4.8.04084

Installed Version: Enterprise

ASP.NET and Web Tools   17.7.160.18752
ASP.NET and Web Tools

Azure App Service Tools v3.0.0   17.7.160.18752
Azure App Service Tools v3.0.0

C# Tools   4.7.0-2.23280.4+66772aff549b2981094175a6f2f69600596c1913
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Extensibility Message Bus   1.4.33 (main@eea8cc7)
Provides common messaging-based MEF services for loosely coupled Visual Studio extension components communication and integration.

Microsoft JVM Debugger   1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

Mono Debugging for Visual Studio   17.7.20 (81efaa2)
Support for debugging Mono processes with Visual Studio.

NuGet Package Manager   6.7.0
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Razor (ASP.NET Core)   17.7.2.2330502+e0cf0b1121019f24d79b73d6d30f5870ca83c81d
Provides languages services for ASP.NET Core Razor.

StylerPackage Extension   1.0
StylerPackage Visual Stuido Extension Detailed Info

TypeScript Tools   17.0.20531.2001
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools   4.7.0-2.23280.4+66772aff549b2981094175a6f2f69600596c1913
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual F# Tools   17.7.0-beta.23272.3+96bfa24a5fee6722ed3e2b280d37e80b594bbcf4
Microsoft Visual F# Tools

Visual Studio IntelliCode   2.2
AI-assisted development for Visual Studio.

VisualStudio.DeviceLog   1.0
Information about my package

VisualStudio.Mac   1.0
Mac Extension for Visual Studio

VSPackage Extension   1.0
VSPackage Visual Studio Extension Detailed Info

Xamarin   17.7.0.135 (main@f75253e)
Visual Studio extension to enable development for Xamarin.iOS and Xamarin.Android.

Xamarin Designer   17.7.2.4 (remotes/origin/d17-7@105126fbf4)
Visual Studio extension to enable Xamarin Designer tools in Visual Studio.

Xamarin.Android SDK   13.2.0.13 (d17-5/3f21639)
Xamarin.Android Reference Assemblies and MSBuild support.
    Mono: 73df89a
    Java.Interop: xamarin/java.interop/d17-5@149d70fe
    SQLite: xamarin/sqlite/3.40.1@68c69d8
    Xamarin.Android Tools: xamarin/xamarin-android-tools/d17-5@ca1552d

Reproduction sample

Here is a link to a repo with the repro sample project. Open the solution in the iOSBuildErrorRepro folder.

Build Logs

MSBuildReproLogs.zip

Seems to be the same as #18308 except the issue persists, even in .NET 8 preview 5 and VS 2022 preview, 17.7.0 Preview 2.0.

[dalexsoto]

Hello, could you please try the new preview 6 and validate this still happens? There were fixes in this area shipped in P6.

[ghost]

Hi @brunck. 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.

[brunck]

@dalexsoto Yes this does still exist. I tested this all weekend with P6 and continued to get this error.

[brunck]

@dalexsoto I was able to get iOS projects to build for if all I did was delete my Directory.build.props file, which changed the output path to be the "old" style which is relative to the .csproj (bin and obj) instead of being in an artifacts folder at the root of my repository.

This makes me wonder if it's a MAX_PATH issue...it's saying a file does not exist and (the Windows half of the path anyway) indeed does not exist. The error message is:

1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk\16.4.8646-net8-p6\tools\msbuild\iOS\Xamarin.Shared.targets(1643,3): error : MessagingRemoteException: An error occurred on client Build1648646net8p6 while executing a reply for topic xvs/build/16.4.8646-net8-p6/execute-task/BlufiBindings.iOS/300388c002fComputeRemoteGeneratorProperties 1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk\16.4.8646-net8-p6\tools\msbuild\iOS\Xamarin.Shared.targets(1643,3): error : FileNotFoundException: Could not find file "/Users/brunck/Library/Caches/Xamarin/mtbs/builds/BluFiBindings.iOS/300388ca3b3157fd3c7a8a62170d1deca68cf7def0a6c0437984a3c72e859eac/C:/SourceCode/7-day-timer-mobile-app/a/obj/BlufiBindings.iOS/debug/ComputeRemoteGeneratorProperties/ComputedProperties.txt" 1>C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk\16.4.8646-net8-p6\tools\msbuild\iOS\Xamarin.Shared.targets(1643,3): error :

The path exists up to the debug folder, but the part ComputeRemoteGeneratorProperties/ComputedProperties.txt does not exist. Even shortening the artifacts path in the .props file to be a didn't make a difference.

It doesn't even seem to have this folder and file if I remove the Directory.build.props file but it may also not be looking for it in that case. At any rate, doing things without the props file (aka the "old" way of build paths) works using VS Windows 17.7 preview 3.
I guess the workaround for me is to not use this .props file, at least for now that works.

[dalexsoto]

Have you tried moving your project really close to the root? I wonder if you are running into MAX_PATH issues, alternatively you could try building from the CLI https://learn.microsoft.com/en-us/dotnet/maui/ios/deployment/publish-cli#publish-an-ios-app-from-windows IIRC CLI on windows does not have the MAX_PATH limitation. Please do share a binlog of you build, I tried to read the ones from you initial post but I was not able to open them at all.

[ghost]

Hi @brunck. 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.

[dalexsoto]

An for whatever reason GitHub just showed me you latest reply aster posting this... Yeah I also think it is MAX_PATH try moving it closer to the root or building from CLI to confirm this.

[brunck]

@dalexsoto I added a link in the issue description to a reproduction sample. It may not be the max path issue. At any rate, you should be able to reproduce my exact behavior with this sample. I'm using VS 17.7 preview 3 and .NET 8 preview 6.

If you build it straight away you should see the MessagingRemoteException.

If you simply remove the Directory.build.props file, remove the artifacts folder and any bin or obj folders that might also be hanging around, and then try to build, it works.

Even if I move this folder to the root drive, I get the same behavior.

[rolfbjarne]

This will be fixed in #18618.

It should be possible to apply the fix locally, by editing the file (the exact path might be different depending on the installed version):

C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk\16.4.8646-net8-p6\tools\msbuild\iOS\Xamarin.Shared.targets

according to the changes: https://github.com/xamarin/xamarin-macios/pull/18618/files

[rolfbjarne]

This turned out to be a bit more complicated than I thought because of #14904 :/

[rolfbjarne]

This turned out to be much more complicated than I thought, so #18618 won't fix this at all.

[rolfbjarne]

The current "solution" is that we'll detect this scenario and show a better error message.

An absolute OutputPath is not supported when building remotely. Note that this may occur as a consequence of setting UseArtifactsOutput=true or ArtifactsPath.

This is the change: #18900

[rolfbjarne]

I've opened #18997 to track support for using absolute paths for [Intermediate]OutputPath, and I'll close this since we'll now show an actionable error message for people that run into this.

[dotMorten]

@rolfbjarne I'm now suddenly getting:

6>C:\Program Files\dotnet\packs\Microsoft.iOS.Windows.Sdk\16.4.8968-net8-rc2\tools\msbuild\iOS\Xamarin.iOS.Common.After.targets(422,3): error : An absolute OutputPath is not supported when building remotely. Note that this may occur as a consequence of setting UseArtifactsOutput=true or ArtifactsPath.

when building a class library. Should this check be changed to only apply to applications? The .NET class library itself isn't built remotely.

[rolfbjarne]

@rolfbjarne I'm now suddenly getting:

6>C:\Program Files\dotnet\packs\Microsoft.iOS.Windows.Sdk\16.4.8968-net8-rc2\tools\msbuild\iOS\Xamarin.iOS.Common.After.targets(422,3): error : An absolute OutputPath is not supported when building remotely. Note that this may occur as a consequence of setting UseArtifactsOutput=true or ArtifactsPath.

when building a class library. Should this check be changed to only apply to applications? The .NET class library itself isn't built remotely.

Actually, yes, iOS class libraries are built remotely, because they may contain resources (xibs, storyboards), which will be compiled, and that has to happen on a Mac. Most iOS class library projects don't have resources, so problems with an absolute output path is unlikely to occur, but given that there's an easy way out of this check (set AllowAbsoluteOutputPath=true, as you've found out), and how complicated and confusing any failures can be if things go wrong, I'm inclined to keep the error for class libraries as well (this can of course be revisited in the future if need be).

[dotMorten]

I'm confused by this. If I disconnect from the remote host, it still builds fine and I can ship that assembly as is? I thought the remote host was only needed to deploy or build IPAs / apps

[rolfbjarne]

I'm confused by this. If I disconnect from the remote host, it still builds fine and I can ship that assembly as is? I thought the remote host was only needed to deploy or build IPAs / apps

The remote host is needed to do anything that requires Apple's toolchain. This includes:

• Compiling storyboards / xibs / some other types of resources.
• Compiling Objective-C code (we may generate helper Objective-C code in some circumstances).
• Linking native code.
• A few other minor things as well.

For historical reasons, when including a storyboard or xib as a bundle resource in a class library project, we'll compile it using Apple's toolchain, and include the compiled result in the class library (as an embedded resource). All the other points only apply to executable projects.

This means that if you don't have an bundle resources in the class library project, the project will build just fine without the remote host, and the result is fully functional.

[dotMorten]

Got it. Thanks! I never had a need for thst so never hit it. In that case I'm good with the workaround

[IQTechSolutions]

there is no workaround or solution here