Não é possível encontrar o destino de tempo de execução para a estrutura .NETCoreApp = v1 compatível com um dos tempos de execução de destino


149

Estou tentando migrar um projeto Asp.Net Core RC1 para RC2 e segui esta documentação e também segui as instruções para migração de DNX para a CLI do .NET.

Estou recebendo o seguinte erro ao tentar dotnet run:

Não é possível encontrar o destino de tempo de execução para a estrutura '.NETCoreAPP, Versão = v1.0' compatível com um dos tempos de execução de destino: 'win10-x64, win81-x64, win8-x64, win7-x64'. Causas Possíveis:

  1. O projeto não foi restaurado ou a restauração falhou - execute 'dotnet restore'
  2. O projeto não lista um dos 'win10-x64, win81-x64, win7-x64' nos 'tempos de execução'

Eu corri dotnet restoree parece ter sido concluído com êxito.

Atualizei todos os pacotes relevantes para o RC2.

Respostas:


290

Eu deveria ter feito exatamente o que dizia a mensagem de erro. Ao migrar do RC1, não percebi que precisava especificar uma runtimesseção no meu project.jsonarquivo.

No meu project.jsoneu adicionei a seguinte seção:

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

E eu estava pronto para ir.


Atualização 27 de fevereiro de 2017

Novos modelos de projeto no Visual Studio 2017 RC já não necessitam de tempos a serem especificados (em executar project.jsonou .csproj) com antecedência se você optar por implantar a sua aplicação como um Framework Dependent Deployment(FDD).

Se, no entanto, você optar por implantar seu aplicativo usando Self-contained Deployment(SCD), precisará especificar todos os tempos de execução nos quais deseja que seu aplicativo seja executado com antecedência em seu .csprojarquivo.

Abaixo está um exemplo de .csprojarquivo para um aplicativo que usa o método de implantação do SCD:

<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>

Consulte este link para obter mais informações, que inclui uma descrição completa dos dois tipos de opções de implantação, bem como seus benefícios e desvantagens.


42
Criei um novo projeto no VS 2015 Update 3. E ainda faltava essa seção.
Edward Olamisan

7
Eu acho que nem sempre é necessário adicionar essa configuração. A documentação diz: "Se você é uma biblioteca de classes portátil que pode ser executada em qualquer tempo de execução, não é necessário especificar um tempo de execução". - Isso é verdade para a maioria dos meus projetos, mas esse erro apareceu quando adicionei um projeto do Entity Framework Core à minha solução. Eu acho que o EF Core - pelo menos em seu estado RC2 - tem uma limitação em quais plataformas ele pode rodar, portanto, os projetos que o referenciam, podem precisar estar em conformidade com essas configurações. Mas estou apenas adivinhando. A documentação é realmente confusa neste momento.
Bernhard Koenig

7
Nem precisava disso em um novo modelo 1.0 Core VS2015, atualizado para 1.0.1 e obteve o erro acima, thx para a correção!
Steve McNiven-Scott

1
@ SteveMcNiven-Scott - O mesmo aqui. Eu também tive que adicionar outra linha em "tempos de execução" para restaurá-la e criar no Ubuntu Server: "ubuntu.16.04-x64". YMMV, mas o erro deve indicar a plataforma que você está perdendo e precisaria adicionar.
Tsar Bomba

5
A mensagem de erro não menciona "project.json". Como as pessoas devem adivinhar?
usefulBee

76

Recebi esse erro após atualizar o modelo principal do VS2015 para 1.0.1. Foi porque eu tenho uma PCL que tem como alvo netstandard 1.4 se você não precisa especificar cada tempo de execução, basta alterar a marcação de dependência para Microsoft.NETCore.Appisso:

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

1
A marcação acima corrigiu meu erro de compilação, mas o IIS Express não seria iniciado depois disso. Alterar "version": "1.0.1" para "version": "1.0.0" resolveu o problema do IIS.
Ross

@Ross atualize a seção de ferramentas em project.json para corresponder à versão NETCore.App
DalSoft 12/16/16

Nesse caso, "ferramentas": {"Microsoft.AspNetCore.Server.IISIntegration.Tools": "1.0.0-preview2-final"}, #
1013 DalSoft

1
@ DalSoft - Sim, atualizei meu VS 2015 há algumas semanas com os patches mais recentes, incluindo IISIntegration.Tools, e resolveu o problema Microsoft.NETCore.App: 1.0.1 para mim.
Ross

1
@usefulBee Biblioteca de Classes Portátil
Mike_G

35

em project.json eu mudei isso (tipo adicionado):

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

Agora eu posso construir novamente :-)

update: agora posso construir novamente, mas não "executar" o site.

Você precisa ter o tempo de execução e o sdk também:

*) As ferramentas do Visual Studio incluem o .NET Core 1.0.1. Para adicionar suporte ao .NET Core 1.1, você também precisa instalar o tempo de execução do .NET Core 1.1.

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


1
Parece que você não pode executar o site porque precisa instalar o SDK do .NET Core 1.1 #
Victor Sharovatov

e às vezes reinstalar o Runtime também é necessário, descobri.
juFo

