Add support for absolute paths for [Intermediate]OutputPath for remote builds

[rolfbjarne]

We've never supported absolute paths for [Intermediate]OutputPath, but this has not been a frequent problem, because the default was to use relative paths.

However, in .NET 8, a new output path mode was implemented (UseArtifactsPath=true), and now absolute paths for [Intermediate]OutputPath will be much more common.

As such, we should look into making absolute paths work.

This wasn't done for .NET 8 because it's a rather complicated problem to fix, and the complexity was discovered too late in the release cycle. In the meantime, we've added logic to detect the scenario, and show an actionable error instead (#18900).

The basic problem is that the project's remote directory, the one with the hash:

/Users/rolf/Library/Caches/Xamarin/mtbs/builds/DotNet8Test/f915cefc3161dc001199a62de03b2def4b16a89c7efc331dce9f95ca9b91ccc1/

is both the root of the project directory (so any relative paths are resolved relative to that directory) as well as the root of the drive system (so it contains C:/... paths).

This means that a given path has two valid locations if it's inside the project directory:

1. As a relative path:

/Users/rolf/Library/Caches/Xamarin/mtbs/builds/DotNet8Test/f915cefc3161dc001199a62de03b2def4b16a89c7efc331dce9f95ca9b91ccc1/outputdir/whatever

2. As an absolute path

/Users/rolf/Library/Caches/Xamarin/mtbs/builds/DotNet8Test/f915cefc3161dc001199a62de03b2def4b16a89c7efc331dce9f95ca9b91ccc1/C:/source/projects/DotNet8Test/outputdir/whatever

and the build breaks when one file is in one location, but our build logic expects it in the other.

One potential fix would be to only work with absolute paths on the Mac (relative to the hash directory), so that the build would create this path:

/Users/rolf/Library/Caches/Xamarin/mtbs/builds/DotNet8Test/f915cefc3161dc001199a62de03b2def4b16a89c7efc331dce9f95ca9b91ccc1/C:/source/projects/DotNet8Test/

make that the current directory, and make all relative paths relative to that directory. Then there would be no confusion, because each path wouldn't have two different locations.

References:

• Unable to build .NET MAUI iOS project on Windows #18510
• https://developercommunity.visualstudio.com/t/Unable-to-build-NET-for-iOS-projects-on/10409856 (https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1847166)
• https://devblogs.microsoft.com/dotnet/announcing-dotnet-8-preview-3/#simplified-output-path
• [net8.0] [msbuild] Show an error for a remote build if [Intermediate]OutputPath is an absolute path. #18900

[gabsamples6]

@rolfbjarne we cannot add nugets to xamarin.firebase.ios.Cloudmessaging in both net 7 and 8

1. Create an empty Maui project .net 7 or 8 (windows machine)
2. Nugets - add reference to Xamarin.Firebase.iOS.Cloudmessagging and you will see

Severity Code Description Project File Line Suppression State
Error Could not find a part of the path 'C:\Users\joebloggs.nuget\packages\xamarin.firebase.ios.installations\8.10.0.3\lib\xamarinios10\Firebase.Installations.resources\FirebaseInstallations.xcframework\ios-arm64_x86_64-simulator\FirebaseInstallations.framework\Headers\FIRInstallationsAuthTokenResult.h'.

Any workarounds?

[rolfbjarne]

@gabsamples6 looks like a MAX_PATH problem, because that path is 263 characters long :/

One workaround would be to put the packages directory in the root folder (and with a shorter name), that should leave a bit more leeway for nuget packages.

[gabsamples6]

@rolfbjarne thanks for your time on this one - this is what I tried.
Changed maxPath in windows 11 - did not work
moved to c:/nuget and even this was not enough

what worked
go to the xaman.shared.Sdk.target and remove the _CopyLocalBindingResources target as you suggested in another thread.

so whenever there is a new version of visual studio I have to remember to go back and delete this target. Not sure if there are any side effects to it but it allowed me to proceed.

However that cleared the first hurdle ony to find out that Xamarin.firebase.cloudmessaging does not work on windows and we develop on windows.

Messaging.SharedInstance is always null so many people are stuck on this one and i have below. Any suggestions? workaround?

	<ItemGroup>
		<BundleResource Include="Platforms\iOS\GoogleService-Info.plist" Link="GoogleService-Info.plist" />
	</ItemGroup>

thank you for your time

[rolfbjarne]

However that cleared the first hurdle ony to find out that Xamarin.firebase.cloudmessaging does not work on windows

I'm not aware of any issues with Xamarin.Firebase.Cloudmessaging, could you create a new issue with a test project?