Nie można znaleźć miejsca docelowego środowiska wykonawczego dla platformy .NETCoreApp = v1 zgodnej z jednym z docelowych środowisk wykonawczych

Próbuję przeprowadzić migrację projektu Asp.Net Core RC1 do RC2 i postępuję zgodnie z tą dokumentacją, a także postępuję zgodnie z instrukcjami dotyczącymi migracji DNX do .NET CLI.

Podczas próby pojawia się następujący błąd dotnet run:

Nie można znaleźć miejsca docelowego dla środowiska wykonawczego „.NETCoreAPP, Version = v1.0” zgodnego z jednym z docelowych środowisk wykonawczych: „win10-x64, win81-x64, win8-x64, win7-x64”. Możliwe przyczyny:

1. Projekt nie został przywrócony lub przywracanie nie powiodło się - uruchomiono przywracanie dotnet
2. Projekt nie wymienia jednego z „win10-x64, win81-x64, win7-x64” w „runtimes”

Biegałem dotnet restorei wydaje się, że zakończyło się pomyślnie.

Zaktualizowałem wszystkie odpowiednie pakiety do RC2.

Powinienem był zrobić dokładnie to, co powiedział komunikat o błędzie. Podczas migracji z RC1 nie zdawałem sobie sprawy, że muszę określić runtimessekcję w moim project.jsonpliku.

W moim project.jsondodałem następującą sekcję:

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

I byłem gotowy.

Aktualizacja 27 lutego 2017 r

Nowe szablony projektów w programie Visual Studio 2017 RC nie wymagają już wcześniejszego określania czasów wykonywania (w project.jsonlub .csproj), jeśli zdecydujesz się wdrożyć aplikację jako Framework Dependent Deployment(FDD).

Jeśli jednak zdecydujesz się wdrożyć aplikację przy użyciu Self-contained Deployment(SCD), musisz z wyprzedzeniem określić w .csprojpliku wszystkie czasy wykonywania, w których aplikacja ma działać .

Poniżej znajduje się przykład .csprojpliku aplikacji korzystającej z metody wdrażania 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>

Aby uzyskać więcej informacji, zobacz to łącze , które zawiera dokładny opis obu typów opcji wdrażania, a także ich zalety i wady.

Otrzymałem ten błąd po aktualizacji podstawowego szablonu VS2015 do wersji 1.0.1. To dlatego, że mam PCL, który jest przeznaczony, netstandard 1.4 jeśli nie chcesz określać każdego środowiska uruchomieniowego, po prostu zmień znaczniki zależności na Microsoft.NETCore.Appto:

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

w project.json zmieniłem to (dodany typ):

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

Teraz mogę znowu budować :-)

aktualizacja: teraz mogę ponownie zbudować, ale nie mogę "uruchomić" strony.

Musisz również upewnić się, że masz środowisko uruchomieniowe i sdk:

*) Narzędzia programu Visual Studio obejmują .NET Core 1.0.1. Aby dodać obsługę platformy .NET Core 1.1, należy również zainstalować środowisko uruchomieniowe .NET Core 1.1.

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

Otrzymałem ten błąd, ponieważ użyłem niesamowicie zepsutego Menedżera pakietów NuGet w programie Visual Studio 2015 do zaktualizowania moich zależności project.json. Okazało się, że:

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

zaangażowany w to:

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

Do widzenia, definicja platformy!

Jeśli przeczytasz te dwa linki:

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

i

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

Zobaczysz, że możesz zbudować całkowicie przenośną wersję, używając następującego fragmentu kodu w elemencie głównym zależności w project.json. Nie ma potrzeby określania środowiska wykonawczego, ponieważ jest to środowisko wykonawcze na poziomie CORE, które powinno być niezależne od platformy lub określane jako „zależne od struktury”

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

lub możesz tworzyć dla wielu docelowych platform („samodzielnych aplikacji”), usuwając element type: platform w następujący sposób:

Dodaj to do elementu głównego zależności w project.json

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

i dodaj to jako nowy element poziomu głównego

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

Wiele celów wymaga podania nazw platform znanych jako „.NET Core Runtime IDentifiers (RID)”. Ich listę można znaleźć w drugim linku powyżej. Zawiera wiele smaków systemów Windows, Linux i OS X.

Aby uzyskać dobry przegląd różnych opcji wdrażania, możesz również przeczytać tę stronę:

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

Z powyższego linku:

Możesz utworzyć dwa typy wdrożeń dla aplikacji .NET Core:

Wdrożenie zależne od struktury

Jak sama nazwa wskazuje, wdrażanie zależne od struktury (FDD) opiera się na udostępnionej wersji platformy .NET Core dla całego systemu, która ma być obecna w systemie docelowym. Ponieważ .NET Core jest już obecny, Twoja aplikacja jest również przenośna między instalacjami .NET Core. Twoja aplikacja zawiera tylko własny kod i wszelkie zależności innych firm, które są poza bibliotekami .NET Core. Dyski FDD zawierają pliki dll, które można uruchomić za pomocą narzędzia dotnet z wiersza polecenia. Na przykład dotnet app.dll uruchamia aplikację o nazwie app.

Samodzielne wdrażanie

W przeciwieństwie do FDD, samodzielne wdrażanie (SCD) nie polega na obecności żadnych współdzielonych komponentów w systemie docelowym. Wszystkie składniki, w tym zarówno biblioteki .NET Core, jak i środowisko uruchomieniowe .NET Core, są dołączone do aplikacji i są odizolowane od innych aplikacji .NET Core. Dyski SCD zawierają plik wykonywalny (taki jak app.exe na platformach Windows dla aplikacji o nazwie app), który jest zmienioną nazwą hosta .NET Core specyficznego dla platformy oraz plik .dll (na przykład app.dll), który jest faktyczna aplikacja.

W moim przypadku właśnie zaktualizowałem wszystkie pakiety nuget do ich najnowszych wersji, a nuget zmienił moje odwołanie do pakietu „Microsoft.NETCore.App” na następujące:

"Microsoft.NETCore.App": "1.1.0"

Zmieniłem go z powrotem na następującą formę i wszystko działało dobrze:

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

Żegnajcie 3 godziny mojego życia ....

jeśli wykonasz dotnet new i spojrzysz na wyjściowy plik json projektu, zobaczysz, że monikery uległy zmianie.

Wprowadź zmiany w pliku project.json w następujący sposób:

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

Znalazłem jeden przydatny link z komentarza svicka pod następującą stroną: https://github.com/dotnet/cli/issues/2442

Zauważyłem, że w project.json potrzebujesz następujących elementów. Oto, co było wymagane, aby naprawić mój błąd:

Zależności

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

Ramy

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

Runtime

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

Jeśli planujesz publikowanie w usługach IIS, możesz chcieć dodać środowiska wykonawcze. Zobacz coś w następujący sposób:

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

Oto ogólna wskazówka, która dobrze mi się sprawdziła. Gdy moje rzeczy się psują, czasami tworzę domyślną aplikację ASP.NET Core albo witrynę internetową, albo pusty interfejs API sieci Web, aby sprawdzić zależności w project.json i innych miejscach. W ten sposób często można złapać wiele rzeczy. Powyższe odpowiedzi są na miejscu, ale pomyślałem, że napiszę to tutaj na wypadek, gdyby ktoś chciał oddzielić logikę bardziej w ogólnym formacie szablonu używanym przez ASP.NET Core.

W systemie Windows 7 z VS 2015 rozwiązanie po aktualizacji do netcore 1.1.2 zmieniało plik project.json w następujący sposób:

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

Po zmianie tego zależności zostaną zaktualizowane i viola.