Currently WIL dependency is referenced via git submodules. Maybe use NuGet package instead? Also, move GSL to NuGet and then reference it will be cool, but probably it's an issue for GSL repo.
The problem is that package management is not unified and I suppose that moving all dependencies to NuGet will be easier to support
Since those are C++ dependencies and NuGet is mostly used for managed dependencies, it would make more sense to use vcpkg to get wil and gsl from.
Unfortunely, I'm not a C++ dev, so not sure about C++ package managers, but as I thought, it's not a problem
But adding another package manager is not a solution, anyway. It just will make the situation worse. What I wanted to state is that better when there is only one way of managing dependencies.
The right tool for the right job. NuGet is terrible for C++ dependency management.
So, we've discussed this with the GSL team. Because they're a headers-only library, shipping a nuget really _really_ doesn't make any sense for them. Their official guidance was to use a submodule.
I don't think we even knew that there was a WIL nuget - looks like it's really new, so that explains why. @DHowett-MSFT /@miniksa thoughts?
I chose to vend WIL as a submodule when they open-sourced because the VS project system has _only very poor_ support for nuget packages against C++ projects. It _exists_, but it's really unpleasant -- you can't have transitive dependencies living in .props files, for example, because while ItemGroup.PackageReference is a thing, it only applies to _literally everything but C++_.
There may be some longstanding ill will here. :smile:
I've ported wil to vcpkg so now it's possible to use it for both gsl and wil: https://github.com/microsoft/vcpkg/pull/6353
We talked to the vcpkg team yesterday about using vcpkg for things like this given that vcpkg seems to be the solution to C/C++ package management where nuget is more for managed code like C#.
We just haven't had the mental capacity to fully internalize what it would mean to get vcpkg up and going.
I believe it's probably the right solution because the vcpkg team is smart and knows this space better than we do. I'm also reticent to adding a third package manager, but I also want to do what experts say is right.
Most helpful comment
Since those are C++ dependencies and NuGet is mostly used for managed dependencies, it would make more sense to use vcpkg to get wil and gsl from.