52
votes

We're using Git and we have a solution which is targeting the full net framework. A couple of days ago, I've started migrating the solution to .net core. Unfortunately, something comes up which made me go back to the master branch (which has the code for the full .NET framework). Whenever I try to build the app, I get the following error:

1>D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets(186,5): error : Your project is not referencing the ".NETFramework,Version=v4.7.2" framework. Add a reference to ".NETFramework,Version=v4.7.2" in the "frameworks" section of your project.json, and then re-run NuGet restore.

I've tried cleaning up the nuget packages, running a git reset, but nothing seems to help. Any idea on what's going on?

8
The lates long-term support version of .NET Core (2.1) doesn't use project.json, it uses .csproj with a new format. Which .NET Core version did you target? What does the csproj file look like?Panagiotis Kanavos
I know...in fact, that's what I have in the netcore branch...Luis Abreu

8 Answers

13
votes

Fix this by automatically deleting project.assets.json for non-Core project(s) via a custom Visual Studio Build Event.

Update (6/13/2020) It turned out deleting project.assets.json caused squiggy lines to show because Intellisense needed the references from the file. So an even better fix is to use a Pre-build event to only delete the file if the project is not .Net Core.

This is identified by $(TargetFramework) ---> "netcoreapp3.1" on my computer. Your installed framework might show a different identifier so update the script accordingly (see the text in your build Output window generated by the ECHO on line 2). Note: This can be an empty string on certain .Net Framework version(s) which shouldn't be an issue. We're also only comparing the first 7 characters to ignore the version to avoid having to update the script if/when the version changes.

SET _tgt=$(TargetFramework)
ECHO %_tgt%
IF NOT "%_tgt:~0,7%" == "netcore" (
    cd $(ProjectDir)\obj
    DEL project.assets.json
)

enter image description here

==== Update (6/13/2020) ends here. Original answer kept below to provide context. ====

We narrowed down the problem to a single file: project.assets.json in the {Your project}/obj folder. It's a file created by a .Net Core project but it does not get deleted by Visual Studio after switching to a .Net Framework project causing the issue mentioned by OP.

The solution is to remove this file but, rather than having to delete it manually every time we need to switch projects, we created a post-build event in Visual Studio to remove it after each successful Core build (your Core projects won't build if you run the script before the build, obviously). You can customize the script to delete whatever files/folders you deem to be problematic but our issue was limited to that single file.

cd $(ProjectDir)\obj
del project.assets.json

Note: You will need to delete the offending artifact(s) manually once if it already exists since the post-build event will only run after a successful build.

enter image description here

140
votes

I had a similiar issue when upgrading some projects from 4.6.2 to 4.7.2 - this happened for both our ASP.Net Core solution targetting full framework, and our WPF solution.

Initially it seemed to be random projects that had this error, other projects with near exact same csproj were building fine and others were failing. The 're-run NuGet restore' in the message sent me down the wrong path aswell (some of these projects didn't even have NuGet references...)

The issue appears to stem from the projects obj folder containing a project.assets.json file, I'm not sure when this was generated - likely relics from the past, and cleaning the project does not remove this. The file points to the previous framework, in my case 4.6.2 - Manually deleting the bin/obj folders for each project that wouldn't build & then rebuilding resolved this error for me. This would also explain why when I cloned the repo for my sanity, it also built fine.

10
votes
  1. Call git clean -dfX- Remove untracked files from the working tree
  2. Rebuild solution
4
votes

MaxJ's answer came close for my situation, but I had to delete bin and obj folders for every project in the solution when doing so in the single project that wouldn't build didn't fix the build.

For convenience, the PS I used for the above which should only be run at the root of a folder that you don't mind deleting these folders in (in Front End node modules might be a bad place for example):

gci -Include bin,obj -Recurse | Remove-Item -Force -Recurse
2
votes

Sounds like you might have some libraries that aren't Core compatible. If Nuget is expecting/requiring 4.7.2, then something is likely still targeting it, either in your project or a library I'd venture. Would also explain why cleaning up the Nuget packages and restoring them doesn't fix the issue if the package that you're restoring still targets 4.7.2.

Related note, are you sure that you're using the latest project structure? I noticed that your error message includes project.json, which was deprecated in favor of the new csproj format; more info is here if it's relevant. I'm not aware of a situation where you'd get an error message about project.json and the solution didn't have a project.json.

2
votes

I deleted the obj and bin folders and rebuilt the Project. Visual Studio automatically created the "dll" files to be used again. It worked for me.

1
votes

I found that just doing a search for project.assets.json over my repo using Agent Ransack and then deleting those files, rather than entire bin & obj folders, did the trick :)

1
votes

I had same error and bin/obj cleanup did not help. After a lengthy investigation I have found that I have mistakenly overridden IntermediateOutputPath to point to the same directory for all my projects. This messed up NuGet intermediate files during parallel build. Fixing Build.Directory.props to include $(MSBuildProjectName) in IntermediateOutputPath resolved the issue for me.