Add support for absolute paths for [Intermediate]OutputPath for remote builds #18997
Comments
rolfbjarne
added
feature
|
@rolfbjarne we cannot add nugets to xamarin.firebase.ios.Cloudmessaging in both net 7 and 8
Severity Code Description Project File Line Suppression State Any workarounds? |
|
@gabsamples6 looks like a MAX_PATH problem, because that path is 263 characters long :/ One workaround would be to put the |
|
@rolfbjarne thanks for your time on this one - this is what I tried. what worked 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? thank you for your time |
I'm not aware of any issues with Xamarin.Firebase.Cloudmessaging, could you create a new issue with a test project? |
…dotnet-linker. Fixes xamarin#19378. We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see xamarin#18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. Fixes xamarin#19378.
…dotnet-linker. Fixes #19378. (#19407) We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see #18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. A few mtouch tests also needed updating, since they're calling mtouch directly instead of going through the msbuild targets. Fixes #19378.
…dotnet-linker. Fixes xamarin#19378. We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see xamarin#18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. Fixes xamarin#19378.
…ges in mtouch/mmp/dotnet-linker. Fixes xamarin#19378. (xamarin#19463) We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see xamarin#18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. A few mtouch tests also needed updating, since they're calling mtouch directly instead of going through the msbuild targets. Fixes xamarin#19378. Backport of xamarin#19407 --------- Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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:
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:
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:
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:
The text was updated successfully, but these errors were encountered: