This is a cross-posting of Long Path Error While Publishing ASP.NET Core Applications at Kloud.
If you are writing an ASP.NET Core RC1 application, there are chances to publish your app to either an Azure Website or another place, by right-mouse clicking in Visual Studio.
In most cases, it should be alright. However, if your app has a NuGet package with a long name, it would be an issue. You might be seeing an error like this:
DNU(0,0): Error : 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.
Yes, this is the notorious
PathTooLongException that Windows OS has had. There’s no silver bullet for easy fix for it. In this post, I’ll show you a couple of options that you might consider.
While creating a package to publish, it uses the following path:
C:\Users\[USERNAME]\AppData\Local\Temp\PublishTemp\[ProjectName][LengthOfProjectFullName] `</pre> For example, I'm using Justin as my `[USERNAME]` and my project has a name of `MyProject` and its full length is `163` then, the package publish path will look like: <pre>`C:\Users\Justin\AppData\Local\Temp\PublishTemp\MyProject163 `</pre> In addition to that, an ASP.NET Core RC1 application creates three different directories under that path – `approot`, `logs` and `wwwroot`. The `approot` path actually contains all NuGet packages and DNX runtime library. Here's the issue arising. If any of NuGet package has a very long name, it can't be fit into the temp folder. If any `node_module` has a deeper dependency, it will also throw an error for packaging. Then, how can we solve the problem? I would suggest two approaches. ## Update Environment Variables !(http://blob.devkimchi.com/devkimchiwp/2016/06/long-path-exception-02.png) There are two environment variables – `TEMP` and `TMP`. This determines your temp directory. Therefore, change it to a shorter ones like: <pre>`TEMP=C:\Temp TMP=C:\Temp `</pre> This is the easiest and quickest way to fix the issue. However, the biggest caveat of this approach is that all other applications using those temp folder will be affected and we might have unwanted side effects. We need to find another way that only impacts on my current web application project. ## Update `.xproj` Fortunately, when you open your `.xproj` file of your ASP.NET Core RC1 application, you will find the line almost at the bottom: <pre>`<Import Project="$(VSToolsPath)\DNX\Microsoft.DNX.targets" Condition="'$(VSToolsPath)' != ''" /> `</pre> This provides us with a great clue! Let's find out what we can to do with that `Microsoft.DNX.targets` file. First of all, open the `Microsoft.DNX.targets` that is located in `C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DNX`. It also points another file, `$(_WebPublishTargetsPath)\Web\Microsoft.DNX.Publishing.targets` that is located in the `C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web` directory. Open the file. Then, find the `Global Properties` section and you will find: <pre>`<PropertyGroup> <PublishTempFolderName Condition="'$(PublishTempFolderName)' == ''">$([System.IO.Path]::GetFileNameWithoutExtension($(MSBuildProjectFullPath)))$(MSBuildProjectFullPath.Length)</PublishTempFolderName> <PublishOutputPathNoTrailingSlash Condition="'$(PublishOutputPathNoTrailingSlash)' == ''">$([System.IO.Path]::GetTempPath())PublishTemp\$(PublishTempFolderName)</PublishOutputPathNoTrailingSlash> <PublishOutputPath Condition="'$(PublishOutputPath)' == ''">$(PublishOutputPathNoTrailingSlash)\</PublishOutputPath> <PublishPowerShellVersion Condition="'$(PublishPowerShellVersion)' == ''">1.0.1</PublishPowerShellVersion> </PropertyGroup> `</pre> Here's the magic property – `PublishOutputPathNoTrailingSlash`. This property is used at the bottom of that `targets` file like: <pre>`<Dnu RuntimeToolingDirectory ="$(RuntimeToolingDirectory)" ProjectFolder="$(MSBuildProjectDirectory)" Project="$(KPackWorkingDirectory)" Command="publish" Runtime="$(FinalPublishVersion)" WwwRoot="$(WebRoot)" WwwRootOut="$(WwwRootOut)" NoSource="$(NoSourceFlag)" Quiet="$(QuietFlag)" IncludeSymbols ="$(IncludeSymbolsFlag)" Native ="$(NativeFlag)" Configuration="$(PublishConfiguration)" Out="$(PublishOutputPathNoTrailingSlash)" ExternalToolsPath="$(ExternalToolsPath)" IsFilePreview="$(FilePreview)" IISCommand="$(IISCommand)" EnvironmentVariables="@(DnuPublishEnvironmentVariables)"/> `</pre> This `Dnu` node basically emulates the `msdeploy.exe` so the `Out` attribute defines the output folder where the package is published. Now, we know what needs to be changed. Within our `.xproj` file, we can add this `PublishOutputPathNoTrailingSlash` node like: <pre>`<PropertyGroup> <PublishOutputPathNoTrailingSlash Condition="'$(PublishOutputPathNoTrailingSlash)' == ''">C:\Temp\$(MSBuildProjectName)</PublishOutputPathNoTrailingSlash> </PropertyGroup> <Import Project="$(VSToolsPath)\DNX\Microsoft.DNX.targets" Condition="'$(VSToolsPath)' != ''" />
Once you add the property, save it and restart your Visual Studio to get this change applied to your ASP.NET Core application project. Run the
Publish menu again and it will not fail. This is a better approach comparing to the first one, because it doesn’t impact on other applications on Windows.
Of course, if you use
msdeploy by your hand, it wouldn’t be an issue as you can choose the
-output value based on your preference.
So far, we have had a walkaround to fix the
PathTooLongException issue during the deployment of your ASP.NET Core RC1 application. Fortunately, this restriction will be removed soon.
> Microsoft removes 260 characters for NTFS Path limit in new Windows 10 insider preview | Great news!!! https://t.co/uT2iqx3gqi
> — Jeff Wouters [MVP] (@JeffWouters) May 30, 2016