Bug 40077 - Using Xaml files generates long intermediate file paths that exceeds 248 char limit
Summary: Using Xaml files generates long intermediate file paths that exceeds 248 char...
Status: RESOLVED FIXED
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.1.0
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Stephane Delcroix
URL:
Depends on:
Blocks:
 
Reported: 2016-04-04 11:21 UTC by Antti Kajanus
Modified: 2017-10-27 17:39 UTC (History)
7 users (show)

Tags: ac, fr
Is this bug a regression?: ---
Last known good build:


Attachments
Error in visual studio (37.85 KB, image/png)
2017-05-25 09:15 UTC, Antti Kajanus
Details
Sample project (321.09 KB, application/x-zip-compressed)
2017-05-25 09:15 UTC, Antti Kajanus
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Antti Kajanus 2016-04-04 11:21:16 UTC
When compiling the Xamarin Forms solution using Shared library that contains XAML pages, intermediate files are create to \obj\ folder. The temporary files has really long name which is constructed something like this {objFolder}{AppName}{FullFilePath}. Since Windows has 248 char limit with the folder/file names we hit the limit constantly. 

Here is the scenario :
- Solution called "company.project.testapp" to for example location C:\temp\intermeadiateTest\
- Add Views folder to shared solution
- Add new Xaml page to the views folder called MyFirstView.xaml
- build

You will see following error:


Severity	Code	Description	Project	File	Line	Suppression State
Error		Files has invalid value "obj\Debug\Company.Project.TestApp.Droid.C_.temp.IntermeadiateTest.Company.Project.TestApp.Company.Project.TestApp.Company.Project.TestApp.Views.MyFirstView.xaml.g.cs". 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.	Company.Project.TestApp.Droid			

You can shorten the file name by removing default extra folder that is created by the template, shortening the folder names / solution name but the issue is still there and even after doing all that, we hit the issue on our repositories. 

Easiest way to get this building is to move folder to closer C: root but forcing to do this is fairly annoying (and we have to point that out in the public GitHub repositories as well that only way to build the solution is to use less than XX characters in the root folder from C: root).
Comment 1 Stephane Delcroix 2017-05-24 09:32:46 UTC
the temporary files are constructed like this

$(IntermediateOutputPath)%(ManifestResourceName).g$(DefaultLanguageSourceExtension)

Don't you have, by chance, a rule that sets EmbeddedResources Ids to ${AppName}.${FullFilePath} ??

Could you please check how your resources are identified ?

This is all quite strange to me as if such long paths were generated by default, we'd have had a LOT more of reports like this one...
Comment 2 Antti Kajanus 2017-05-24 13:40:45 UTC
Hi you can get this surfaced by doing this:

1) Create new solution using Xamarin Forms
2) Set project name to CompanyName.ProjectName.Client
3) Build

No extra configurations (expect set UWP building from Configuration Manager).

You should see following error:
"Files has invalid value

obj\x86\Debug\CompanyName.ProjectName.Client.UWP.c_.users.<SNIP>.documents.visual_studio_2015.Projects.CompanyName.ProjectName.Client.CompanyName.ProjectName.Client.CompanyName.ProjectName.Client.MainPage.xaml.g.cs". 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.    CompanyName.ProjectName.Client.UWP"
Comment 3 Paul DiPietro [MSFT] 2017-05-24 18:28:10 UTC
I have just attempted creating a new solution from the Forms project template and added a XAML page as mentioned in the first comment (as well as the same project name) and it builds as expected. The file path is:

C:\Temp\company.project.testapp\company.project.testapp\company.project.testapp\obj\Debug\company.project.testapp.App.xaml.g.cs
Comment 4 Antti Kajanus 2017-05-25 09:02:20 UTC
We tested this yesterday and 2 machines behaves the same in our end. 

- Windows 10 Enterprise
- Visual Studio 2015 Professional Update 3 version 14.0.25421.03
- Xamarin updated yesterday (24th May 2017)

Is there some settings somewhere that might cause this behavior either in Visual Studio level or project/solution level?
Comment 5 Antti Kajanus 2017-05-25 09:15:13 UTC
Created attachment 22446 [details]
Error in visual studio
Comment 6 Antti Kajanus 2017-05-25 09:15:47 UTC
Created attachment 22447 [details]
Sample project
Comment 7 Stephane Delcroix 2017-05-29 09:02:12 UTC
I can't reproduce your issue on my setup, but I nonetheless wrote a fix so it doesn't happen anymore

https://github.com/xamarin/Xamarin.Forms/pull/940
Comment 8 Morten Nielsen 2017-05-30 17:29:05 UTC
It's worth noting that since Anniversary update, long path names issues in VS are rarely a problem. So make sure you test on Win7 or older Win10 installs.
Comment 9 Stephane Delcroix 2017-10-16 14:47:12 UTC
this is a proper fix
https://github.com/xamarin/Xamarin.Forms/pull/1202
Comment 10 Samantha Houts [MSFT] 2017-10-27 17:39:16 UTC
Should be fixed in 2.5.1-pre1. Thank you!