Nuget package restore and imports fail in Visual Studio when additional fallback folder path is too long

[fredrikhr]

Issue Description

When using packages in a Nuget Fallback folder using the RestoreAdditionalProjectFallbackFolders MSBuild property, Visual Studio behaves strangely when opening the solution and when restoring packages.

When a package restored from the fallback folder contains build artifacts (i.e. .props or .targets files), Visual Studio shows an error message that the including project's .nuget.g.props file cannot import the package's .props file due to the file being invalid.
During a build in Visual Studio the NuGet package restore fails with an error message stating that the referenced .nuspec file could not be found.

Steps to Reproduce

1. Create a deeply nested folder structure somewhere creating a very long path
2. Unzip a nupkg from a local package (or otherwise not listed on public Nuget feeds) to a subdirectory underneath the directory created in step 1.
   The package must contain .props or .targets files in its build folder.
3. Create a new Visual Studio solution and project somewhere.
4. Add the MSBuild property RestoreAdditionalProjectFallbackFolders to the newly created project and set it to the long path created in step 1.
5. Add a package reference to the private package used in step 2. Make sure the package is not normally restorable, so that Nuget will use the specified fallback folder for restore.
6. Close and reopen the project in Visual Studio Note errors shown in the Visual Studio error list (even before performing any build action)
7. Build the solution
   Note the Nuget package restore error message

Expected Behavior

Visual Studio should not fail to load projects because they refer to Nuget packages restored from fallback folders with too longs paths. Or if that was an expected failure, the error message should not say the file was invalid.

Visual Studio build should behave similarly to a command-line build.

Actual Behavior

When opening a solution with a project that depends on Nuget packages restored from a fallback folder using a long path Visual Studio shows the following error message in the Error List window:

Project ".....\packages\FallbackPathPackageWithProps\1.0.0\build\FallbackPathPackageWithProps.props" was not imported by "......\obj\MyProject.csproj.nuget.g.props" at (23,5), due to the file being invalid.

When selecting Build solution the Build output in the Output window shows:

NuGet package restore failed. Please see Error List window for detailed warnings and errors.
Error occurred while restoring NuGet packages: Could not find a part of the path '.....\packages\FallbackPathPackageWithProps\1.0.0\FallbackPathPackageWithProps.nuspec'.

Analysis

Despite the error messages shown i Visual Studio I was able to verify that both the .props file to import and the .nuspec file were files available on the file system and they contained valid XML according to the MSBuild XSD and the Nuget package specification XSD.

Deeper investigation has shown that this is probably related to paths becoming too long when the package located within one of the paths specified by RestoreAdditionalProjectFallbackFolders is stored in a Path exceeding a certain length (probably MAX_PATH). The issue does not occur in similar situations when the path is comparably short.

When opening the project in Visual Studio Code, or when building from the command-line using either MSBuild.exe (from Developer Command Prompt for VS) or dotnet restore, dotnet build no errors occur and both restore and build succeed without problems.

It is possible to provoke this behaviour when cloning (recursively) the repository https://github.com/fredrikhr/powerplatform-extras to a location with a reasonably long path. It includes a setup where Nuget packages are locally built within the repository structure and subsequently imported from a repository-local fallback folder.

Versions & Configurations

Visual Studio 2026, November 2025 Feature Update, version 18.0.0

But has also occurred previously in Visual Studio 2022.

[MichalPavlik]

Thank you for the feedback. As you experience the issue in Visual Studio, the best way to track the progress is here: https://developercommunity.visualstudio.com/t/allow-building-running-and-debugging-a-net-applica/351628