dotnet build fails with --no-restore and --artifacts-path

Describe the bug

dotnet build fails when specifying the --no-restore and --artifacts-path options together.

The restore is done separately in order to use lock files, since dotnet build doesn't support --locked-mode like dotnet restore does.

To Reproduce

See this project for complete reproduction steps:

https://github.com/paulmedynski-microsoft/dotnet-build-issues

Exceptions (if any)

$ dotnet build -c Release --no-restore --artifacts-path artifacts
/usr/share/dotnet/sdk/8.0.300/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1004: Assets file '/home/paul/dev/paulmedynski/dotnet-build-issues/artifacts/obj/dotnet-build-issues/project.assets.json' not found. Run a NuGet package restore to generate this file. [/home/paul/dev/paulmedynski/dotnet-build-issues/dotnet-build-issues.csproj]

Build FAILED.

Further technical details

.NET SDK:
Version: 8.0.300
Commit: 326f6e68b2
Workload version: 8.0.300-manifests.c1c70047
MSBuild version: 17.10.4+10fbfbf2e

Runtime Environment:
OS Name: debian
OS Version: 12
OS Platform: Linux
RID: linux-x64
Base Path: /usr/share/dotnet/sdk/8.0.300/

.NET workloads installed:
There are no installed workloads to display.

Host:
Version: 8.0.5
Architecture: x64
Commit: 087e15321b

.NET SDKs installed:
8.0.300 [/usr/share/dotnet/sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 8.0.5 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
None

Environment variables:
Not set

global.json file:
Not found

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

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

[baronfel]

Good find - we missed adding the --artifacts-path option to dotnet restore. In the meantime you can work around this by adding -p ArtifactsPath=./artifacts on your dotnet restore call. The big thing is that you need to make sure that the Restore writes the cached files to the same location that the build expects to see them.

The -p ArtifactsPath option appears to be relative to the .csproj file being restored. For the sample project I linked, it doesn't matter because the only project is in the repo root. For more complicated solutions with projects in a variety of sub-directory depths, using -p ArtifactsPath during a solution-wide restore would be problematic. In this case, you can issue individual dotnet restore -p ArtifactsPath=../../../artifacts with the relative path as appropriate.

I've updated the linked project to suggest using -p ArtifactsPath.

[baronfel]

What I described is essentially the equivalent of what the .NET CLI does today for the other commands that do support the artifacts path option - the primary difference is that I didn't specify a fully-qualified path to the directory, which is definitely what I'd suggest if you were building in a multi-project scenario! You can specify any file path you'd like, but that path is evaluated per project, just like every MSBuild property.

[MasterMann]

Same happens with dotnet publish, ignores the --artifacts-path parameter. I might create a separate issue, if applicable/valid

[DanOpcode]

Seems like this is fixed now?