Long internal paths in MR Feature Tool package may cause building errors

[aleneum]

I stumbled upon an issues with the MR Feature Tool package of WLT when the build path is longer than about 50 chars.

I created a new Unity Project with Unity 2019.4.24f1 and run the MR Feature Tool (1.0.2103.3-Beta) and installed some features. My package.json now contains these new items and the related package have been copied.

    "com.microsoft.mixedreality.toolkit.foundation": "file:MixedReality/com.microsoft.mixedreality.toolkit.foundation-2.6.1.tgz",
    "com.microsoft.mixedreality.toolkit.tools": "file:MixedReality/com.microsoft.mixedreality.toolkit.tools-2.6.1.tgz",
    "com.microsoft.spatialaudio.spatializer.unity": "file:MixedReality/com.microsoft.spatialaudio.spatializer.unity-1.0.196.tgz",
    "com.microsoft.mixedreality.worldlockingtools": "file:MixedReality/com.microsoft.mixedreality.worldlockingtools-1.3.5.tgz",
    "com.microsoft.mixedreality.webrtc": "file:MixedReality/com.microsoft.mixedreality.webrtc-2.0.2.tgz",
    "com.microsoft.mixedreality.toolkit.standardassets": "file:MixedReality/com.microsoft.mixedreality.toolkit.standardassets-2.6.1.tgz"

When I try to build the project, I get the following error:

FileNotFoundException: Packages/com.microsoft.mixedreality.worldlockingtools/Packages/Microsoft.MixedReality.Unity.FrozenWorld.Engine.1.1.0/lib/unity/Windows-UWP-ARM64/FrozenWorldPlugin.dll does not exist
System.IO.File.Copy (System.String sourceFileName, System.String destFileName, System.Boolean overwrite) (at <eae584ce26bc40229c1b1aa476bfa589>:0)
PostProcessWinRT.CopyFileWithDebugSymbols (System.String source, System.String target, System.Boolean isFileManagedAssembly) (at C:/buildslave/unity/build/PlatformDependent/MetroPlayer/Extensions/Managed/PostProcessWinRT.cs:639)
PostProcessWinRT.CopyPlugins () (at C:/buildslave/unity/build/PlatformDependent/MetroPlayer/Extensions/Managed/PostProcessWinRT.cs:932)
PostProcessWinRT.Process () (at C:/buildslave/unity/build/PlatformDependent/MetroPlayer/Extensions/Managed/PostProcessWinRT.cs:170)
UnityEditor.UWP.BuildPostprocessor.PostProcess (UnityEditor.Modules.BuildPostProcessArgs args) (at C:/buildslave/unity/build/PlatformDependent/MetroPlayer/Extensions/Managed/ExtensionModule.cs:85)
Rethrow as BuildFailedException: Exception of type 'UnityEditor.Build.BuildFailedException' was thrown.
UnityEditor.UWP.BuildPostprocessor.PostProcess (UnityEditor.Modules.BuildPostProcessArgs args) (at C:/buildslave/unity/build/PlatformDependent/MetroPlayer/Extensions/Managed/ExtensionModule.cs:89)
UnityEditor.Modules.DefaultBuildPostprocessor.PostProcess (UnityEditor.Modules.BuildPostProcessArgs args, UnityEditor.BuildProperties& outProperties) (at <5984c823338e4ca69b7a0ca01115425e>:0)
UnityEditor.PostprocessBuildPlayer.Postprocess (UnityEditor.BuildTargetGroup targetGroup, UnityEditor.BuildTarget target, System.String installPath, System.String companyName, System.String productName, System.Int32 width, System.Int32 height, UnityEditor.BuildOptions options, UnityEditor.RuntimeClassRegistry usedClassRegistry, UnityEditor.Build.Reporting.BuildReport report) (at <5984c823338e4ca69b7a0ca01115425e>:0)
UnityEngine.GUIUtility:ProcessEvent(Int32, IntPtr)

I have the feeling that the building path has somethings to do with this. While building succeeded at:

C:\Users\alneuman\workspace\WLTTest

It did not not work with:

C:\Users\alneuman\workspace\Unity\SandboxProjects\WLTTest

I checked where Unity keeps the uncompressed packages and the path for WLTCore is:

C:\Users\alneuman\workspace\Unity\SandboxProjects\WLTTest\Library\PackageCache\com.microsoft.mixedreality.worldlockingtools@834acdcbd53e-1618586077562

Combining this with what Unity tells me (Packages/com.microsoft.mixedreality.worldlockingtools/Packages/Microsoft.MixedReality.Unity.FrozenWorld.Engine.1.1.0/lib/unity/Windows-UWP-ARM64/FrozenWorldPlugin.dll)
I end up with the actual file system path:

C:\Users\alneuman\workspace\Unity\SandboxProjects\WLTTest\Library\PackageCache\com.microsoft.mixedreality.worldlockingtools@834acdcbd53e-1618586077562/Packages/Microsoft.MixedReality.Unity.FrozenWorld.Engine.1.1.0/lib/unity/Windows-UWP-ARM64/FrozenWorldPlugin.dll (264 chars)

in contrast to the shorter path

C:\Users\alneuman\workspace\WLTTest\Library\PackageCache\com.microsoft.mixedreality.worldlockingtools@834acdcbd53e-1618586077562/Packages/Microsoft.MixedReality.Unity.FrozenWorld.Engine.1.1.0/lib/unity/Windows-UWP-ARM64/FrozenWorldPlugin.dll (241 chars)

The Unity project path alone (Library\PackageCache\com.microsoft.mixedreality.worldlockingtools@834acdcbd53e-1618586077562/Packages/Microsoft.MixedReality.Unity.FrozenWorld.Engine.1.1.0/lib/unity/Windows-UWP-ARM64/FrozenWorldPlugin.dll) is 205 characters long! It consumes almost 80% of the allowed path length! This means, users have about 20 - 30 chars to organize their projects when you consider the user's home directory static.

[fast-slow-still]

I have been hit by the same issue. While the issue is ultimately the path length limit, we (WLT) are taking steps to mitigate the issue by using less of the 260 characters, leaving more for user folder structure. We are also working with Unity to see if some of the Unity imposed path length can be eliminated or reduced.

In the short term, the workaround is, as you have found, to install into a folder with a short path length.

[fast-slow-still]

Note that about 90 characters of that path are the result of installing using Unity's package management rather than from .unitypackage files. So another workaround would be to install from the Releases .unitypackages instead of MRFeatureTool.

[aleneum]

Thank you, @fast-slow-still, for sharing some workarounds. I relocated my workspace for now. Conceptually, there is absolutely nothing wrong with the WLT package structure. And I agree, this issue is caused by multiple factors. I wouldn't consider this an issue of WLT in particular but something that might haunt MR developers more frequently in the future when the MR Feature Tool is becoming more popular in the MR(TK) ecosystem. Closing this since it's not an actual bug report but just some remarks that might save future visitors of this issue tracker some debugging time.