Hi Repka, you can use libraries generated by vcpkg in VS 2017 today, but you need VS 2015 to build the libraries. We are working on enabling the 2017 toolset for builds so that you'll have complete VS 2017 support. The goal is to have that ready by the time of the final RTW release.
a) A prebuild action which runs "vcpkg install <x> <y> <z>" for every package you'd like to depend on
b) (for open source projects) A readme doc which gives users a one-liner for each platform you support: apt-get, brew, yum, vcpkg, pacman, etc.
2. Vcpkg is completely relocatable and you can have completely independent version sets side-by-side. We didn't mention it in the video, but every vcpkg enlistment has a props file that you can use to override the "user-wide" system we demoed.
3. We wield the "ports\" directory as our Lock file -- it specifies exactly what versions are desired and how to build them. For closed source projects, vcpkg is perfectly suitable to be either checked in directly or included via submodule/subtree.
4. I'm not 100% sure what you mean here, but the intention is that every library in vcpkg is made available to every part of your "process" (so, exe + any dlls). In this way, it serves to make libraries look and feel like the Windows SDK.
5. Today, you can drop in (or override) any additional ports you'd like into the "ports\" directory and they'll instantly become available. In the future, we do want to support this scenario better though! We have an active issue on GitHub to discuss it and I'd love to have your perspective: https://github.com/Microsoft/vcpkg/issues/114