Running nuget restore from VS does not work for sample projects

[harinikmsft]

It appears that all sample projects in RNWCPP are restoring nugets to the wrong location when this is done through VS. Something in the toolchain needs to be fixed so that we don't need to do nuget restore manually every time.

[kmelmon]

Rob Relyea says:

By default, when you use Packages.Config, the following happens:
• Each solution has its own solution packages folder
With PackageReference, we don’t put things in a solution packages folder, but instead put things in a user-wide folder that all solutions can access: %userprofile%.nuget\packages by default.

In order to properly restore and build a solution which has some packages.config:
Nuget.exe restore solutionName.sln
Msbuild

So if you are trying to restore and build 4 solutions, do that.

In RNWCPP\nuget.config you had a setting of repositoryPath.

So I think there are a few options:

A) Remove repository path setting in RNWCPP\nuget.config
This will mean both playground will have a solution packages folder, and so will RNWCPP.
B) Or Keep the setting of repositoryPath to packages
This will make all restores done under the RNWCPP folder use RNWCPP\packages
If you want to do this, you need to hand edit the projects used by Playground.sln to point to that location, instead of the original location.*.sln
(Or you can load the solution into VS, go to the Package Manager Console, switch the drop down to the projects which appear to have bad paths – Folly/ReactCommon I think. – then run “update-packge -reinstall” which will uninstall the packages and then install them, hopefully fixing the paths.)
If you have any projects that are used in two different solutions, those solutions should share the same repositoryPath, or you will have a problem with one of the solutions or the other.

Sorry, Packages.Config is v1 technology…so I, and my current team, don’t spend as much time with it as we do with PackageReference.

Packages.Config has a bad design – it requires NuGet to talk to the project system to add references and other elements in the .vcxproj. That is fragile, when people move directories, or hand edit those elements.
ProjectReference has changed that – just drops in inside the .csproj, and then restore builds a obj\project.assets.json file, .g.props and .g.targets file.
During build, a build task harvests assembly info from the assets file, and creates references (etc) on the fly for the compiler. Much less fragile, etc…
(Please ask C++ team to implement packagereference support if this seems like an important improvement for C++ projects)

[kmelmon]

Although there is a workaround documented on the main site, we should fix this using one of the solutions recommended above.