1. Narzędzie do interfejsu wiersza poleceń NET Core (CLI)
Wycofał project.json i zastąpił go plikiem .csproj, który project.json był używany jako plik konfiguracyjny projektu we wczesnym rdzeniu .NET i szacuje się, że Microsoft wycofał go po wykryciu pewnych problemów, a MSBuild nadal był używany jako narzędzie do kompilacji .net.
MSBuild przedstawia:https://docs.microsoft.com/zh-cn ... sbuild?view=vs-2017
Kiedy wykonujemy kompilację i generowanie VS, VS po prostu pomaga nam wywołać narzędzie MSBuild, co oznacza, że przy kompilacji projektu .NET nie musimy wcale instalować narzędzia VS.
Polecenie narzędzia .NET Core CLI wygląda następująco:
.NET Command Line Tools (2.1.301)
Użycie: dotnet [opcje uruchomieniowe] [ścieżka do aplikacji]
Użycie: dotnet [sdk-options] [command] [argumenty] [command-options]
path-to-application:
Ścieżka do aplikacji .dll plik do wykonania.
Polecenia SDK:
new inicjuje projekt .NET.
przywróć zależności określone w projekcie .NET.
natychmiast uruchom i wykonaj projekt .NET.
Buduj projekt .NET.
publish publikuje projekt .NET do wdrożenia (wliczając runtime).
Test wykonuje testy jednostkowe z użyciem testowego runnera określonego w projekcie.
aby stworzyć pakiet NuGet.
migracja projektów opartych na project.json na projekty oparte na MSBuild.
Czysty, czysty generowany wynik.
Plik SLN Modification Solution (SLN).
Dodaj do źródła.
Usuń z projektu.
Wypisz narzędzia, do których projekt się odwołuje lub które instaluje.
NuGet udostępnia dodatkowe polecenia NuGet.
msbuild działa na Microsoft Build Engine (MSBuild).
vstest uruchamia narzędzie Microsoft Test Execution w linii poleceń.
Magazyn przechowuje określony zespół w magazynie runtime.
narzędzia do instalacji lub używania narzędzi, które rozszerzają doświadczenie .NET.
Build Server wchodzi w interakcję z serwerem uruchomionym przez wersję build.
Pomoc to pomoc.
Typowe opcje:
-v|--rozwlekłość określa poziom szczegółowości polecenia. Dozwolone wartości to Q[UIET], M[inimal], N[Ormal], D[etailed] oraz diag[nostic].
-H|--pomoc to pomoc.
Uruchom polecenie dotnet — pomóż uzyskać więcej informacji o poleceniu.
sdk-options:
--wersja pokazuje wersję używanego .NET Core SDK.
--info wyświetla informacje o rdzeniu .NET.
--list-sdks do wyświetlania zainstalowanego SDK.
--list-runtimes pokazuje zainstalowany czas działania.
-d|--diagnostyka umożliwia wynik diagnostyki.
runtime-options:
--additionalprobingpath <path> Ścieżka zawierająca politykę i montaż sondy do sondy.
--<version>fx-wersja zainstalowanej wersji współdzielonego frameworka, która będzie używana do uruchomienia aplikacji.
--roll-forward-on-no-candidate-fx "No Roll Forward to Candidate Shared Framework" jest włączone.
--dodatkowe-dep <path> do ścieżki do innych plików deps.json.
Dodatkowe narzędzia ('dotnet [tool-name] --help' dla więcej informacji):
Certyfikaty deweloperskie Tworzą i zarządzają certyfikatami deweloperskimi.
ef narzędzia wiersza poleceń Entity Framework Core.
sql-cache SQL Server cache narzędzia wiersza poleceń.
sekrety użytkownika Zarządzaj sekretami użytkownika w programie.
watch. Uruchom obserwator plików, który uruchamia polecenie po zmianie plików.
2. Kompilacja i wydanie
Publikuj projekt .NET do wdrożenia (w tym czas działania).
dotnet publish
C:\project\dotnet\test1>dotnet publish --help
Użycie: dotnet publish [opcje]
Opcje:
-H, --help wyświetla informacje o pomocy.
-o, --output <OUTPUT_DIR> służy do umieszczenia katalogu wyjściowego opublikowanego elementu.
-f, --ramy <FRAMEWORK> Docelowe ramy do publikacji. Ramy docelowe muszą być określone w dokumencie projektu.
-r, --<RUNTIME_IDENTIFIER>Runtime publikuj projekt dla danego czasu wykonywania. Używaj tego przy tworzeniu samodzielnych wdrożeń. Domyślną akcją jest opublikowanie aplikacji zależnej od frameworka.
-c, --konfiguracja <CONFIGURATION> jest używana do generowania konfiguracji projektu. Domyślną wartością dla większości projektów jest "Debug".
--version-suffix <VERSION_SUFFIX> definiuje wartość właściwości $(VersionSuffiks) w Twoim projekcie.
--manifest <manifest.xml> Ścieżka do docelowego pliku manifestu zawierającego listę pakietów do wykonania w kroku publikacji.
--no-build nie buduj projektu przed publikacją. Oznacza --brak przywracania.
--samodzielne aplikacje towarzyszące publikują środowiska uruchomienia .NET Core, eliminując konieczność instalowania runtime na docelowej maszynie. Jeśli podano identyfikator w czasie rzeczywistym, domyślnie przyjmuje się "true".
--no-restore Nie wykonuj niejawnego przywracania podczas wykonywania polecenia.
-v, --rozwlekłość określa poziom szczegółowości polecenia. Dozwolone wartości to Q[UIET], M[inimal], N[Ormal], D[etailed] oraz diag[nostic].
--no-dependencies ustawia tę flagę, aby ignorować odwołania między projektami i przywracać jedynie projekt główny.
--wymuszać wymuszanie rozwiązania wszystkich zależności, nawet jeśli ostatnie przywrócenie zakończyło się sukcesem. To jest równoważne z usuwaniem project.assets.json.
To polecenie publikuje aplikację do folderu pub za pomocą konfiguracji Publish. Wewnętrznie to polecenie tłumaczy się na następujące wywołanie MSBuild:
Określ docelową platformę dla swojej aplikacji
Utwórz tag w sekcji pliku csproj (która służy do definiowania docelowej platformy dla Twojej aplikacji), <PropertyGroup> <RuntimeIdentifiers> a następnie określ identyfikator czasowy (RID) dla każdej platformy docelowej. Należy zauważyć, że do rozdzielania RID wymagane są także średniki. Sprawdź katalog identyfikatorów runtime, aby znaleźć listę identyfikatorów runtime.
Na przykład <PropertyGroup> poniższa sekcja wskazuje, że aplikacja działa na 64-bitowym systemie operacyjnym Windows 10 oraz 64-bitowej wersji OS X 10.11.
Jeśli chcemy wygenerować dystrybucję tylko poniżej platformy win10 x64, możemy wykonać następujące polecenie:
Folder wyjściowy: C:\project\dotnet\test1\bin\release\netcoreapp2.1\win10-x64\publish, cały folder ma 66M, co jest dość duże, jak pokazano na poniższym rysunku:
Wygeneruj pakiet wydania na platformie centos.7-x64, jest 70M, co również jest dość duże, spróbujmy opublikować go na CentOS 7, aby go uruchomić (SDK .NET Core nie jest zainstalowany na systemach CentOS 7）。
Informacje o systemie są następujące:
[root@master ~]# uname -a
Linux master 3.10.0-862.el7.x86_64 #1 SMP pt kwi 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@master ~]# kot /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
[root@master ~]# mkdir temp
[root@master ~]# temperatura płyty CD/
[root@master temperatura]# ./test1
-bash: ./test1: Za mało uprawnień
[root@master temp]# CD..
[root@master ~]# chmod -R 777 temp/
[root@master ~]# temperatura płyty CD/
[root@master temperatura]# ./test1
Cześć ludzie!
[root@master temp]# echo "http://www.itsvse.com"
http://www.itsvse.com
[root@master temperatura] #
3、. Identyfikator Run NET Core
.NET Core RID, RID to skrót od Runtime Identifier (Runtime Identifier). Wartości RID są używane do identyfikacji platformy docelowej, na której działa aplikacja. Pakiety .NET używają ich do reprezentowania zasobów specyficznych dla platformy w pakietach NuGet. Poniższe wartości są przykładami RID: linux-x64, ubuntu.14.04-x64, win7-x64 lub osx.10.12-x64. Dla pakietów z natywnymi zależnościami RID określa platformę, na której można je przywrócić.
Możesz <RuntimeIdentifier> ustawić RID w elemencie pliku projektu. Wiele RID-ów można zdefiniować jako <RuntimeIdentifiers> listę (oddzieloną średnikami) w elementach pliku projektu.
RID-y reprezentujące konkretny system operacyjny zazwyczaj podążają następującym wzorcem: [os]. [wersja]-[architektura]-[dodatkowe zastrzeżenia], gdzie:
- [OS] to nazwa systemu operacyjnego/platformowego. Na przykład Ubuntu.
- [version] to wersja operacyjna, sformatowana kropką (.) numerem wersji. Na przykład 15.10. Wersje nie powinny być wydaniami marketingowymi, ponieważ zazwyczaj reprezentują wiele odrębnych wersji systemu operacyjnego z różnymi peryferiami API platformy.
- [architektura] to architektura procesora. Na przykład: x86, x64, arm lub arm64.
- [dodatkowe doprecyfikaty] dalsze rozróżnienie między różnymi platformami. Na przykład AOT lub Corert.
Szczegółowe wprowadzenie:https://docs.microsoft.com/zh-cn/dotnet/core/rid-catalog
4、. NET Core tworzy pakiety NuGet
Dla .NET Standard i .NET Core wszystkie biblioteki powinny być wydane jako pakiety NuGet. W rzeczywistości właśnie tak publikowane i używane są wszystkie biblioteki standardowe .NET. Można to łatwo osiągnąć za pomocą polecenia dotnet pack.
(Koniec)
|
Opublikowano 21.01.2019 17:10:26
|
|
|
|
