What is the correct way to run a target before/after Restore?

[tlmii]

Steps to reproduce

1. Create a solution
2. Add a project
3. Edit the .csproj to add a target like

<Target Name="MyTarget" AfterTargets="Restore">
  <!-- Whatever you want it to do -->
</Target>

4. From command line, run msbuild on your project, with restore and generate a binlog msbuild YourProjectName.csproj /r /bl
5. Look at the msbuild.binlog file that's generated. MyTarget will be immediately after the Restore target.
6. From command line, run msbuild on your solution with restore and generate a binlog msbuild YourSolutionName.sln /r /bl
7. Look at the msbuild.binlog file that's generated. MyTarget will not be run at all.

Expected behavior

MyTarget target is run after Restore target.

Actual behavior

MyTarget target is never run

Environment data

msbuild /version output:

Microsoft (R) Build Engine version 16.5.0-preview-19562-03+d72e25031 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

16.5.0.56203

OS info:win

Other info

1. The same thing is true for BeforeTargets as AfterTargets as far as I can tell.
2. It looks like the problem is because there is no Restore target on the individual project when building from the solution. There is just one "meta" Restore target no matter how many projects are in the solution

Question

So the question then becomes, how do we do this properly? I want to do some extra restore stuff whenever a restore is done, but not worry about it at build time.

[rainersigwald]

This is happening because NuGet has different restore flows when invoked at the solution level and the project level. At the project level, the Restore target in the project is called, because that's the entry point of the build. At the solution level, the Restore target in the solution does something different: it collects reference information from all of the projects in the solution, then does the restore operation for the solution all at once. This can be much faster than doing restore for each project in turn.

If you want to customize solution restore, you can use solution build extensibility to call your custom target for each project in the solution before/after the (solution's) Restore target is called.

If you want to run per-project and don't depend on the NuGet restore result, you might be able to hook the target NuGet uses to collect information from each project in addition to Restore, but I'm not sure if that's a documented, public extensibility point.

cc @jeffkl, @nkolev92

[tlmii]

This is happening because NuGet has different restore flows when invoked at the solution level and the project level. At the project level, the Restore target in the project is called, because that's the entry point of the build. At the solution level, the Restore target in the solution does something different: it collects reference information from all of the projects in the solution, then does the restore operation for the solution all at once. This can be much faster than doing restore for each project in turn.

That matches my understanding of the underlying situation, so thank you for confirming.

If you want to run per-project and don't depend on the NuGet restore result, you might be able to hook the target NuGet uses to collect information from each project in addition to Restore, but I'm not sure if that's a documented, public extensibility point.

This was exactly the route we were examining as an alternative, but were hesitant to take a dependency on what seemed like implementation details. It looks like either _IsProjectRestoreSupported or _GenerateRestoreProjectPathWalk would work for our specific solution right now - just not sure if that's a good long term solution.

[nkolev92]

@tmlii

You are correct to be hesitant about any targets prefixed with _.

Can you elaborate more about your scenario?
What are you trying to customize?

There's a further complication to the issues summarized by both you and @rainersigwald and that's that NuGet Visual Studio restore is not run by a target.

[tlmii]

The short answer is that we're essentially trying to run npm ci as part of an otherwise mostly msbuild/C#-driven development project. We thought it would be nice to tie in the target that executes that with the restore process in msbuild (at least) and VS (if possible) since they are roughly equivalent concepts. We might not end up going down this route (mixing the worlds is fraught anyway) but wanted to see if it was even possible.

[nkolev92]

Unfortunately, there is no way to hook on to restore in Visual Studio in a performant way.
For that reason I'd recommend not doing it if at all possible.
The Collect* targets in NuGet are an extensibility mechanism, but meant only for lightweight operations.

[stan-sz]

See related NuGet/Home#4781

[Liero]

I have a dotnet-tools.json defined at solution level.

Some projects in the solution depends on the dotnet tools.

How to ensure, that the dotnet tools are restored, when either, solution or a project is build?

I guess, ideal would be a variable flag, that could flow across projects when building solution...

[AraHaan]

you could just tell them that your project depends on the tools being restored first before trying to open it in devenv.

[sreelekshmip]

I am using msbuild /restore to retore the packages and then invoked devenv to build the solution. The commands are included in a batch file and this file is integrated to CI pipeline. The batch commands are as shown below.

---

_msbuild MySolution.sln -t:Restore

"%VS160COMNTOOLS%..\IDE\devenv" "MySolution.sln" /build "%Build%|x64" /out MySolution.log
if errorlevel 1 goto :failed_

---

'MySolution.sln' includes two projects- a library project and a WPF application. The packages referenced in the projects are specified in a Packages.props file.

The build results are inconsistent. Sometimes it fails with following errors.

CSC : error CS2001: Source file '\obj\DDLStyleEditor\Views\ElementGroupView.g.cs' could not be found.
CSC : error CS2001: Source file '\obj\DDLStyleEditor\Views\OptionsView.g.cs' could not be found.
CSC : error CS2001: Source file '\obj\DDLStyleEditor\Views\PropertiesView.g.cs' could not be found.
CSC : error CS2001: Source file '\obj\DDLStyleEditor\Views\MainView.g.cs' could not be found.

It works fine with VS2019, the packages are properly restored and the solution build successfully. Then why does it fail with batch file??. Please help.