WSL dotnet clean error MSB4018 The "ResolvePackageAssets" task failed unexpectedly.

[cschuchardt88]

Describe the bug

When running dotnet clean on my projects solution file I get an error with Microsoft.PackageDependencyResolution.targets of MSB4018. Not sure if other projects have this problem. I am using Ubuntu 24.04.1 LTS in WSL. This is clean install of dotnet sdk.

To Reproduce

My project is too complex. However it should still be a problem. If the dotnet sdk only works with basic projects then what's the point of supporting all the features in dotnet. So I'm not going to bother to even upload project or reference it.

Exceptions (if any)

This on every project, in the solution.

RpcServer failed with 1 error(s) (0.2s)
    /usr/lib/dotnet/sdk/9.0.103/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error MSB4018:
      The "ResolvePackageAssets" task failed unexpectedly.
      NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder 'C:\Program Files (x86
      )\Microsoft Visual Studio\Shared\NuGetPackages'.
         at NuGet.Packaging.FallbackPackagePathResolver..ctor(String userPackageFolder, IEnumerable`1 fallba
      ckPackageFolders)
         at Microsoft.NET.Build.Tasks.NuGetPackageResolver.CreateResolver(IEnumerable`1 packageFolders)
         at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheWriter..ctor(ResolvePackageAssets task)
         at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader.CreateReaderFromDisk(ResolvePackageAs
      sets task, Byte[] settingsHash)
         at Microsoft.NET.Build.Tasks.ResolvePackageAssets.CacheReader..ctor(ResolvePackageAssets task)
         at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ReadItemGroups()
         at Microsoft.NET.Build.Tasks.ResolvePackageAssets.ExecuteCore()
         at Microsoft.NET.Build.Tasks.TaskBase.Execute()
         at Microsoft.Build.BackEnd.TaskExecutionHost.Execute()
         at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(TaskExecutionHost taskExecutionHost,
       TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToE
      xecuteTask)

Further technical details

// uname -a
Linux PC01 5.15.167.4-microsoft-standard-WSL2 #1 SMP Tue Nov 5 00:21:55 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

// dotnet --info
.NET SDK:
 Version:           9.0.103
 Commit:            c4e5fd73fe
 Workload version:  9.0.100-manifests.e611c4b6
 MSBuild version:   17.12.24+c4e5fd73f

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  24.04
 OS Platform: Linux
 RID:         ubuntu.24.04-x64
 Base Path:   /usr/lib/dotnet/sdk/9.0.103/

.NET workloads installed:
There are no installed workloads to display.
Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.2
  Architecture: x64
  Commit:       c4e5fd73fe

.NET SDKs installed:
  8.0.112 [/usr/lib/dotnet/sdk]
  9.0.103 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.12 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.2 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.12 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.2 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  /mnt/r/github/cschuchardt88/neo/global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[baronfel]

do you have self-contained reproduction steps, or a binlog we can use to investigate the MSBuild logic? I personally would expect the use of the VS fallback folder (C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages) to be a smell in modern .NET project.

[cschuchardt88]

I believe the task thinks I'm on Windows vs Linux WSL. Even though sdk can detect the correct OS. I know msbuild tasks can't 100% tell which OS you are on.

Here you are
dotnet.clean.binlog.zip

[baronfel]

Thanks for the binlog, it was enlightening! We may need to call in the NuGet team for this one. What I think has happened is that you performed some action on a Windows host that triggered a restore, and so NuGet wrote a project.assets.json that contained Windows-style paths. Here's a snippet from the project.assets.json for the project that's failing:

"packageFolders": {
    "C:\\Users\\<user>\\.nuget\\packages\\": {},
    "C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\NuGetPackages": {}
  },
  "project": {
    "version": "3.7.5",
    "restore": {
      "projectUniqueName": "R:\\<some_root>\\neo\\src\\Plugins\\RpcServer\\RpcServer.csproj",
      "projectName": "Neo.Plugins.RpcServer",
      "projectPath": "R:\\<some_root>\\neo\\src\\Plugins\\RpcServer\\RpcServer.csproj",
      "packagesPath": "C:\\Users\\<user>\.nuget\\packages\\",
      "outputPath": "R:\\<some_root>\\neo\\src\\Plugins\\RpcServer\\obj\\",
      "projectStyle": "PackageReference",
      "fallbackFolders": [
        "C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\NuGetPackages"
      ],
      "configFilePaths": [
        "R:\\<some_root>\\neo\\NuGet.Config",
        "C:\\Users\\<user>\\AppData\\Roaming\\NuGet\\NuGet.Config",
        "C:\\Program Files (x86)\\NuGet\\Config\\Microsoft.VisualStudio.FallbackLocation.config",
        "C:\\Program Files (x86)\\NuGet\\Config\\Microsoft.VisualStudio.Offline.config"
      ],
      "originalTargetFrameworks": [
        "net9.0"
      ],
      "sources": {
        "C:\\Program Files\\dotnet\\library-packs": {},
        "https://api.nuget.org/v3/index.json": {},
        "https://www.myget.org/F/neo/api/v3/index.json": {}
      },

Then, the clean command was invoked on the WSL side and it tried to use those paths. I think there may be a fundamental mismatch in the way assets files are invoked - they seem to contain platform-specific components, and so if you switch platforms in a single working session (e.g. cd to a Windows location, dotnet build, and then wsl to enter into a WSL workspace) that will never work as things are implemented today.

The SDK uses this project.assets.json file to determine which files should be referenced by your project, but a big part of that is calling into NuGet APIs to tell us more about the packages involved - if those APIs aren't expecting cross-platform scenarios like this, that's the root of the problem.

cc @nkolev92 / @zivkan for feedback on my hypothesis here.

[cschuchardt88]

So if I delete $(IntermediateOutputPath) path for each project in the solution I should be good?