msbuild cannot build new style csproj when targetting net462

[rainersigwald]

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

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.targets(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\ClassLibraryFw462NewProj\ClassLibraryFw462NewProj.csproj]

    0 Warning(s)
    1 Error(s)

Environment data

msbuild /version output:

Microsoft (R) Build Engine version 15.7.179.6572 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
15.7.179.6572

OS info: Win 10 x64 v1803 (OS Build 17134.112)
VS 2017 (15.7.4)

Copied from original issue: dotnet/msbuild#3429

[rainersigwald]

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.

[rainersigwald]

Moving to the sdk repo to see if there's interest in optimizing for the no-PackageReference case.

[dsplaisted]

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.

[livarcocc]

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.

[SidShetye]

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.

[davkean]

Let's just reopen it until we've tracked this down. @rrelyea Is NuGet restore supposed to work for the PackageReference case?

[SidShetye]

@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

[rainersigwald]

@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?

[SidShetye]

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>

[rainersigwald]

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

[Amit-Kumar-Sonkar]

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'.

[rainersigwald]

@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.

[Amit-Kumar-Sonkar]

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..

[fleed]

@Amit-Kumar-Sonkar I’m experiencing a similar issue on Azure DevOps.
How did you fix it in your case?

[fleed]

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

[StingyJack]

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.

• The first task is an MSBuild task that only cleans the solution with an argument of /t:Clean
• The second task is an inline powershell script that does a 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.

[ankeetnet]

I am having same issues on AzureDevOps pipeline after updating my projects to .net core 2.2.