Cache fails to be recreated after NuGet package update

[frederiktoft]

Description:
I have an Umbraco web project with four projects in the solution, with dependencies on each other. All four have packages.lock.json files and I have been able to make several succesful runs with the cache enabled. But after I have updated a nuget package, the cache fails to be recreated. Visual studio has updated the lock files correctly and they are all committed correctly.
This is an excerpt from my full workflow file:

env:
    NUGET_PACKAGES: ${{ github.workspace }}/.nuget/packages
# removed non-relevant steps that would otherwise be here
      - name: Setup dotnet 8
        uses: actions/setup-dotnet@v4
        with:
            dotnet-version: '8.0.x'
            cache: true
            cache-dependency-path: '**/packages.lock.json'

      - name: Restore NuGet packages
        run: sudo dotnet restore --locked-mode

if I outcomment cache: true the build proceeds and completes successfully. There have been no other changes since the last succesful run with cache enabled other than a few nuget packages has been updated.

Excerpt from the build log with the setup-dotnet step (changed a few names for privacy sake):

Run actions/setup-dotnet@v[4](https://github.com/xx/myapp/actions/runs/7870769631/job/21472666391#step:4:4)
  with:
    dotnet-version: 8.0.x
    cache: true
    cache-dependency-path: **/packages.lock.json
  env:
    BUILD_CONFIGURATION: Debug
    AZURE_APP_NAME: redacted
    RUNTIME_IDENTIFIER: win-x[6](https://github.com/xx/myapp/actions/runs/7870769631/job/21472666391#step:4:6)4
    NUGET_PACKAGES: /home/runner/work/myapp/myapp/.nuget/packages
/home/runner/work/_actions/actions/setup-dotnet/v4/externals/install-dotnet.sh --skip-non-versioned-files --runtime dotnet --channel LTS
dotnet-install: .NET Core Runtime with version '[8](https://github.com/xx/myapp/actions/runs/7870769631/job/21472666391#step:4:8).0.1' is already installed.
/home/runner/work/_actions/actions/setup-dotnet/v4/externals/install-dotnet.sh --skip-non-versioned-files --channel 8.0
dotnet-install: .NET Core SDK with version '8.0.[10](https://github.com/xx/myapp/actions/runs/7870769636/job/21472666393#step:4:10)1' is already installed.
Dotnet cache is not found

And this is for the post dotnet-setup process:

Post job cleanup.
Error: Cache folder path is retrieved for .NET CLI but doesn't exist on disk: /home/runner/work/myapp/myapp/.nuget/packages

So I think this obviously is related to the lock file being changed, and the task somehow fails to update the cache accordingly.

Task version:
v4

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:
Reproduction steps basically described above, but:

1. Have a .NET 8 web application fully set up with packages.lock.json files with github workflow, hosted ubuntu runners.
2. Enable dotnet-setup task cache as per documentation.
3. Update a nuget package in visual studio resulting in the packages.lock.json being updated accordingly.
4. Run the workflow build on github.

Expected behavior:
Task updates cache correctly so it can be reused in subsequent runs.

Actual behavior:
Cache is not updated, and fails because since the packages.lock.json hash has changed it cant find an existing cache with the correct hash.

[aparnajyothi-y]

Hello @frederiktoft, Thank you for creating this issue and we will look into it :)

[frederiktoft]

Hello @frederiktoft, Thank you for creating this issue and we will look into it :)

No problem. If you need more information from me, please say so and I will provide it ASAP.

[shaanmugapriya]

Hello @frederiktoft,

Thank you once again for sharing the details.

We have tried to reproduce the issue at our end. After updating nuget packages, we have faced some project reference issues in Visual Studio. Here are few suggestions that helped us to resolve the issue.

1. Kindly validate the restore step in log that all the projects were able to restore.

2. Verify if the local build is working fine in Visual Studio.
3. Remove the project references and add again. Then rebuild the solution.

This helped to resolve the issue. If you are still facing the issue after checking all the above scenarios, kindly help us with the actual log for restore step as well. Thanks!!

[aparnajyothi-y]

Hello @frederiktoft, Please let us know if you are facing the issue after checking all the above scenarios.

[aparnajyothi-y]

Hello @frederiktoft, Please let us know if you are facing the issue after checking all the above scenarios.

[aparnajyothi-y]

Closing this issue after two reminders. Please feel free to reach us in case of any further questions.