I agree that the invocation of package restore prior to MSBuild is the solution but I strongly believe it should be the responsibility of NuGet to raise an appropriate error when this has not been done. Otherwise the burden is shifted to either package producers to provide these errors (as currently implemented in StyleCop.MSBuild) or to package consumers (VS user, build script writer, build system provider) to remember to either restore packages before the first build or run a second build (messy).
Whilst the VS/build system cases can probably be taken care of by the tooling as suggested above, I should also be able to git clone and run build.bat/rake/etc. and rely on a complete build taking place, and if not, I should be informed (and then presumably I'd question the build script author as to why they didn't add package restore as a first step!).
I propose that in addition to the Import elements for .props and .targets, NuGet injects a further target into PrepareForBuildDependsOn (see StyleCop.MSBuild example above) which raises an error if a packaged .targets or .props has not been imported. If the core team don't have the bandwidth to add this, I'd be happy to send a PR once the branch has made it onto master.
I had plenty of enquiries about StyleCop.MSBuild and package restore before I added the error messages, after which the enquiries largely disappeared. I guess that some people were also running automated builds on fresh checkouts without even realising that their StyleCop targets were not being imported and invoked. I guess they'd find out eventually, but it just puts speed bumps in the dev cycle.
Ultimately, the absolute fix-it-for-all-no-further-questions solution to all this may well be to introduce NuGet package restore as an MSBuild (and XBuild) feature in it's own right. I.e. NuGet package restore would not be 'just another target' but it's something that is outside that process, which takes place before the import of targets, etc. but I guess this is probably not feasible to get done or perhaps may not be desirable from an MSBuild architecture POV.
Whilst the VS/build system cases can probably be taken care of by the tooling as suggested above, I should also be able to git clone and run build.bat/rake/etc. and rely on a complete build taking place, and if not, I should be informed (and then presumably I'd question the build script author as to why they didn't add package restore as a first step!).
I propose that in addition to the Import elements for .props and .targets, NuGet injects a further target into PrepareForBuildDependsOn (see StyleCop.MSBuild example above) which raises an error if a packaged .targets or .props has not been imported. If the core team don't have the bandwidth to add this, I'd be happy to send a PR once the branch has made it onto master.
I had plenty of enquiries about StyleCop.MSBuild and package restore before I added the error messages, after which the enquiries largely disappeared. I guess that some people were also running automated builds on fresh checkouts without even realising that their StyleCop targets were not being imported and invoked. I guess they'd find out eventually, but it just puts speed bumps in the dev cycle.
Ultimately, the absolute fix-it-for-all-no-further-questions solution to all this may well be to introduce NuGet package restore as an MSBuild (and XBuild) feature in it's own right. I.e. NuGet package restore would not be 'just another target' but it's something that is outside that process, which takes place before the import of targets, etc. but I guess this is probably not feasible to get done or perhaps may not be desirable from an MSBuild architecture POV.