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?

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>

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)

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.

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.

Answer 5

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.

Answer 6

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>

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