Open rainersigwald opened 6 years ago
Thanks for the detailed report!
All projects that use Microsoft.NET.Sdk
require NuGet restore before build. You can accomplish this with a small change to your build script:
diff --git a/DemoProblem.ps1 b/DemoProblem.ps1
index ae1b278..fbcee89 100644
--- a/DemoProblem.ps1
+++ b/DemoProblem.ps1
@@ -37,7 +37,7 @@ gci . -Recurse -Include bin,obj | % { ri -Recurse -Force $_.FullName }
# And now it barfs :/
# building in VS2017 (15.7.4) works just fine though
$cwd=$PSScriptRoot # just point to current directory / soln dir
-msbuild .\ClassLibraryFw462NewProj\ClassLibraryFw462NewProj.csproj /p:SolutionDir=$cwd /p:Configuration=Debug /m /t:build
+msbuild .\ClassLibraryFw462NewProj\ClassLibraryFw462NewProj.csproj /p:SolutionDir=$cwd /p:Configuration=Debug /m /t:build /restore
# dump our msbuild version too
msbuild /version
\ No newline at end of file
The VS build does NuGet restore independently and silently, which is why it works transparently.
Moving to the sdk repo to see if there's interest in optimizing for the no-PackageReference
case.
I think it is OK that restore is required. Even if your project doesn't have any PackageReferences, you could have project references to projects that have PackageReferences, which means restore would be necessary for your build. So determining that you don't need restore would require walking the project references, at which point you might as well be restoring anyway.
Agreed. This seems like too small of a case to warrant adding this complexity to the system. Going to close the issue for now. If there are strong arguments to doing this, please, make your case.
A simple /restore
to msbuild huh? We couldn't have figured that our because in our actual CI environment we already had something like
& $solutionDir\.nuget\nuget.exe restore $solutionDir\
to handle the nuget restore phase.
Why does nuget restore need to be done only with the /restore
and not with a nuget restore
? We lost quite a bit of time over this
EDIT: Our actual CI failure had real nuget references but during simplification to post here it was observed that having no actual nuget reference still caused this failure.
Let's just reopen it until we've tracked this down. @rrelyea Is NuGet restore
supposed to work for the PackageReference case?
@davkean speaking of repro, I've updated https://github.com/SidShetye/msbuild-newcsproj-issue to reproduce this issue even after issuing the equivalent of nuget.exe restore mysolution.sln
@SidShetye I tried running your repro script at https://github.com/SidShetye/msbuild-newcsproj-issue/commit/76af77794933aee8f073d5781b7364d57ce3e595; it restores and builds without error on my machine. nuget.exe
from my PATH is version 4.6.2.5055
. Do you perhaps have an older one?
I actually downloaded the latest nuget.exe and checked it in to minimize variability over nuget.exe. Still, it's the same version you have and the same from nuget.org
PS C:\temp\new-old-proj-mix-soln> .\nuget.exe
NuGet Version: 4.6.2.5055
here is what I see
PS C:\temp\new-old-proj-mix-soln> .\DemoProblem.ps1
Visual Studio environment already setup
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin\amd64'.
Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 6/22/2018 2:30:49 PM.
1>Project "C:\temp\new-old-proj-mix-soln\ClassLibraryFw462NewProj\ClassLibraryFw462NewProj.csproj" on node 1 (buil
d target(s)).
1>PrepareForBuild:
Creating directory "bin\Debug\net462\".
Creating directory "obj\Debug\net462\".
1>C:\Program Files\dotnet\sdk\2.1.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets
(198,5): error : Assets file 'C:\temp\new-old-proj-mix-soln\ClassLibraryFw462NewProj\obj\project.assets.json' no
t found. Run a NuGet package restore to generate this file. [C:\temp\new-old-proj-mix-soln\ClassLibraryFw462NewP
roj\ClassLibraryFw462NewProj.csproj]
1>Done Building Project "C:\temp\new-old-proj-mix-soln\ClassLibraryFw462NewProj\ClassLibraryFw462NewProj.csproj" (
build target(s)) -- FAILED.
Build FAILED.
"C:\temp\new-old-proj-mix-soln\ClassLibraryFw462NewProj\ClassLibraryFw462NewProj.csproj" (build target) (1) ->
(ResolvePackageAssets target) ->
C:\Program Files\dotnet\sdk\2.1.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targe
ts(198,5): error : Assets file 'C:\temp\new-old-proj-mix-soln\ClassLibraryFw462NewProj\obj\project.assets.json'
not found. Run a NuGet package restore to generate this file. [C:\temp\new-old-proj-mix-soln\ClassLibraryFw462Ne
wProj\ClassLibraryFw462NewProj.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.33
Microsoft (R) Build Engine version 15.7.179.6572 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
15.7.179.6572
PS C:\temp\new-old-proj-mix-soln>
git repo state
PS C:\temp\new-old-proj-mix-soln> git log -n 1
commit 76af77794933aee8f073d5781b7364d57ce3e595 (HEAD -> master, origin/master)
Author: Sid Shetye <sid@crypteron.com>
Date: Thu Jun 21 20:21:37 2018 -0700
even adding a dummy nuget package doesn't help
PS C:\temp\new-old-proj-mix-soln> git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
PS C:\temp\new-old-proj-mix-soln>
Aha!
MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin\amd64'. Nothing to do. None of the projects in this solution specify any packages for NuGet to restore.
MSBuild 14 didn't support PackageReferences, so this is probably the proximate cause of the problem.
It sounds like NuGet.exe
's environment detection isn't catching Visual Studio 2017 in your environment. @rrelyea can you route for that problem?
@SidShetye I think this might work around the autodetection:
nuget.exe restore -MSBuildPath $(Split-Path -Path (get-command msbuild.exe).source -Parent) .\new-old-proj-mix-soln.sln
what are the way to resolve below Issues while Build is going on from VSTS ?? even after ran dotnet build, dotnet restore not able to fix . ??
C:\Program Files\dotnet\sdk\2.1.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(198,5): Error : Assets file 'D:\a\3\s\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
Process 'msbuild.exe' exited with code '1'.
@Amit-Kumar-Sonkar That looks like a separate issue. Can you reproduce it in isolation?
D:\a\3\s\obj\project.assets.json
makes me think you might have an incorrectly-redirected intermediate output path in at least one of your projects.
well Finally we were able to resolve the TFS BUILD Issue 🥇 from Command Line and TFS
FROM COMMAND LINE : )
FROM TFS : )
Now we were trying to DEPLOY Asp.Net Core Website after successful BUILD AND RELEASE..
stucked somewhere in Deployment let see..
@Amit-Kumar-Sonkar I’m experiencing a similar issue on Azure DevOps. How did you fix it in your case?
I could finally fix the issue on the server. The error that I was getting in Azure DevOps Pipelines build:
C:\Program Files\dotnet\sdk\2.2.100-preview3-009430\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5): error NETSDK1064: Package Common.FeatureToggleManagement.Core, version 0.1.0-web-update-client-5198.1-13160 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
I'm using packages stored stored in an Azure DevOps Artifacts feed.
Solution:
I pinned the specific version 2.1.500 of the .net Core SDK using the command dotnet new globaljson --sdk-version 2.1.500
.
Previously, the build server was using the SDK version 2.2.100-preview3-009430. This version is also installed on my computer, but I noticed that the build succeeds if run from the command line (also on the build agent!), but not if run within Azure DevOps.
I hope that this helps preventing issues from the final version for the SDK 2.2.
/cc @rainersigwald
This happens with TFS 2015 vNext builds as well when using the MSBuild task (using a custom location pointing to msbuild v15).
To fix it, I had to split the one MSBuild task into two, and add a powershell task in between them.
/t:Clean
Push-Location
to the solution folder and then calls dotnet restore
The third task is an MSBuild task that does not clean, but does build the solution and has an option enabled for Nuget Restore.
I think this is a problem with that TFS 2015 msbuild task and nuget. When enabling that package restore option on the msbuild task, the logs show that nuget is using msbuild v14.0 and that is probably what doesnt understand the obj\project.assets.json
file. Or it could be the nuget.exe that the build tasks are using. Its v3.2.1. I didn't see that it may not be using the one in the path until right now. =/
An excerpt to show what I mean with the versions.
2018-12-10T21:24:46.0010754Z ##[debug]Entering Invoke-BuildTools.
2018-12-10T21:24:46.0166759Z ##[debug] NuGetRestore: 'True'
2018-12-10T21:24:46.0166759Z ##[debug] SolutionFiles: 'D:\agent006\_work\43\s\Trunk\Master.sln'
2018-12-10T21:24:46.0166759Z ##[debug] MSBuildLocation: 'c:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe'
2018-12-10T21:24:46.0166759Z ##[debug] MSBuildArguments: '/tv:15.0 /p:platform="any cpu" /p:configuration="release"'
2018-12-10T21:24:46.0322764Z ##[debug] Clean: 'False'
2018-12-10T21:24:46.0322764Z ##[debug] NoTimelineLogger: 'False'
2018-12-10T21:24:46.0478769Z ##[debug]Entering Invoke-NuGetRestore.
2018-12-10T21:24:46.0478769Z ##[debug] File: 'D:\agent006\_work\43\s\Trunk\Master.sln'
2018-12-10T21:24:46.0478769Z ##[debug]Env:AGENT_HOMEDIRECTORY: 'D:\agent006'
2018-12-10T21:24:46.0790779Z ##[debug]Asserting leaf path exists: 'D:\agent006\Agent\Worker\Tools\NuGet.exe'
2018-12-10T21:24:46.0946784Z ##[debug]Entering Invoke-VstsTool.
2018-12-10T21:24:46.0946784Z ##[debug] FileName: 'D:\agent006\Agent\Worker\Tools\NuGet.exe'
2018-12-10T21:24:46.1102789Z ##[debug] Arguments: 'restore "D:\agent006\_work\43\s\Trunk\Master.sln" -NonInteractive'
2018-12-10T21:24:46.1102789Z ##[debug] WorkingDirectory: 'D:\agent006\_work\43\s\Trunk'
2018-12-10T21:24:46.1102789Z ##[debug] RequireExitCodeZero: 'True'
2018-12-10T21:24:50.7748284Z MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
2018-12-10T21:24:51.3208459Z Restoring NuGet package Something.1.1.0.6.
I am having same issues on AzureDevOps pipeline after updating my projects to .net core 2.2.
From @SidShetye on June 19, 2018 23:48
Steps to reproduce
Problem demo'd at the repo at https://github.com/SidShetye/msbuild-newcsproj-issue
Expected behavior
build the project like VS2017 gui does on the same machine
Actual behavior
build fails even though there are no nuget dependencies
Environment data
msbuild /version
output:OS info: Win 10 x64 v1803 (OS Build 17134.112) VS 2017 (15.7.4)
Copied from original issue: Microsoft/msbuild#3429