Home: <PackageReference> does not work when building in Visual Studio 2017 command line mode

[hrumhurum]

Description

<PackageReference> items in MSBuild projects are ignored when solution is built via Visual Studio command line. This prohibits to use NuGet package references in build server scenario due to the fact that resulting projects cannot be built.

NuGet product used: Visual Studio
VS version: Visual Studio 2017 Professional Version 15.1 (26403.7)
NuGet Package Manager version: 4.1.0
OS version: Windows 10 Version 1703 (15063.138)
Worked before?: No

Reproduction Steps

1. Unpack the enclosed sample project

2. Please ensure that path to devenv.com is correct in Build.bat file

3. Run Build.bat from the command line

Expected Results

Microsoft Visual Studio 2017 Version 15.0.26403.7.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: SampleApp, Configuration: Release Any CPU ------
1> SampleApp -> C:\Temp\SampleApp\SampleApp\bin\Release\SampleApp.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Actual Results

Microsoft Visual Studio 2017 Version 15.0.26403.7.
Copyright (C) Microsoft Corp. All rights reserved.
1>------ Build started: Project: SampleApp, Configuration: Release Any CPU ------
1>C:\Temp\SampleApp\SampleApp\Program.cs(1,7,1,17): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Sample Project

Please find the enclosed file SampleApp.zip.

[nkolev92]

VS - Build does not explicitly do a NuGet restore.
Consider using MSBuild directly for these scenarios.
https://docs.microsoft.com/en-us/nuget/schema/msbuild-targets

[hrumhurum]

@nkolev92, MSBuild restore does the job. I performed the following command before building the solution and got a successful build:

MSBuild.exe SampleApp.csproj /t:restore

Thank you.

That's a good solution but I have to write a script that walks through the .sln file, finds the projects with <PackageReference> items and does MSBuild restore for them. While this is a doable approach, it would be much handier if Visual Studio provided that experience out of the box. Yes, it already works in Visual Studio UI, but it does not work in Visual Studio command line mode. This introduces an unpleasant discrepancy pushing a lot of people to unneeded hassle and frustrations.

Is there some consideration that stops you from implementing automatic package restore in headless scenarios?

[nkolev92]

Restore can be performed at solution level, you don't need to walk the project graph.

The recommended approach here would be to use NuGet.exe/MSBuild for restore and then MSBuild for building the solution/project.

Any particular reason why you favor using devenv.exe vs MSBuild for your scenarios?

[hrumhurum]

Restore can be performed at solution level, you don't need to walk the project graph. The recommended approach here would be to use NuGet.exe/MSBuild for restore

Trying with nuget.exe which is marked as the latest one here:

C:\Temp\SampleApp>nuget.exe restore SampleApp.sln
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.

Trying with MSBuild:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\MSBuild.exe" SampleApp.sln /t:restore
  Restoring packages for C:\Temp\SampleApp\SampleApp\SampleApp.csproj...
  Committing restore...
  Restore completed in 267,21 ms for C:\Temp\SampleApp\SampleApp\SampleApp.csproj.

Yep, MSBuild solution restore works for <PackageReference> items. Thank you!

Any particular reason why you favor using devenv.exe vs MSBuild for your scenarios?

The solutions we build often rely on things like Wix Toolset, VS Modeling SDK and T4 which are notoriously don't work as expected when the build is performed by MSBuild.exe. That's why we use Visual Studio command line for builds: it just has the least amount of discrepancies between UI and headless modes.

[nkolev92]

The NuGet.exe there is 3.5.0.
NuGet.exe 3.5.0 does not support package reference.
The recommended latest thing is a little bit confusing, apologies for that.
Please try go to https://dist.nuget.org/index.html and download 4.1.0 or 4.2.0

Currently there are no immediate plans to allow restore calls to happen from VS command line.

Give your use case we would recommend using NuGet.exe for your restore (MSBuild works the same for Package Reference/ project.json scenarios, but it ignores package.config projects), and then triggering a build like you were doing before.

[hrumhurum]

Checked out NuGet.exe 4.x per your suggestion and it works with <PackageReference> items as advertised.

Give your use case we would recommend using NuGet.exe for your restore (MSBuild works the same for Package Reference/ project.json scenarios, but it ignores package.config projects), and then triggering a build like you were doing before.

Doing exactly that. Thank you. The issue is solved.

Currently there are no immediate plans to allow restore calls to happen from VS command line.

That's unfortunate but understandable. I know, this is a little thing but those tiny things tend to form a more important metrics: the product experience. Would love to see the out of the box support for NuGet restore in Visual Studio command line mode.

[traderhut]

Currently there are no immediate plans to allow restore calls to happen from VS command line.

I'm confused, if the command line build doesn't work like the UI, isn't this an All hands on deck, Urgent FIX THIS NOW!!!, Production support issue?

How the crud are we going to get a continuous build system to work (I've been fighting with this most of the day, nuget restore doesn't work, msbuild /t:restore doesn't work, msbuild /t:build didn't work, dotnet restore didn't work, I'm running 4.3 of nuget, so it isn't a old version issue... I need to get the project to build under Team City, and I'm currently guessing that we need to rework the project somehow to make it build-able by the command line... What a freaking mess. Microsoft has just gone down hill over the last half decade...

This just seems like a 'shakes head and looks for a new development platform' kind of problem... So sad, MS used to be such a solid customer focused company...

[hrumhurum]

Hello @traderhut ,

There is an easy workaround. Just use MSBuild.exe to build your solution with the parameters like that:

"C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\msbuild.exe" YourSolution.sln /t:Clean,restore,Build /p:configuration="Release" /p:platform="Any CPU" /p:VisualStudioVersion="16.0" /nologo /nr:false /m

MSBuild 16.0 came a loooong way since the original issue was initially posted. Currently it is nearly on par with Visual Studio 2019. The issues with T4 models and alike are long gone, so it may be a very good substitute to a full build with Visual Studio.

If you do not want to use MSBuild, you can always use nuget.exe before building a solution with Visual Studio:

nuget.exe restore YourSolution.sln

The problem is solved.

Yes, having an out-of-the-box experience is better, but workarounds are solid and decent. It may be a more painful experience with some older versions of Visual Studio though.

Hope this helps.

[nkolev92]

Small improvement.

/t:Clean,Restore,Build is not a good idea due to an MSBuild thing about evaluation.

See: https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets#restoring-and-building-with-one-msbuild-command

Running /t:Build /restore should be enough.

Note that the recommendation to use MSBuild instead of devenv.exe has been there since at least Visual Studio 2015.

https://docs.microsoft.com/en-us/visualstudio/ide/reference/devenv-command-line-switches?view=vs-2015

[aw2003]

If you do not want to use MSBuild, you can always use nuget.exe before building a solution with Visual Studio:

nuget.exe restore YourSolution.sln

The problem is solved.

This doesn't work (devenv still complains about references it can't find) - all this does is restore the package you require into your build environment, it doesn't solve the actual problem building the application. I'm also trying to get a solution with a csproj in it to build under teamcity using devenv.com (VS2017), and PackageReference doesn't work with exactly the nuget command line you're suggesting used. I'm using Nuget 5.4.0.6315.

I'm also infuriated that the accepted answer appears to be "Use MSBuild". The application is developed and debugged in the VS IDE. If I build and test using TeamCity, I don't have total confidence this is the same binary UNLESS IT'S BUILT USING DEVENV, Why bother with CI at all if you can't actually use the same environment you've developed and tested your application in??

This is really poor, and apparently has been going on for years. Come on - fix this. If the IDE can do it, devenv.com should be able to!!!