ASP.NET Core Application (.NET Framework) for Windows x64 only error in project.assets.json

Question

I want to simplify my configuration in my ASP.NET Core Web Application (.NET Framework) application using VS 2017.

I already know that my website will be running under Windows/IIS in x64 environment and .NET 4.6.2. There is no chance in the foreseen and unforeseen future for this application to use any other environment from the dev to production.

So, I only need Debug x64 and Release x64 modes only. (AnyCPU and x86 are not needed!), so I went ahead and removed all other configuration from the project.

Now, upon compilation, I am getting the following error:

'C:\Projects\MyProject\My.Website\obj\project.assets.json' doesn't have a target for '.NETFramework,Version=v4.6.2/win7-x64'.

Ensure you have restored this project for TargetFramework='net462' and RuntimeIdentifier='win7-x64'. MD.Website C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.targets

I am developing on Windows 7, I am not sure how to fix this one. Any idea?

Spies

Remove that file and let VS generate a new copy to see if it fixes. – Clements

@LexLi I should have mentioned that I tried deleting and rebuilding and all the troubleshooting stuff before posting. No, this didn't work :( – Spies

Answer 1

For some reason <TargetFramework> in my .csproj file was singular. I added an "s" and it became "TargetFrameworks", which worked:

  <PropertyGroup>
    <TargetFrameworks>net462</TargetFrameworks>
    <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
  </PropertyGroup>

Spies

For me I guess this is a bug in the migration from the xproj to csproj. Did you get this issue creating a new project with VS2017 or did you also migrate? – Louettalough

For me adding 's' gave another problem. But I was missing <RuntimeIdentifier> so I just added it. – Jumada

Happened when I upgraded from VS 15.3 to 15.4, then all hell broke lose. Added the 's' and then it compiled and ran. – Declamation

I think this is because changing to "TargetFrameworks" trigger nuget package being restored. – Rhebarhee

Also you need to run dotnet restore as well, which Tiago also mentioned in the next – Twospot

Wtf is this bug? I got it updating from .NET Core 2.0 to 2.2. After doing as proposed it went away, but when I tried to publish my webapp it came back - needed to apply James' solution as well. – Despoil

Answer 2

I didn't change my TargetFramework, I ran in the Package Manager Console the command:

dotnet restore

And it worked! (I'm using VS2017 and I'm doing a .net core application pointing to .net framework)

Interment

Thanks! It worked for me. I had an asp.net core (.net framework) application. – Reeva

From Microsoft docs: Starting with .NET Core 2.0, you don't have to run dotnet restore because it's run implicitly by all commands that require a restore to occur, such as dotnet new, dotnet build and dotnet run. It's still a valid command in certain scenarios where doing an explicit restore makes sense, such as continuous integration builds in Visual Studio Team Services or in build systems that need to explicitly control the time at which the restore occurs. – Misjudge

Answer 3

I had manually changed mine from x86 to x64. In this case, just restoring the packages from Visual Studio would not work but closing Visual Studio, deleting the project.assets.json, re-starting Visual Studio and re-building the project worked for me. I left <TargetFramework> singular.

Command line nuget restore ... may also have worked.

Schlicher

Answer 4

I had this issue when trying to publish a dotnetcore console application to a local folder after upgrading it to version 2.0.

After trying all the deleting folders and dotnet restore and making sure all settings in Application and Build were 2_0 to no avail. I realised my publish profile was still targeting 1.1, even though 2.0 was showing as selected when I went into edit the profile, it showed 1.1 in the publish summary. So I re-selected 2.0 in the dropdown and it updated the summary to show 2.0 and it all worked fine.

Rafflesia

After trying all of the above, this answer worked for me. It was actually already on 2.1, but somehow going into the publish settings and resetting it to 2.1 fixed the issue and I published successfully. – Nels

I needed to open the "Configure..."-dialog once - the 2.2 in my case was already there but I needed to open it once manually... – Despoil

Answer 5

For some reason <RuntimeIdentifier> in my .csproj file was missing. Adding it resolved this issue for me:

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>  
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>      
  <Platforms>AnyCPU;x64</Platforms>
  <LangVersion>7.3</LangVersion>
</PropertyGroup>

Birdt

Answer 6

I have a .net core application pointing to .net framework 4.6.1 in VS2017 which I tried to publish. I changed my platform target from x86 to x64 and started to get this error when I tried to publish again but I didn't have any problems to build. I just opened publish profile settings and everything looked normal (target runtime was win7-x64) but that was enough for my publish to start working properly.

Bowman

Answer 7

Check the actual publishing profile file of the Publish you are trying to run. In our case, we have a set of projects that have to be shared between Core and regular asp.net, so we target Core 1.1 and set the runtime version to 4.6.1. After running through all of the projects and updating them to target version 4.7, I started getting this error on publish (the actual builds worked fine, as did localhost debugging, it was the publish that was jacked).

Checking the actual "widgets - Web Deploy.pubxml" file, I found this at the bottom:

    <_DestinationType>AzureWebSite</_DestinationType>
    <TargetFramework>net461</TargetFramework>
    <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
  </PropertyGroup>
</Project>

As others on this thread have mentioned, simply opening up the property sheet of the publishing profile will show you, in my case, that the framework was targeted to 4.7 (which was accurate per the projects involved but did not reflect the actual value in the file)... I did still need to click the Save button to get the underlying .pubxml file to actually be updated with the correct value. You can probably edit that file manually too, if you feel so inclined.

This one drove me nuts. :)

Famagusta

Answer 8

As Boris pointed out, in my case the problem was in the PublishProfiles. First, I added the following in my .csproj file (As BluE mentioned in the post above):

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>  
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>      
  <Platforms>AnyCPU;x64</Platforms>
  <LangVersion>7.3</LangVersion>
</PropertyGroup>

and then I opened my PublishProfile

and then click on the Edit link:

and finally in the opening dialog, set the TargetFramework to your project's Framework and the TargetRungime to win-x64 and then click Save!

Thats it!
Now if you try publishing your project using this profile, it should be working perfectly.
Hope it helps someone.

Macri

Answer 9

For me moving the PlatformTarget section to the common PropertyGroup fixed the same problem on Azure DevOps build:

Does not work:

<PropertyGroup>
    <TargetFramework>net461</TargetFramework>
    ...
    <Platforms>x64</Platforms>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    ...
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Works:

<PropertyGroup>
    <TargetFramework>net461</TargetFramework>
    ...
    <Platforms>x64</Platforms>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
    ...
</PropertyGroup>

Radiocarbon

Answer 10

• Fore sure the "dot net engineers" did lot of mistakes in their design.
• note above : target framework with or without s is to indicate if you target one or more framework, both exist.
• Adding runtimeidentifier indeed solve the solution and put the binary in an additional level inside the subfolder win7-x64.
• for my case i did change nothing , just before building i changed the "nuget restore" into "dotnet restore" and it solved the issue (i just cannot accept to see a "win7" in a folder name when target binary should run on multiple windows version/ the purpose of dotnet ....).

Runyan