1

I have a solution with many projects, and we are migrating to .NET SDK style projects, but for now we have a mix of .NET framework style projects and .NET SDK style projects.

We are also migrating to GitHub actions, and this solution was building without errors previously, but the restore action started failing when dotnet was updated from 6.0.300 to 6.0.400 (update: I tried targeting 6.0.300 specifically in the setup-dotnet action, but it's throwing the same errors, so I'm not sure what changed to cause it to fail like this when it was working before.)

I updated our local action server to 6.0.400, and when I run the command dotnet restore ./path/to/solution.sln it is restoring the NuGet packages for just the .NET SDK style projects as expected.

dotnet is installed with this GitHub action

    - name: Setup .NET
      uses: actions/setup-dotnet@v2
      with:
        dotnet-version: 6.0.x

and restore is being called with this GitHub action

    - name: Restore dependencies
      run: dotnet restore ${{env.SOLUTION_FILE_PATH}}

and when dotnet restore is being run from the GitHub action, I am getting the following error error MSB4057: The target "Restore" does not exist in the project. for all of the .NET SDK style projects. It's as if it's trying to restore NuGet packages using the older .NET Framework style NuGet packages. This is very different than what I've seen before and is unexpected. I have a separate action for calling nuget restore ./path/to/solution.sln for restoring packages for the .NET framework style projects, and I'm expecting dotnet restore to only restore the .NET SDK style projects.

Has anyone else run into similar problems with dotnet 6.0.400? Are there better options for restoring NuGet packages in GitHub actions?

I'm not really sure where to look next because running the command line commands locally work exactly how I would expect them to, and it only behaves oddly when getting called from GitHub actions.

Update: I've been able to reproduce the failure locally by running the dotnet version that is being installed locally as part of actions/setup-dotnet@v2

If I run dotnet restore ... from the global install location C:\Program Files\dotnet\dotnet.exe then I get the following output which is what I expect

Determining projects to restore...
Restored C:\actions-runner\_work\MySolution\MySolution\src\FirstSdkProject\FirstSdkProject.csproj (in 335 ms). Restored C:\actions-runner\_work\MySolution\MySolution\src\SecondSdkProject\SecondSdkProject.csproj ( in 357 ms).

If I restore from the locally installed dotnet at C:\Users\MyUser\AppData\Local\Microsoft\dotnet then I get the unexpected output that I'm getting in the GitHub action

Determining projects to restore...
Determining projects to restore...
C:\actions-runner\_work\MySolution\MySolution\src\FirstSdkProject\FirstSdkProject.csproj : error MSB4057: The target "Restore" does not exist in the project.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
C:\actions-runner\_work\MySolution\MySolution\src\SecondSdkProject\SecondSdkProject.csproj : error MSB4057: The target "Restore" does not exist in the project.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Determining projects to restore...
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.
Nothing to do. None of the projects specified contain packages to restore.

Comparing the information on dotnet.exe, they are the exact same version of dotnet and using a file compare program they are binary the same, and the folders they are in are seemingly the same as well with only a few minor differences. Why would running restore have two very different outcomes just running from different locations?

TJ Rockefeller
  • 3,178
  • 17
  • 43
  • You are supposed to use `msbuild /t:restore`. – Lex Li Aug 29 '22 at 16:35
  • @LexLi I'm confused how `msbuild /t:restore` would help here because my issue is with restoring NuGet packages for .NET SDK projects. Isn't msbuild restore for the older .NET framework style projects? – TJ Rockefeller Aug 29 '22 at 16:41
  • Give it a try please. MSBuild works for all kinds of projects, as it is the default build engine in the ecosystem, while .NET CLI is .NET Core specific. – Lex Li Aug 29 '22 at 18:12
  • @LexLi tried it, and `msbuild /t:restore` does not restore the .NET SDK style projects giving this message in the log `The project file may be invalid or missing targets required for restore` – TJ Rockefeller Aug 29 '22 at 19:49
  • https://halfblood.pro/the-rough-history-of-msbuild-cc72a217fa98 Unfortunately there are too many MSBuild instances on the machine, so we are not talking about the same thing. You need to use the MSBuild instance compatible to .NET 6, which usually ships with VS 2022. – Lex Li Aug 30 '22 at 00:33
  • @LexLi this is a relatively new build server, and I'm using the action `microsoft/setup-msbuild@v1.0.2` to configure paths to msbuild on the server, and VS 2022 build tools are installed on the machine. The path configured for the GitHub build is C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin – TJ Rockefeller Aug 30 '22 at 13:09
  • 1
    Then you might collect MSBuild bin log and see what exactly happens under the hood, https://msbuildlog.com – Lex Li Aug 30 '22 at 14:49

1 Answers1

1

One of the main differences between a .NET Framework project and a .NET SDK project is how NuGet package references are managed. With .NET Framework projects, NuGet references are managed in packages.config. To build and restore including packages.config references you need the following

msbuild -t:build -restore -p:RestorePackagesConfig=true ./path/to/solution.sln

If you don't have mixed projects and they all follow the .NET SDK csproj format, then you won't have any packages.config references and you can build and restore with this.

msbuild -t:build -restore ./path/to/solution.sln

The option RestorePackagesConfig is only available on msbuild 16.5+ https://learn.microsoft.com/en-us/nuget/reference/msbuild-targets#restoring-packagereference-and-packagesconfig-projects-with-msbuild

TJ Rockefeller
  • 3,178
  • 17
  • 43