Reputation: 3364
Using Visual Studio 2017, AspNetCore 1.1.2
All of a sudden I am getting following error when I am trying to publish (Release build) any project in the solution:
Assets file 'C:\example\obj\project.assets.json' doesn't have a target for '.NETFramework,Version=v4.5.2/win7-x86'. Ensure that restore has run and that you have included 'net452' in the TargetFrameworks for your project. You may also need to include 'win7-x86' in your project's RuntimeIdentifiers.
Have checked in the project.assets.json
files, I have:
"targets": {
".NETFramework,Version=v4.5.2": {
and
"runtimes": {
"win7-x86": {
"#import": []
}
In the *.csproj files I have:
<PropertyGroup>
<TargetFramework>net452</TargetFramework>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
Have made no changes to config in the projects. Only thing is that I have updated VS2017 to latest version today, 15.6.3. Could this cause issue?
Upvotes: 144
Views: 132877
Reputation: 7938
In my case I upgraded a classic .NET 4 project (exe type) to the cleaner Sdk version. Local build (VS 2022) did not give errors, but on Azure DevOps the build failed.
Adding an explicit PlatformTarget
to the .csproj solved the issue.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net48</TargetFramework>
<PlatformTarget>AnyCPU</PlatformTarget>
</PropertyGroup>
</Project>
Projects with the "Library"
OutputType
did not need an explicitPlatformTarget
. For these project types "AnyCPU" seems to be the default.
Upvotes: 0
Reputation: 899
It is craaaaazy to see how this error message is confusing regarding the number of solutions. My solution: consists in adding the Runtime Identifier (RID) in all csproj:
<RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
To avoid having the RID suffixed in output directory:
<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
Final csproj
<PropertyGroup>
<TargetFramework>net48</TargetFramework>
<OutputType>WinExe</OutputType>
<Platforms>x64</Platforms>
...
<UseWindowsForms>true</UseWindowsForms>
<OutputPath>bin\$(Platform)\$(Configuration)\</OutputPath>
<RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath>
</PropertyGroup>
Indicate it in the dotnet restore:
dotnet restore "${PROJECT_NAME}.sln" -r win-x64
pass it also to msbuild:
msbuild "${PROJECT_NAME}.sln" /p:Configuration=${BUILD_CONFIG} /p:Platform="${BUILD_PLATFORM}" /t:Rebuild /p:Runtimeidentifier=win-x64
Upvotes: 0
Reputation: 31980
From https://learn.microsoft.com/en-us/dotnet/core/tools/sdk-errors/netsdk1005
When the .NET SDK issues error NETSDK1005 or NETSDK1047, the project's assets file is missing information on one of your target frameworks. NuGet writes a file named project.assets.json in the obj folder, and the .NET SDK uses it to get information about packages to pass into the compiler.
First ensure that a nuget restore for your project works correctly using dotnet restore
. Resolve any issues first, then try rebuilding your project (you may need to delete the obj
folder first).
Upvotes: 1
Reputation: 1
Just edit target framework in profile to new dot net version. It can resolve your problem.
Upvotes: 0
Reputation: 4587
For me it was the happening because I had migrated my project from .net5.0
to .net6.0
and the problem was caused when I was publishing the project while debugging worked fine.
Checking the publishing profile showed that it had a configuration for .net5.0
in it:
Changing the existing .net core
version with the desired one resolved the issue:
Upvotes: 7
Reputation: 164
On my end I had this issue with net6.0 at build time, even before trying to publish. Even if everything was pointing to csproj and it had all the right TargetFramework, the issue was that our repo had a Nuget.Config at it's root and it included a configuration for a local disk Nuget Repo of another programmer. I disabled the Nuget.Config file and I was able to build the project. It was probably unable to restore the Nuget Packages but the error message was misleading.
Upvotes: 0
Reputation: 571
Running dotnet restore --packages .nuget
in the project directory fixed the issues for me.
Upvotes: 8
Reputation: 665
I upgraded from netstandard to net6.0, when publishing had to change TargetFramework to net6.0
Upvotes: 1
Reputation: 56
Had the same problem, for me it was that I had a space before my TargetFramework
<TargetFramework> net6.0</TargetFramework>
Upvotes: 0
Reputation: 320
I ran into the NETSDK1047
when playing around with Docker in a brand new dotnet project created using dotnet new worker
and the docker file from dotnet-docker samples.
❯ docker build -t dockertest .
output elided...
/usr/share/dotnet/sdk/6.0.300/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(267,5): error NETSDK1047: Assets file '/source/obj/project.assets.json' doesn't have a target for 'net6.0/linux-musl-x64'. Ensure that restore has run and that you have included 'net6.0' in the TargetFrameworks for your project. You may also need to include 'linux-musl-x64' in your project's RuntimeIdentifiers. [/source/dockertest.csproj]
The command '/bin/sh -c dotnet publish -c release -o /app -r linux-musl-x64 --self-contained true --no-restore /p:PublishTrimmed=true /p:PublishReadyToRun=true /p:PublishSingleFile=true' returned a non-zero code: 1
dockertest on main [✘] via .NET v6.0.202 🎯 net6.0
❯
The issue was because I forgot to add a .dockerignore
file ignoring the bin
and obj
directories.
I only realized why because I tried different Dockerfiles from the dotnet-docker
repo and got a different error which has this same resolution. I'll try to make a PR to the docs of NETSDK1047
to add this resolution. edit: link to PR https://github.com/dotnet/docs/pull/29530
Upvotes: 1
Reputation: 1
From my experience if you have dependencies in your solution built using "ProjectSection(ProjectDependencies) = postProject" then in this case dotnet build goes nuts.
Upvotes: 0
Reputation: 21
In my case, if you have TargetFrameworks
and TargetFramework
together in the csrpoj file, remove TargetFramework
will solve the problem.
edit it from:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard2.0;net461;</TargetFrameworks>
<TargetFramework>net461</TargetFramework><!--remove this line-->
</PropertyGroup>
</Project>
to
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard2.0;net461;</TargetFrameworks>
</PropertyGroup>
</Project>
Upvotes: 2
Reputation: 29213
According to the Microsoft blog (which, bizarrely, my account doesn't have permissions to post in), this isn't a bug, and is entirely caused by ReSharper. If you disable this, the problem goes away.
Errr, one problem: I'm getting this error, and I don't have ReSharper.
After a lot of hunting around, I found the reason I was getting the error on my .NET Core project which had been upgraded from 1.0 to 2.1.
When running my project in Debug or Release mode, everything worked fine, but when I tried to publish to Azure, I got that error:
Assets file '(mikesproject)\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v2.0'. Ensure that restore has run and that you have included 'netcoreapp2.0' in the TargetFrameworks for your project.
Although I had updated the version of .NET Core to 2.1 in Project\Properties and upgraded the various nuget packages, there was one place which hadn't picked up this change... the Publish Profile file.
I needed to go into the Properties\PublishProfiles
folder in my solution, open up the .pubxml
file relating to the way I was publishing to Azure, and change this setting from netcoreapp2.0
to netcoreapp2.1
:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
. . .
<TargetFramework>netcoreapp2.0</TargetFramework>
. . .
</PropertyGroup>
</Project>
Ridiculous, hey?
I do wish Microsoft error messages gave some clue as to the source of problems like this.
Upvotes: 167
Reputation: 416
In my case updating visual studio 2019 to the latest version, fixed the issue.
Upvotes: 0
Reputation: 529
I got this error when upgrading a web project from netcoreapp3.1 to net5.0.
One of the answers here pointed me in the right direction:
The publish profile still had netcoreapp3.1 as target framework. Edited the publish profile and changed target framework to net5.0 and it worked.
(Visual Studio 16.8)
Upvotes: 4
Reputation: 463
If your build script starts with a dotnet restore
and ends with a dotnet publish --no-restore
, you must make sure that they both include the same --runtime
parameter.
Upvotes: 10
Reputation: 111
I had similar issue, when I installed a new sdk version.
Exception was:
Severity Code Description Project File Line Suppression State Error NETSDK1005
Assets file '.. \RazorPages\obj\project.assets.json' doesn't have a target for
'netcoreapp3.1'. Ensure that restore has run and that you have included 'netcoreapp3.1'
in the TargetFrameworks for your project. RazorPages
C:\Program Files\dotnet\sdk\5.0.102\Sdks\Microsoft.NET.Sdk
\targets\Microsoft.PackageDependencyResolution.targets 241
Solution was to select again the target version of the project.
Upvotes: 2
Reputation: 287
Receiving similar error for 'netcoreapp3.1' when building using command line. It turned out to be an MsBuild switch that caused the issue. Specifically speaking:
/p:TargetFramework="netcoreapp3.1"
Removed the switch and the error was fixed.
Upvotes: 1
Reputation: 6978
You should try all the other solutions here first. Failing that you can try what eventually unblocked me when none of these did. I ran into this problem when porting a Jenkins build to an Azure DevOps pipeline on a pool of agents. It took about 60 builds before I tried every other possibility. I found out that needed to do two things:
The versions I needed to use are likely different than yours.
1:
call choco install windows-adk-all --version=10.0.15063.0 --force
call choco install windows-sdk-10.1 --version=10.1.15063.468 --force
2:
call MSBuild -t:restore Solution.sln
call MSBuild Solution.sln /t:rebuild;pack /p:Configuration=Release /p:Platform="Any CPU"
Upvotes: 3
Reputation: 1252
Migrating from nuget 5.4 to nuget 5.8 solve the problem on my devops build server
Upvotes: 29
Reputation: 104781
To me, the error was caused because of an existing global.json file in the solution level folder, pointing to a different .NET version. Removing that file (or changing its SDK version) resolved the problem
Upvotes: 2
Reputation: 1226
A colleague ran into this after upgrading an application from dotnet core 1.1 to dotnet core 2.1. He properly updated all the targetFramework references within the various csproj files, and had no issues on his local development machine. However, we run Azure DevOps Server and build agents on-premises, so the build agent was reporting this error after a pull request build was executed.
The dotnet clean
task was throwing an error because of the new targeted framework. dotnet clean
uses the same targets as build, publish, etc, so after a change in target frameworks the dotnet restore
must happen before the dotnet clean
to update the dependent files. In hindsight this makes sense because you want to restore dependencies to the proper target framework before you do any building or deploying.
This may only affect projects with upgraded target frameworks but I have not tested it.
Upvotes: 1
Reputation: 211
Delete the publish profile you created and create a new one. The wizard will put in the correct targetframe work for you and publish again. It should solve the problem.
Upvotes: 14
Reputation: 8616
Had this error in similar situation. This has helped me: Link
This is my property group in *.csproj file of my .net core 3.0 project:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFrameworks>netcoreapp3.0</TargetFrameworks>
<RuntimeIdentifier>win-x64</RuntimeIdentifier> <----- SOLVES IT. Mandatory Line
</PropertyGroup>
Upvotes: 50
Reputation: 2120
Restarting Visual Studio or unloading/reloading the project didn't work for me, but deleting the "obj" folder and then rebuilding seems to have fixed the issue.
Upvotes: 4
Reputation: 3732
For me the problem ended up being that one of my NuGet feeds was down, so a package was not getting updated properly. It wasn't until I ran a NuGet package restore directly on the solution that I saw any error messages related to my NuGet feed being down.
Upvotes: 3
Reputation: 2530
Right click on the project file, and click unload. Then right click on the project and reload.
Upvotes: 58