Rider OOTB experience

When opening and building a solution with sdk style projects in Rider it ends up calling e.g

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.exe" "/property:Configuration=Debug" "/property:Platform=Any CPU" "/property:SDKToolingDirectory=C:\Program Files\dotnet" "/t:ObservableProcess" /m "C:\Projects\elastic\abstractions\src\Elasticsearch.Net.Abstractions.sln"

I removed the rider specific logging arguments to be able to run the same command on the command line. This does not attempting to restore a solution.

Rider no longer aggressively restores since the RC

https://blog.jetbrains.com/dotnet/2017/07/14/rider-release-candidate-performance-refactorings-unity/

Not sure if this is something that paket's target file needs to be resilient too or if Rider should do something here.

Visual Studio still calls a restore upon opening the solution so the Open sln file -> Build flow works OOTB there.

cc @enricosada @citizenmatt

Happy to hear your thoughts before diving in too deep!

(PS i'm all for avoiding unneeded calls to dotnet restore https://github.com/dotnet/cli/issues/6524 😄)

Start by reproducing the Rider build command shown in the issue and inspect Paket's target file, which is the only project entry point mentioned. Compare the restore behavior with Visual Studio's open-solution/build flow, then determine whether Paket's targets or Rider must change so SDK-style solutions build correctly without unnecessary restores.