search

microsoft / vcpkg

C++ Library Manager for Windows, Linux, and MacOS
MIT License
23.14k stars 6.38k forks source link

vcpkg fails to deploy dependencies for managed projects #41782

Open FrayxRulez opened 6 days ago

FrayxRulez commented 6 days ago

Starting from this commit vcpkg fails to deploy dependencies to my MSBuild solution where the entry point is a C# project referencing multiple C++ ones.

This seems to be caused by the addition of and '@(Link)' != '' to AppLocalFromInstalled conditions, removing the check seems to restore the old behavior where DLLs get successfully copied to both vcxproj and csproj output folders.

I use classic vcpkg without any manifest.

MonicaLiu0311 commented 3 days ago

@BillyONeal Can you help take a look at this issue?

BillyONeal commented 2 days ago

As far as I know .csproj was never intended to be used with this, and not engaging vcpkg's customizations for .csproj was, in fact, the whole purpose of that change. People were complaining that projects unrelated to C++ were slowed down by our attempt to deploy applocal DLLs.

Can you describe what you were actually trying to do here?

FrayxRulez commented 2 days ago

I just have a C# project referencing a few C++ projects (C++/WinRT) that happen to use VCPKG, so I’d expect these vcpkg dependencies to be transitive. As I build the C# project, all the C++ binaries get copied by MSBuild to the output folder as they’re needed by the final executable to run, if all the VCPKG ones are then missing the thing is just going to crash on launch.

BillyONeal commented 1 day ago

I don't think restoring running applocal.ps1 in .csproj is correct here; adding an explicit way to ask for it might make sense.

BillyONeal commented 1 day ago

Actually, I go back to being confused at what this would have ever done:

https://github.com/microsoft/vcpkg/blob/1174c9ea1d02461e52be88ac932b3d7410e3ffe6/scripts/buildsystems/msbuild/vcpkg.targets#L202

$(TargetPath) will be pointing at your C# code in .csproj world, if it exists at all.

FrayxRulez commented 22 hours ago

The script worked as I would (personally) expect before your change, and it still works today by removing the check on @(Link). I still feel that's quite reasonable for dependencies to be transitive: if I have a reference chain such as A.vcxproj -> B.vcxproj -> C.csproj, in the final bin directory I'll find A.dll, B.dll and C.dll, why the same behavior shouldn't exist if the dependency comes in the form of a vcpkg package rather than any other way? (NuGet packages are transitive as well, same applies for VSIX extensions and so on). So, I'm not really arguing on whether or not this should be done, I'm more interested in getting the "old" behavior restored.