In previous post, we have written several tutorial about common error that you can find when you publish your ASP.NET website. In this article, you might find new error message when deploying ASP.NET Core website.
If you are writing an ASP.NET Core application, there are chances to publish your your ASP.NET Website to your hosting provider, 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.
Cause
While creating a package to publish, it uses the following path:
C:\Users\[USERNAME]\AppData\Local\Temp\PublishTemp\[ProjectName][LengthOfProjectFullName]
For example, I’m using Andriy 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:
C:\Users\Andriy\AppData\Local\Temp\PublishTemp\MyProject163
In addition to that, an ASP.NET Core 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
Please type run -> open your command prompt:
SystemDrive=C: SystemRoot=C:\WINDOWS TEMP=C:\Users\Andriy\AppData\Local\Temp TMP=C:\Users\Andriy\AppData\Local\Temp USERDOMAIN=Your_Username USERNAME=Andriy USERPROFILE=C:\Users\Andriy
There are two environment variables – TEMP and TMP. This determines your temp directory. Therefore, change it to a shorter ones like:
TEMP=C:\Temp TMP=C:\Temp
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 application, you will find the line almost at the bottom
<Import Project="$(VSToolsPath)\DNX\Microsoft.DNX.targets" Condition="'$(VSToolsPath)' != ''" />
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:
<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>
Here’s the magic property – PublishOutputPathNoTrailingSlash. This property is used at the bottom of that targets file like:
<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)"/>
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:
<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 application. I hope that Microsoft will update Visual Studio that the publish path can be customised by individual project rather than sticking onto the default temp path.
Andriy Kravets is writer and experience .NET developer and like .NET for regular development. He likes to build cross-platform libraries/software with .NET.
