Tjyylli

(Using nuget.exe version 4.9.2 and Visual Studio 2017 Community Edition)

I'm stumped on a nuget.exe restore issue. I'm using Jenkins to build pushed sources. I had a solution with a single project in it, Roadmap, and that built fine, including using

nuget.exe restore "test.sln"

to restore the nuget packages. My Jenkins builds always start with an empty directory.

Now I have a second project. It uses several of the same nuget packages. But when Jenkins runs the same nuget.exe command on the .sln file, I get this error:

C:Jenkinsworkspacetest>nuget restore "test.sln"

MSBuild auto-detection: using msbuild version '12.0' from 'C:Program Files (x86

)MSBuild12.0binamd64'.

All packages listed in packages.config are already installed.

Invalid restore input. Missing required property 'OutputPath' for project type '

PackageReference'. Input files: C:JenkinsworkspacetestRoadtripRoadtrip.csproj.

I do see the OutputPath set in both of the .csproj files in my solution. But the error message isn't completely misleading. Roadmap.csproj, the original, has lines like these for the nuget packages:

  <ItemGroup>

     <Reference Include="CommonServiceLocator, Version=2.0.4.0, Culture=neutral, PublicKeyToken=489b6accfaf20ef0, processorArchitecture=MSIL">

       <HintPath>..packagesCommonServiceLocator.2.0.4libnet45CommonServiceLocator.dll</HintPath>

     </Reference>

  ...

In Roadtrip.csproj, the new one, the equivalent section holds

  <ItemGroup>

     <PackageReference Include="CommonServiceLocator">

        <Version>2.0.4</Version>

     </PackageReference>

  ...

This is the case whether I use the solution nuget manager to add packages to one or both projects, or use each project nuget manager to add their packages.

From what I've seen online, Roadtrip that looks fine. I'm not sure why it would differ from Roadmap. From within Visual Studio, the references are found and both apps run, with the correct DLLs sitting in the debug and release directories. Additionally, when I run the nuget.exe line on my laptop, the packages are retrieved.

It's only when I run it on the remote Jenkins server that it fails. I've tried looking for the differences in the configurations, but they're not jumping out, what I can find that's relevant matches on both. I'm hoping there's someone knowledgeable here who knows the specifics of why I'd see that error message.

I appreciate any assistance.

Update: I was going to add this in the morning, and Scott mentioned doing so as well... I'm picking on Jenkins, but it's really the machine Jenkins is running on. I can open a cmd window on my laptop (not the MSVC cmd window), wipe out the solution packages directory and all obj/bin subdirectories, and nuget.exe restore test.sln completes successfully. Doing the same on the machine with Jenkins fails as shown above... and used to work before I added the second project. The versions of nuget and Visual Studio are the same on both, the environment variables in the cmd windows are the same on both.

My working answer is that the Visual Studio / nuget.exe versions I'm using do not support PackageReference in .csproj files. I've read that it should, but couldn't get past this issue. Once I modified my Roadmap project to use packages.config and modified my .csproj file to match the Roadmap file, the nuget restore command worked as expected.

I had the same issue while restoring locally, and it worked as expected. But when I tried and started my job on the Jenkins agent, I got the same issue with the nuget restore.

nuget restore pathToProjectMyProject.csproj



Invalid restore input. Missing required property 'OutputPath' for project type 'PackageReference'. Input files: MyProject.csproj

Where on my Jenkins Agent machine I had the same Nuget version as the Nuget version on my machine. And the same MSBuild as my MSBuild on my machine.

But the nuget restore command started another MSBuild version on my agent.
Specifying the MSBuildPath to the MSBuild version 15, helped in my case.

nuget restore pathToProjectMyProject.csproj -MSBuildPath "pathToMSBuildMSBuild15.0Bin"

Or you might try using -MSBuildVersion.

As far as I understand the PackageReference change works best with MSBuild version 15. Since it came with Visual Studio 2017, and at the same time MSBuild 15.