Isso me ajudou. Obrigado! Comentando "Microsoft.NETCore.App" diretamente das dependências no project.json e alterando-o para "frameworks": {"netcoreapp1.1": {"dependencies": {"Microsoft.NETCore.App": {" version ":" 1.1.0 "," type ":" platform "}}}},
neodímio

1
Obrigado. Estes 2 passos simples resolveram o problema. Esperamos que a MS a torne mais amigável ao desenvolvedor em um futuro próximo.
EvZ 02/02

20

Recebi esse erro porque usei o incrivelmente quebrado NuGet Package Manager no Visual Studio 2015 para atualizar minhas dependências project.json. Aconteceu isso:

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

nisso:

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

Adeus, definição de plataforma!


15

Se você ler estes dois links:

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

e

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

Você verá que é possível criar uma versão completamente portátil usando o seguinte trecho no elemento raiz de dependências em project.json. Não há necessidade de especificar tempos de execução, pois esse é um tempo de execução no nível CORE, que deve ser independente da plataforma ou conhecido como "Dependente da estrutura"

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

ou você pode criar para várias plataformas direcionadas ("aplicativos independentes") removendo o elemento type: platform como este:

Inclua isso no elemento raiz das dependências em project.json

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

e adicione isso como um novo elemento de nível raiz

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

Vários destinos exigem que você forneça nomes de plataformas conhecidos como ".NET Core Runtime IDentifiers (RID)". Uma lista deles pode ser encontrada no segundo link acima. Inclui muitos sabores do Windows, Linux e OS X.

Para uma boa visão geral das várias opções de implantação, você também pode ler esta página:

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

No link acima:

Você pode criar dois tipos de implantações para aplicativos .NET Core:

Implantação dependente da estrutura

Como o nome indica, a implantação dependente da estrutura (FDD) depende de uma versão compartilhada em todo o sistema do .NET Core para estar presente no sistema de destino. Como o .NET Core já está presente, seu aplicativo também é portátil entre instalações do .NET Core. Seu aplicativo contém apenas seu próprio código e quaisquer dependências de terceiros que estão fora das bibliotecas do .NET Core. Os FDDs contêm arquivos .dll que podem ser iniciados usando o utilitário dotnet na linha de comando. Por exemplo, dotnet app.dll executa um aplicativo chamado app.

Implantação independente

Diferentemente do FDD, uma implantação autônoma (SCD) não depende de nenhum componente compartilhado para estar presente no sistema de destino. Todos os componentes, incluindo as bibliotecas do .NET Core e o tempo de execução do .NET Core, estão incluídos no aplicativo e são isolados de outros aplicativos do .NET Core. Os SCDs incluem um executável (como app.exe em plataformas Windows para um aplicativo chamado app), que é uma versão renomeada do host .NET Core específico da plataforma e um arquivo .dll (como app.dll), que é a aplicação real.


9

No meu caso, eu havia acabado de atualizar todos os pacotes de nuget para suas versões mais recentes e o nuget mudou minha referência de pacote 'Microsoft.NETCore.App' para o seguinte:

"Microsoft.NETCore.App": "1.1.0"

Eu mudei de volta para o seguinte formulário e tudo funcionou bem:

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

Adeus 3 horas da minha vida ....


4

se você executar um dotnet new e examinar o projeto de saída json, verá que os apelidos foram alterados.

Faça as alterações no seu project.json da seguinte maneira:

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

Para mim, esta é a melhor solução. O .NET Core está em um estado de fluxo e as coisas continuam mudando. Usando a CLI para gerar um project.json para corrigir alterações no seu project.json que o NuGet PM parece incapaz de manter consistente e atualizado.
James B

0

Encontrei um link útil a partir do comentário de svick na seguinte página: https://github.com/dotnet/cli/issues/2442


1
Embora sua resposta esteja 100% correta, ela também pode se tornar 100% inútil se esse link for movido, alterado, mesclado em outro ou o site principal simplesmente desaparecer ... :-( Portanto, edite sua resposta e copie a mensagem relevante. passos do link para a sua resposta, garantindo assim sua resposta por 100% da vida útil deste site! ;-) Você sempre pode deixar o link na parte inferior da sua resposta como fonte do seu material ...
Donald Duck

0

Eu achei que você precisava do seguinte em project.json. Aqui está o que foi necessário para corrigir meu erro:

Dependências

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

Frameworks

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

Tempo de execução

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

Você pode querer adicionar tempos de execução se planeja publicar no IIS. Por favor, veja o seguinte:

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

Aqui está uma dica geral que funcionou bem para mim. Quando minhas coisas são interrompidas, às vezes crio um aplicativo ASP.NET Core padrão, o site ou a API da Web vazia, para examinar as dependências no project.json e em outros lugares. Muitas vezes você pode pegar muitas coisas dessa maneira. As respostas acima são pontuais, mas pensei em escrever isso aqui, caso alguém queira separar a lógica mais no formato geral do modelo usado pelo ASP.NET Core.


0

No Windows 7 com o VS 2015, a solução após a atualização para o netcore 1.1.2 estava alterando o arquivo project.json da seguinte maneira:

{
"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
  }                             //
}

Depois de mudar isso, as dependências serão atualizadas e viola.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.