Xamarin.Android.Support.Animated.Vector.Drawable path too long

[mhmacleod]

Xamarin.Android Version (eg: 6.0):

25.1.1

Operating System & Version (eg: Mac OSX 10.11):

Windows 7

Support Libraries Version (eg: 23.3.0):

25.1.1

Describe your Issue:

Path to dll is unnecessarily long leading to error message during build: 'The "ResolveLibraryProjectImports" task failed unexpectedly...' with the exact error message being "System.IO.PathTooLongException".
Project package folder is not very deep: "C:\123\123456789012\123\1234567\123\packages", but the addition of 'Xamarin.Android.Support.Animated.Vector.Drawable' twice - first to the folder, then the name of the dll - causes the overflow

Steps to Reproduce (with link to sample solution if possible):

Just create a visual studio project in a folder of the above length referencing this nuget and attempt to build

Include any relevant Exception Stack traces, build logs, adb logs:

Error The "ResolveLibraryProjectImports" task failed unexpectedly.
System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
at System.IO.PathHelper.GetFullPathName()...

[Redth]

MAX_PATH on windows is a constant issue. I know your path doesn't seem too deep, but you'll have to move it much closer to root. We have something like C:\and-sup\ as our project root in our CI environment to mitigate this.

[mhmacleod]

I'm also familiar with headaches from windows filepath lengths, but asking all users to move their entire source code solution much closer to root just to use this nuget package is impractical, especially when many I believe are like me who work in a team and follow source-controlled file structures and have our own nested series of projects and folders that we can't easily move around.
Wouldn't this just be much easier to shorten the library's name/folder or abbreviate certain segments e.g. 'Anim' for 'Animated'; 'Vect' for 'Vector'?

[whench18]

Hi I have one great solution to that. Try using the Long path tool. This will help you solve any kinds of problems concerning path too long issues. this is proven and tested by many users.

[marky15]

Hello!! I have great solution to that. Try using the LONG PATH TOOLl. This will help you solve any kinds of problems concerning path too long issues. I have tried this one and this is proven and tested by many users.

[Redth]

One of the problems with changing the paths at this point is there are NuGet Package ID's and assembly names involved, and changing those would potentially involve some breaking changes.

[Redth]

I've spent a bit more time digging into this. The folder name under obj/Debug/__library_project_imports__ is based on the assembly name. Changing the assembly name in our nuget packages at this point would cause a fair bit of pain for us and other customers. Unfortunately at this point it's just not feasible to change the assembly names.

However, there are still some options for windows users:

1. You can try using this msbuild property in your project:

<PropertyGroup>
    <UseShortFileNames>True</UseShortFileNames>
</PropertyGroup>

This will cause the folders to be named by a 10 char hash, which in this case will save you ~26 chars in the path (eg: obj/Debug/__library_project_imports__/123456789A/...). There may be other path shortening optimizations in the future if you set this property as well.

2. You can also change your project's <IntermediateOutputPath> to be in a more shallow root path, eg:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <IntermediateOutputPath>C:\temp\myproj</IntermediateOutputPath>
</PropertyGroup>

We're always looking at improving windows compatibility, especially around MAX_PATH issues. In the future the embedded library projects may be handled a bit differently for Android Support and Google Play Services / Firebase avoiding some of these path scenarios.

I'm sure this isn't exactly the answer you were hoping for, but hopefully it will help alleviate some of the MAX_PATH pressure as we continue to work on this problem.