Long Path Error While Publishing ASP.NET Core Applications

If you are writing an ASP.NET Core application, there are chances to publish your app to either a 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.

Cause

While creating a package to publish, it uses the following path:

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:

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

There are two environment variables – TEMP and TMP. This determines your temp directory. Therefore, change it to a shorter ones like:

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:

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:

Here’s the magic property – PublishOutputPathNoTrailingSlash. This property is used at the bottom of that targets file like:

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:

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.