Po uruchomieniu polecenia pakietu NuGet pojawia się błąd: "AutoMapper" ma już zależność zdefiniowaną dla 'NETStandard.Library'

Mam problem z pakowaniem własnego pakietu nuget, który zawiera AutoMapper 5.0.2. Powoduje to tylko błąd w serwerach Build Visual Studio Team Services (VSTeam).Po uruchomieniu polecenia pakietu NuGet pojawia się błąd: "AutoMapper" ma już zależność zdefiniowaną dla 'NETStandard.Library'

Mój projekt jest przy użyciu .NET 4.6.1

Wszelkie pomysły jak to naprawić?

Tutaj jest błąd:

2016-07-08T23:46:44.5801667Z C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\1.102.0\agent\worker\tools\NuGet.exe pack "C:\a\1\s\Project.csproj" -OutputDirectory "C:\a\1\s\Project\bin\release" -Properties Configuration=release -IncludeReferencedProjects 
2016-07-08T23:46:45.0458195Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'. 
2016-07-08T23:46:45.0468395Z Attempting to build package from 'Project.csproj'. 
2016-07-08T23:46:45.1942694Z Packing files from 'C:\a\1\s\Project\bin\Release'. 
2016-07-08T23:46:45.3942642Z ##[error]**'AutoMapper' already has a dependency defined for 'NETStandard.Library'.** 
2016-07-08T23:46:45.4142626Z ##[error]System.Exception: Unexpected exit code 1 returned from tool NuGet.exe 
2016-07-08T23:46:45.4152639Z ##[error] at Microsoft.TeamFoundation.DistributedTask.Task.Internal.PowerShell.InvokeToolCmdlet.ProcessRecord() 
2016-07-08T23:46:45.4152639Z ##[error] at System.Management.Automation.CommandProcessor.ProcessRecord()

ja również otwarty problem na GitHub: https://github.com/AutoMapper/AutoMapper/issues/1499

Źródło

2016-07-09 Phobis

Musisz zaktualizować wersję NuGet, której używasz, jak opisano tutaj - http://stackoverflow.com/questions/38247961/nuget-package-manager-automapper-already-has-a-dependency-defined-for- micros –

Pomyślałem, że tak było. Po prostu nie wiem jak to zrobić na Hosted Build Server dla Visual Studio Online. – Phobis

Wygląda na to, że Hosted Build Server działa z NuGet 3.3.0.212 – Phobis

udało mi się naprawić/Obejście problemu poprzez umieszczenie skryptu PowerShell w celu pobrania najnowszej Nuget. Następnie wskazałem wszystkie zadania NuGet na ten nowy plik nuget.exe. Zalety: kompilacje znów działają, wady: każda kompilacja ponownie pobiera NuGet, powodując niepotrzebne obciążenie NuGet.org.

Oto moja PowerShell:

$sourceNugetExe = "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe" 
$targetNugetExe = "$(build.sourcesdirectory)/nuget.exe" 
Invoke-WebRequest $sourceNugetExe -OutFile $targetNugetExe 
Set-Alias nuget $targetNugetExe -Scope Global -Verbose 
nuget

Źródło

2016-07-09 16:05:37 Phobis

Scenariusz nie działa dla mnie (mam. Termin "Build.SourcesDirectory" nie jest rozpoznawany jako nazwa polecenia cmdlet, funkcji, pliku skryptu lub działającego programu), ale to, co działało, było po prostu pobieraniem https://dist.nuget.org/win-x86-commandline/latest/nuget.exe plik, zastępując plik w moim projekcie, a następnie po prostu wszędzie w VSO ustawienie ścieżki NuGet do "$ (Build.SourcesDirectory) \. nuget \ nuget.exe " –

Zamiast pobierać' nuget.exe' na każdej kompilacji, umieściłem go w kontrolce źródłowej i wskazałem krok kompilacji, aby go użyć. Ale ten sam problem - nugetowa wersja to łamanie rzeczy. – trailmax

@VictorF: Dla samodzielnego skryptu Powershell można użyć '$ PSScriptRoot' (tj.' $ TargetNugetExe = "$ PSScriptRoot/nuget.exe" ') –

Musisz zainstalować nową wersję Nuget dla wizualnej wersji studyjnej.

Pobierz stąd Nuget gallery

Źródło

2016-07-28 22:42:35 Alienalone

Oczywiście coś głupiego, jak to, byłoby naprawą. lol Dziękuję, to zadziałało dla mnie. – Nicholas

Jeżeli ktoś za pomocą zespołu Miasto trzeba także używać/zainstalować nowszą wersję Nuget.

Źródło

2016-09-15 10:13:30 darmis

Po uruchomieniu polecenia pakietu NuGet pojawia się błąd: "AutoMapper" ma już zależność zdefiniowaną dla 'NETStandard.Library'

Odpowiedz

Powiązane problemy