2017-01-06 33 views
6

Mam program, który próbuję przenieść do .NET Standard/Core. Interfejs wiersza poleceń do biblioteki jest zbudowany z docelową strukturą netcoreapp1.0. Próbowałem wysłać to do testera (z innym systemem operacyjnym), który miał zainstalowany tylko .NET Core 1.1. Program nie działa i podaje błąd:.NET Core 1.0 aplikacja nie będzie działać na systemie .NET Core 1.1

The specified framework 'Microsoft.NETCore.App', version '1.0.1' was not found. 
- Check application dependencies and target a framework version installed at: 
    /usr/share/dotnet/shared/Microsoft.NETCore.App 
- The following versions are installed: 
    1.1.0 
- Alternatively, install the framework version '1.0.1'. 

Czy to jest oczekiwane? Jak rozumiem, każda wersja Core/Standard była ścisłym nadzorem poprzedniego. W związku z tym spodziewałem się, że program ukierunkowany na 1.0 będzie nadal działał na systemie z wersją 1.1, a nie będzie wymagał wielu celów dla każdej wersji instalacyjnej.

Ogólnie rzecz biorąc, w jaki sposób mogę skonfigurować ustawienia, aby nie martwić się o to, że później pojawi się nowsza wersja .NET Core, która nie będzie w stanie uruchomić programu?

+3

'1.1.0'! =' 1.0.1' –

Odpowiedz

2

Musisz zrozumieć kilka innych pojęć.

  1. Aplikacja .NET Core staje się samodzielna, jeśli prawidłowo używasz dotnet publish. Następnie na komputerze docelowym, na którym nie ma zainstalowanego .NET Core (lub wersji, na której opiera się), aplikacja może działać bez problemów. Na podstawie Twojego opisu prawdopodobnie zapomniałeś o tym lub nie próbujesz opublikować tej aplikacji.

  2. Jeśli Twoim celem jest przeniesienie kodu opartego na .NET Core 1.0.1 na inny komputer, a na komputerze jest zainstalowany tylko 1.1.0, powinieneś być w stanie uruchomić skrypt dotnet-install, aby zainstalować wymagane środowisko uruchomieniowe,

https://docs.microsoft.com/en-us/dotnet/articles/core/preview3/tools/dotnet-install-script

Ponieważ używasz Visual Studio 2017 RC już, należy wiedzieć, że .NET Rdzeń 1.0.x teraz powinno być 1.0.3. Obsługa wersji 1.0.0-1.0.2 wygasła.

+0

1.0.1 był domyślny dla narzędzia preview4, które jest jedyną wersją pakietu SDK do obsługi projektów .csproj w tej chwili (preview3 nie jest już dostępny). Na szczęście odkryłem, że preview4 nadal może tworzyć 1.1.0 (jak również 1.0.3, itp., Używając odpowiedniego pakietu nuget), i poprzez szereg eksperymentów z tym zdecydowałem się po prostu opublikować program jako 1.1 . Nie rozwiązuje problemu "Czy uruchomi się po wydaniu wersji 1.2 i to jest jedyna wersja zainstalowana na komputerze docelowym?", Ale mogę ją odłożyć na razie. – dsmith

2

Brakuje pliku global.json. Dodaj jeden do swojego projektu, aby aplikacja wiedziała o rozruchu przy użyciu środowiska wykonawczego 1.0.0, a nie 1.1.

+0

Rodzaj dźwięków jak to, czego potrzebuję, ale nie całkiem. Buduję w VS 2017 (powinienem o tym wspomnieć), co oznacza, że ​​używam .csproj/msbuild, a nie project.json/global.json. It * to * generuje [nazwa projektu] .runtimeconfig.json w katalogu publikowania, który określa wersję do uruchomienia, i działa lokalnie w wersji 1.0.0/1.0.1/1.0.2/1.0.3, ale nie w wersji 1.0. 4 (tak, jak oczekiwano dla linii 1.0). Jednak nie uruchomi docelowego 1.0.4 w wersji 1.1.0. – dsmith

+1

@dsmith Nie testowałem tego, ale jestem dość pewny, że nawet w VS2017 i formacie csproj, global.json jest nadal używany do określenia wersji SDK. global.json i project.json to nie to samo. – Kushan

+0

To prawda, ale plik global.json określa, który zestaw narzędzi do budowania ma być używany, a nie jakikolwiek element środowiska wykonawczego. Ponieważ mam projekty .csproj, jedynymi prawidłowymi narzędziami dla mnie są te z podglądem4, które obsługują tylko .csproj (preview3 również by działało, ale nie mam zainstalowanej żadnej z tych wersji). Wszystkie narzędzia preview2 obsługują tylko project.json, co oznacza, że ​​w ogóle nie będą działać. Ponieważ są to jedyne dostępne opcje, nie ma nic, co mógłbym zmienić w global.json, co miałoby znaczenie. Wciąż jednak było się przydać, żeby się w nim zagłębić. – dsmith