-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Invalid runtimeconfig.json" on Windows for paths precisely from 260 to 274 characters #53223
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsDescription(The issue only affects Windows.)
So, according to what I could gather during the initial investigation of the issue, it depends on path length for the
It looks like the countermeasures were applied for it to work under long paths, but there's an arithmetic or logical error in the code that applies the workaround, so it breaks for certain path lengths. I expect it to work in all three cases. Or, if it breaks due to the path length, I expect it to break in a predictable way, and not for paths in a certain length range. Configuration
Regression?I don't think it is. AFAIK, it works the same in .NET Core 3.1.
|
The span of 14 characters (260–274) could be explained by the difference in lengths between the path to the exe file and the path to the |
Thanks for the investigation, @ForNeVeR - really helpful. Looks like the hosting layer normalizes the app path for long paths, then builds up the I think this should be a matter of changing the runtimeconfig reading to update/store the normalized path. It is currently doing a file existence check using
I wonder if this could actually be the underlying issue with dotnet/aspnetcore#27469 - cc @vitek-karas @jkotalik |
Re dotnet/aspnetcore#27469 connection - that is potentially possible - assuming the system uses symlinks to redirect to a much longer path location. |
I think there's a similar issue with
Not sure how long the paths are, but it does use symlinks for |
For App Service, you can tell what d:\home symbolic link to by browsing to Kudu Debug Console -> |
Description
(The issue only affects Windows.)
dotnet new console -o net5console && cd net5console && dotnet build
T:\Temp\LongPaths\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789
(272 characters, more thanMAX_PATH
)T:\Temp\LongPaths\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\30characters_34567890123456789
(252 characters, less thanMAX_PATH
)T:\Temp\LongPaths\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\50characters_3456789012345678901234567890123456789\21characters_34567890
(243 characters, less thanMAX_PATH
)net5console\bin\Debug\net5.0
to the directories from step 2.cmd
, sincepwsh
doesn't work with certain long paths too well), and see the results:So, according to what I could gather during the initial investigation of the issue, it depends on path length for the
runtimeconfig.json
file:It looks like the countermeasures were applied for it to work under long paths, but there's an arithmetic or logical error in the code that applies the workaround, so it breaks for certain path lengths.
I expect it to work in all three cases. Or, if it breaks due to the path length, I expect it to break in a predictable way, and not for paths in a certain length range.
Configuration
Regression?
I don't think it is. AFAIK, it works the same in .NET Core 3.1.
The text was updated successfully, but these errors were encountered: