One of the dependent projects has a required reference to the Nest
nuget package.
Did you call Nest's function in the dependent project? VS will not copy the dependent project's assembly into top-level project if it finds the dependent project doesn't actually call(need) the assembly in code.
Why does this occur? Shouldn't installing the Nest package on the
dependent project resolve this dependency?
I'm not sure the cause of the issue with info available in your question, many factors can cause the strange behavior and sometimes VS version would also affect it...
Assuming you have a top-level project A and it depends on project B using Project Reference.
1.If both them targets .net framework, please make sure they use the same way to manager nuget packages.(Both using packages.config or both using PackageReference)
2.If A is .net framework project while B is .net standard project, please make sure the A is also using PackageReference format to manage nuget packages.
Cause .net standard(new SDK format) uses PackageReference packages, if A uses Packages.config and reference B, the build system will be confused about the different nuget formats in the build process. And we won't find the Nest.dll copied from B's output folder to A's output folder.
For this situation, try adding <RestoreProjectStyle>PackageReference</RestoreProjectStyle> into top-level A's project file.(xx.csproj) It will make sure both A and B can be restored as PackageReference style.
3.If A is .net framework with packageReference, and B is .net framework with Packages.config, right-click the packages.config and choose Migrate Package.config to PackageReference button. Also you may get some help from this document.
4.If your top-level project is .net core and B project targets .net standard, in VS2017, the nest.dll won't be copied into A's output folder, you can try adding <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> to your A.csproj to resolve this issue. Similar issue see here. (And VS2019 16.3.8 has fixed this issue, this issue mostly occurs in VS2017)
And this behavior is also affected by VS version, if you're using VS2017, please update it to latest 15.9.17 for better experience. If you're using VS2019, please update it to 16.3.8.
Hope it helps :)