asp.net – Can not find runtime target for framework .NETCoreApp=v1 compatible with one of the target runtimes

The Question :

149 people think this question is useful

I am trying to migrate an Asp.Net Core RC1 project to RC2 and have been following this documentation and have also followed the instructions for DNX migration to .NET CLI.

I am getting the following error when I try dotnet run:

Can not find runtime target for framework ‘.NETCoreAPP, Version=v1.0’ compatible with one of the target runtimes: ‘win10-x64, win81-x64, win8-x64, win7-x64’. Possible causes:

  1. The project has not been restored or restore failed -run ‘dotnet restore’
  2. The project does not list one of ‘win10-x64, win81-x64, win7-x64’ in the ‘runtimes’

I have run dotnet restore and it seems to have completed successfully.

I have updated all the relevant packages to RC2.

The Question Comments :

The Answer 1

290 people think this answer is useful

I should have done exactly what the error message said. When migrating from RC1, I did not realise that I had to specify a runtimes section in my project.json file.

In my project.json I added the following section:

"runtimes": {
    "win10-x64": { }
  }

And I was good to go.


Update 27 February 2017

New project templates in Visual Studio 2017 RC no longer require run times to be specified (in project.json or .csproj) in advance if you choose to deploy your app as a Framework Dependent Deployment (FDD).

If, however, you choose to deploy your app using Self-contained Deployment (SCD), then you will need to specify all the run times you want your app to run on in advance in your .csproj file.

Below is an example of a .csproj file for an app that uses the SCD deployment method:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <VersionPrefix>1.0.0</VersionPrefix>
    <DebugType>Portable</DebugType>
    <RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="9.0.1" />
  </ItemGroup>
</Project>

Please see this link for more information, which includes a thorough description of both types of deployment options, as well as their benefits and disadvantages.

The Answer 2

76 people think this answer is useful

I received this error after updating VS2015 core template to 1.0.1. It was because I have a PCL that targets netstandard 1.4 if you don’t want to have to specify each runtime, Just change the dependency markup for Microsoft.NETCore.App to this:

"Microsoft.NETCore.App": {
 "type": "platform",
 "version": "1.0.1"
}

The Answer 3

35 people think this answer is useful

in project.json I changed this (added type):

//"Microsoft.NETCore.App": "1.1.0",
"Microsoft.NETCore.App": { "version": "1.1.0", "type": "platform" },

Now I can build again 🙂

update: now I can build again but not “run” the website.

You need to make sure you have the runtime and sdk also:

*) Visual Studio tools include .NET Core 1.0.1. To add .NET Core 1.1 support you need to also install the .NET Core 1.1 runtime.

https://www.microsoft.com/net/download/core#/current

The Answer 4

20 people think this answer is useful

I received this error because I used the incredibly broken NuGet Package Manager in Visual Studio 2015 to update my project.json dependencies. It turned this:

"frameworks": {
  "netcoreapp1.0": {
    "dependencies": {
      "Microsoft.NETCore.App": {
        "type": "platform",
        "version": "1.0.1"
      } 
    }
  }
}

into this:

"dependencies": {
  "Microsoft.NETCore.App": "1.1.0"
},
"frameworks": {
  "netcoreapp1.0": {}
}

Bye bye, platform definition!

The Answer 5

15 people think this answer is useful

If you read these two links:

First, https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/using-with-xplat-cli

and

second, https://docs.microsoft.com/en-us/dotnet/articles/core/rid-catalog

You will see that you can build a completely portable version using the following snippet in the dependencies root element in project.json. There is no need to specify runtimes as this is a CORE level runtime which should be platform agnostic, or known as “Framework dependent”

"Microsoft.NETCore.App": {
    "type": "platform",
    "version": "1.0.1"
}

or you can build for multiple targeted platforms (“self contained applications”) by removing the type: platform element like this:

Add this to the dependencies root element in project.json

"Microsoft.NETCore.App": {
    "version": "1.0.1"
}

and add this as a new root level element

"runtimes": {
    "win10-x64": {},  /* one or more RIDs */
    "osx.10.10-x64": {}
  },

Multiple targeted requires that you supply platform names known as “.NET Core Runtime IDentifiers (RID)” A list of these can be found at the second link above. It includes many flavors of Windows, Linux and OS X.

For a good overview of the various deployment optins, you can read this page as well:

https://docs.microsoft.com/en-us/dotnet/articles/core/deploying/index

From the above link:

You can create two types of deployments for .NET Core applications:

Framework-dependent deployment

As the name implies, framework-dependent deployment (FDD) relies on a shared system-wide version of .NET Core to be present on the target system. Because .NET Core is already present, your app is also portable between installations of .NET Core. Your app contains only its own code and any third-party dependencies that are outside of the .NET Core libraries. FDDs contain .dll files that can be launched by using the dotnet utility from the command line. For example, dotnet app.dll runs an application named app.

Self-contained deployment

Unlike FDD, a self-contained deployment (SCD) does not rely on any shared components to be present on the target system. All components, including both .NET Core libraries and the .NET Core runtime, are included with the application and are isolated from other .NET Core applications. SCDs include an executable (such as app.exe on Windows platforms for an application named app), which is a renamed version of the platform-specific .NET Core host, and a .dll file (such as app.dll), which is the actual application.

The Answer 6

9 people think this answer is useful

In my case I had just updated all the nuget packages to their latest versions and nuget changed my ‘Microsoft.NETCore.App’ package reference to the following:

"Microsoft.NETCore.App": "1.1.0"

I changed it back to the following form and everything worked fine:

"Microsoft.NETCore.App": {
      "version": "1.1.0",
      "type": "platform"
    }

Good bye 3 hours of my life….

The Answer 7

4 people think this answer is useful

if you execute a dotnet new and look at the output project json, you will see that the monikers have changed.

Make the changes to your project.json as follows:

"dependencies": {},
   "frameworks": {
     "netcoreapp1.0": {
        "dependencies": {
         "Microsoft.NETCore.App": {
         "type": "platform",
         "version": "1.0.1"
         }
    },
      "imports": "dnxcore50"
    }
  }

The Answer 8

0 people think this answer is useful

I found one useful link from comment by svick under following page: https://github.com/dotnet/cli/issues/2442

The Answer 9

0 people think this answer is useful

I found you need the following in project.json. Here is what was required to fix my error:

Dependencies

"dependencies": {
   "Microsoft.NETCore.App": {
      "version": "1.0.1",
      "type": "platform"
   },
}

Frameworks

"frameworks": {
    "netcoreapp1.0": {
      "imports": [
        "dotnet5.6",
        "portable-net45+win8"
      ]
    }
  },

Runtime

  "runtimeOptions": {
    "configProperties": {
      "System.GC.Server": true
    }
  },

You might want to add runtimes if you plan on publishing to IIS. Please see something as follows:

 "runtimes": {
    "win10-x64": {}
  },

Here is a general tip that has worked well for me. When my stuff breaks, I sometimes create a default ASP.NET Core application either the website or empty web api to look at the dependencies in project.json and elsewhere. You can often catch a lot of things that way. The answers above are spot on, but I thought I would write this here in case someone wanted to separate the logic out more in the general template format that ASP.NET Core uses.

The Answer 10

0 people think this answer is useful

In Windows 7 with VS 2015, the soluiton after updating to netcore 1.1.2 was changing the project.json file as following:

{
"version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.NETCore.App": "1.1.2"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"    //This line must disappear
    }
  },

  "runtimes": {                 //
    "win7-x64": {}              //Add this lines
  }                             //
}

After changing this the dependencies will update and viola.

Tags:

Add a Comment