locked
Hosted Agent: NuGet Packager now fails (was working) with VS2017 Hosted Agent RRS feed

  • Question

  • Having had a build process that works with my VS2017 and  the VS2017 hosted agents in VSTS I now find that the NuGet Packager seems to fail with:

         'Newtonsoft.Json' already has a dependency defined for 'Microsoft.CSharp'.

    I have tried different versions in the Nuget Restore of 3.3.0 and 4.0.0 but I think I have to use 4.0.0.

    Anyone have any suggestion on getting this NuGet Packager working?

    Thanks

    db

    ==============================================================================

    Task         : NuGet Packager
    Description  : Creates nupkg outputs from csproj or nuspec files
    Version      : 0.1.72
    Author       : Lawrence Gripper
    Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=627416)
    ==============================================================================
    Preparing task execution handler.
    Executing the powershell script: C:\a\_tasks\NuGetPackager_333b11bd-d341-40d9-afcf-b32d5ce6f24b\0.1.72\NuGetPackager.ps1
    Find-Files -SearchPattern C:\a\1\s\**\blahg.csproj -RootFolder C:\a\1\s
     
    C:\LR\MMS\Services\mms\TaskAgentProvisioner\Tools\agents\2.115.0\externals\nuget\NuGet.exe pack "C:\a\1\s\blahg.csproj" -OutputDirectory "C:\a\1\s" -Properties Configuration=release -version 2017.4.24.4
    MSBuild auto-detection: using msbuild version '4.0' from 'C:\Windows\Microsoft.NET\Framework\v4.0.30319'.
    Attempting to build package from 'blahg.csproj'.
    Packing files from 'C:\a\1\s\***\bin\Release'.
    ##[error]'Newtonsoft.Json' already has a dependency defined for 'Microsoft.CSharp'.
    ##[error]System.Exception: Unexpected exit code 1 returned from tool NuGet.exe
       at Microsoft.TeamFoundation.DistributedTask.Task.Internal.InvokeToolCmdlet.ProcessRecord()
       at System.Management.Automation.CommandProcessor.ProcessRecord()
    ##[error]PowerShell script completed with 1 errors.

    Monday, April 24, 2017 11:08 AM

Answers

  • Just to note that I had a similar issue and solved it by making the Nuget restore LESS specific in Azure.

    Per this image the three lines specified in this segment were *highly specific* to the project I was building.

    I deleted "path to nuget config" completely.

    I changed <path to>\packages.config to **\*.sln and the build started working again.

    I suspect that there was a change in the background of azure which altered the previous configuration from being accepted to  failing.

    Wednesday, May 17, 2017 2:41 PM

All replies

  • Downgraded Newtonsoft.Json from version 10.0.2 to 9.01 in the solution and the VSTS build now works with the NuGet Packager. Seems to be an issue with the latest version of Newtonsoft.Json and the NuGet Packager.

    This might have something to do with it...

    10.0.2 - Microsoft.CSharp (>= 4.3.0)

    9.0.1 - Microsoft.CSharp (>= 4.0.1)

    Monday, April 24, 2017 5:59 PM
  • Hey Db,

    We ran into this issue today after we upgraded a package that in turn required Newtonsoft.Json 10.0.2. I saw a few different stack overflow posts of various ages, but this one in particular was helpful:

    https://stackoverflow.com/questions/25725545/nuget-x-already-has-a-dependency-defined-for-y

    I was able to pack from the same csproj on my local machine using nuget v3.5. I added a task to my build definition to verify the version of nuget that the packager task uses. Although we had a nuget restore build task that used nuget 4.0.0, the packager task still utilized nuget 3.3.

    I first tried to update the nuget that the packager uses, but ran into access denied errors.

    Ultimately we were able to get our packager to work by adding the path to the nuget.exe that the Nuget Restore build task uses to the advanced options of the nuget packager task. On our hosted agent, this path was

    d:\a\_tasks\NuGetInstaller_333b11bd-d341-40d9-afcf-b32d5ce6f23b\0.2.31\node_modules\nuget-task-common\NuGet\4.0.0\NuGet.exe

    However, on hosted 2017 agent the path was:

    C:\a\_tasks\NuGetInstaller_333b11bd-d341-40d9-afcf-b32d5ce6f23b\0.2.31\node_modules\nuget-task-common\NuGet\4.0.0\NuGet.exe

    I am not what the variance on the "NuGetInstaller_333b11bd-d341-40d9-afcf-b32d5ce6f23b" part of the path will be and am still looking for a better workaround.

    Hope this helps!

    Edit:

    We were able to simplify our workaround a bit by including the nuget command line package in our project and providing a path to that for the nuget packager task.

    https://www.nuget.org/packages/NuGet.CommandLine/

    The new path used in the nuget packager is now:

    $(System.DefaultWorkingDirectory)\{{soution_name}}\packages\NuGet.CommandLine.3.5.0\tools\Nuget.exe

    This should be more stable than using the nuget restore's nuget.exe.


    Wednesday, May 3, 2017 9:14 PM
  • Just to note that I had a similar issue and solved it by making the Nuget restore LESS specific in Azure.

    Per this image the three lines specified in this segment were *highly specific* to the project I was building.

    I deleted "path to nuget config" completely.

    I changed <path to>\packages.config to **\*.sln and the build started working again.

    I suspect that there was a change in the background of azure which altered the previous configuration from being accepted to  failing.

    Wednesday, May 17, 2017 2:41 PM
  • @AlexC04

    Thanks for sharing the fix. 

    Sunday, May 21, 2017 1:48 PM
  • Just to note that I had a similar issue and solved it by making the Nuget restore LESS specific in Azure.

    Per this image the three lines specified in this segment were *highly specific* to the project I was building.

    I deleted "path to nuget config" completely.

    I changed <path to>\packages.config to **\*.sln and the build started working again.

    I suspect that there was a change in the background of azure which altered the previous configuration from being accepted to  failing.

    For me, the fix was, further down under "Advanced"... I changed "Nuget Version" from 3.3 to 4.0.

    I'm not sure if Nuget 3.3 and Msbuild 4.0 are incompatible? But, like mine, it's using Msbuild 4.0 and Nuget 3.3... Going 4.0 and 4.0 got it working for me.
    Monday, June 12, 2017 1:43 AM