sdk: Unable to find fallback package folder

Steps to reproduce

  1. Start with a clean Windows box and install Visual Studio Enterprise 2017 (latest) with .NET Core.
  2. Clone https://github.com/azure/azure-iot-sdk-csharp and run jenkins\windows_csharp.cmd in root.

Expected behavior

Builds works as expected.

Actual behavior

BUILD: --- SecurityProvider for TPM Debug ---
Microsoft (R) Build Engine version 15.6.82.30579 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018: The "ResolvePackageDependencies" task failed unexpectedly. [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018: NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder 'C:\Users\cipop\.dotnet\NuGetFallbackFolder'. [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018:    at NuGet.Packaging.FallbackPackagePathResolver..ctor(String userPackageFolder, IEnumerable`1 fallbackPackageFolders) [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018:    at Microsoft.NET.Build.Tasks.NuGetPackageResolver.CreateResolver(LockFile lockFile, String projectPath) [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.get_PackageResolver() [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.ResolvePackagePath(LockFileLibrary package) [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018:    at Microsoft.NET.Build.Tasks.ResolvePackageDependencies.GetPackageAndFileDefinitions() [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute() [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() in E:\A\_work\82\s\src\Build\BackEnd\TaskExecutionHost\TaskExecutionHost.cs:line 631 [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]
C:\Program Files\dotnet\sdk\2.1.101\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__25.MoveNext() in E:\A\_work\82\s\src\Build\BackEnd\Components\RequestBuilder\TaskBuilder.cs:line 787 [S:\cs\security\tpm\src\Microsoft.Azure.Devices.Provisioning.Security.Tpm.csproj]

Environment data

dotnet --info output:

dotnet --info
.NET Command Line Tools (2.1.101)

Product Information:
 Version:            2.1.101
 Commit SHA-1 hash:  6c22303bf0

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.101\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.6
  Build    : 74b1c703813c8910df5b96f304b0f2b78cdf194d

There is something interesting in the Users folder:

USERNAME=cipop
USERPROFILE=C:\Users\cipop.CORP

> dir c:\Users\ /b
Administrator
cipop
cipop.CORP
Public

Seems to be related to dotnet/sdk#8578, dotnet/sdk#8536, dotnet/sdk#8578, dotnet/sdk#8680 .

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 45 (20 by maintainers)

Most upvoted comments

If you are using Docker and getting this error, make sure you have a .dockerignore and do not copy over the bin and obj files.

**/bin
**/obj
**/out
**/.vscode
**/.vs
.dotnet
.Microsoft.DotNet.ImageBuilder

VIA: https://github.com/dotnet/dotnet-docker/blob/master/.dockerignore

Workaround:

mkdir C:\Users\cipop\.dotnet\NuGetFallbackFolder

I have the same error, but on Windows Subsystem Linux, Bash on Ubuntu on Windows

/usr/local/dotnet/sdk/2.1.101/Sdks/Microsoft.NET.Sdk/build/Microsoft.PackageDependencyResolution.targets(172,5): error MSB4018: NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder 'C:\Program Files\dotnet\sdk\NuGetFallbackFolder'. [/mnt/d/code/bb-aiv/municipality-registry/src/MunicipalityRegistry.Api.Oslo/MunicipalityRegistry.Api.Oslo.csproj]

Which makes sense, since there is no C:\ either it is ~/.dotnet or /mnt/c/

At least I was able to find the file where the entry resides: C:\Program Files (x86)\NuGet\Config\Xamarin.Offline.config contains:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <fallbackPackageFolders>
    <add key="Xamarin Offline Packages" value="C:\Microsoft\Xamarin\NuGet\"/>
  </fallbackPackageFolders>
</configuration>

Renaming the file to Xamarin.Offline.config.bak (adding .bak) helped for me. No need for a C:\Microsoft\... directory in the root of my drive and no need to add <RestoreFallbackFolders>clear</RestoreFallbackFolders> to each and every project.

Now only to find out what (else) was in that C:\Microsoft\... directory and what else broke when I deleted it… I probably broke Xamarin, but I don’t use that (for now) anyway. I just happened to check the box when installing VS2019 thinking “maybe, someday, why not already install it?”

I’ve “fixed” it by not relying on the fallback folder:

  <PropertyGroup>
    <RestoreFallbackFolders>clear</RestoreFallbackFolders>
  </PropertyGroup>

In my case i was using the Linux Subsystem (Ubuntu 18.04) and had Visual Studio 2019 still open in windows. This may block some file handles and can fail your build with this misleading error. Closing VS and performing clean and than build fixed it.

I “fixed” it via remove dotnet clean before dotnet restore in my Dockerfile

And please, for goodness sake, don’t make us wait for .NET 6 for this to be addressed.

FWIW: This error was observed in VSfM (VS for Mac) 2019 in a multi-project solution. It manifested on only 2 projects - a supplemental project and a test project not related to the former project. Again, this is on Mac not Windows environment! I understand that most folks here are reporting and posting re:Windows, but I think adding my 2c to the thread will be beneficial to folks like myself (Mac users). Mainly because this thread is very high in the Google search results related to the issue.

So, without further ado – VS has had long standing problem with ‘Cleaning’ a solution and contained projects. In my case there were only two offending projects, name and structure are irrelevant to the solution:

For each of the affected projects – manually delete each one’s “obj” and “bin” folders!

That did it for me!

I don’t want to have to add this to each and every project and I also don’t want some “C:\Microsoft\Xamarin” folder in the root of my drive - stuff just doesn’t belong there. And I sure as hell didn’t put it there.

Exactly! Who the hell had the idea to place the folder on the root drive?!

I deleted some folder in the root of my C: drive (C:\Microsoft\Xamarin) after I got a new workstation and had (clean) installed Windows 10 & VS2019. I should’ve known… But the folder was empty (I guess? I’m quite sure I checked it and must’ve thought it was some leftover installer residue file, I don’t make it a habit to delete folders actually containing files (and I have showing hidden files turned on)). Anyway:

Error occurred while restoring NuGet packages: The local source 'C:\Microsoft\Xamarin\NuGet\' doesn't exist.
1>------ Build started: Project: ConsoleApp1, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(164,5): error MSB4018: The "GetPackageDirectory" task failed unexpectedly.
1>C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(164,5): error MSB4018: NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder 'C:\Microsoft\Xamarin\NuGet\'.
1>C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(164,5): error MSB4018:    at NuGet.Packaging.FallbackPackagePathResolver..ctor(String userPackageFolder, IEnumerable`1 fallbackPackageFolders)
1>C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(164,5): error MSB4018:    at Microsoft.NET.Build.Tasks.NuGetPackageResolver.CreateResolver(IEnumerable`1 packageFolders)
1>C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(164,5): error MSB4018:    at Microsoft.NET.Build.Tasks.GetPackageDirectory.ExecuteCore()
1>C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(164,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute()
1>C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(164,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
1>C:\Program Files\dotnet\sdk\3.1.201\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(164,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
1>Done building project "ConsoleApp1.csproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

image

I did happen do have a WSL open (Debian, but I also have a Ubuntu WSL) but closing that and VS2019 didn’t help; even after a dotnet clean:

image

Or dotnet restore:

image

My %appdata%/nuget/nuget.config contains no reference to “C:\Microsoft.…” at all:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <bindingRedirects>
    <add key="skip" value="False" />
  </bindingRedirects>
  <packageManagement>
    <add key="format" value="0" />
    <add key="disabled" value="False" />
  </packageManagement>
</configuration>

@CumpsD suggestion here worked for me. But creating a new project results in the same error.

I don’t want to have to add this to each and every project and I also don’t want some “C:\Microsoft\Xamarin” folder in the root of my drive - stuff just doesn’t belong there. And I sure as hell didn’t put it there. Howver, simply creating the directory does help. For now.

I am now literally scanning my entire C: drive for any files containing C:\Microsoft\Xamarin as to find out where that setting could be buried…

Totally agree with @yannduran. If we have to wait for a year for an easy-to-done fix, something is terribly wrong. A software by definition means a changeable product. If you can change it or at least easily, it isn’t a software.

I do work at Microsoft, but I have not worked on this project for a long time.

This Xamarin folder does not appear related to the SDK or the root cause of this closed bug. I am not sure how best to reach the Xamarin tooling owners, but I think that’s who should look at this next. @KathleenDollard @marcpopMSFT can you help route this?

@nguerrera (I’m assuming you work for Microsoft)

Is Microsoft going to do anything about moving this folder out of the root directory, other than keep closing this issue? Why are the people saying this is a problem being ignored? If there’s a better issue for this to be discussed, please mention it here.

This is a ridiculous place to have this folder and people are going to keep deleting it, as it’s usually empty and it’s best practice to NOT have random folders in the root anyway. Microsoft doesn’t care about consistency or that it’s violating what it advises us to not do?

If it’s intended to be a machine-wide folder, It should have gone into C:\Program Files (x86)\NuGet\Xamarin as the NuGet folder already exists. If it’s intended to be a user folder, it should be somewhere in %localappdata%/nuget (the most obvious choice) or even somewhere in %appdata%/nuget. The one place it should NOT be in is in the root of the Windows drive.

@nguerrera Hi there! You closed this but the problem remains. Would be better to hear the feedback and fix it?

The Xamarin specific NuGet issue is being tracked in this developer community ticket

I’ve asked around internally to see who owns this particular config file and offline cache. We’ll get this over to the correct person to comment on why this is the folder used. Thanks.

Indeed, the easy solution here is to put the Xamarin fallback setting into %localappdata%/nuget and that is it. I can’t believe it that we have to discuss it and complain about it for years now. 😒

@nguerrera

Thanks for your reply/help Nick!

got "Unable to find fallback package folder 'C:\Program Files (x86)\Xamarin\NuGet" awsome. When coding VS code Azure function. dotnet restore saved my day.

@CumpsD I would treat this as a different issue from this one. If this is consistently happening to you, please file a separate issue with repro steps and we can take a look.

@nkolev92 this is already the CLI repo 😄