1. NET Core kommandolinjegrensesnitt (CLI) verktøy
Foreldet project.json og erstattet den med en .csproj-fil, som project.json ble brukt som prosjektkonfigurasjonsfil i den tidlige .NET-kjernen, og det anslås at Microsoft foreldet den etter å ha oppdaget noen problemer, og MSBuild ble fortsatt brukt som et .net-kompilasjonsverktøy.
MSBuild introduserer:https://docs.microsoft.com/zh-cn ... sbuild?view=vs-2017
Når vi utfører VS-kompilering og generering, hjelper VS oss bare med å kalle MSBuild-verktøyet, noe som betyr at når vi kompilerer .NET-prosjektet, trenger vi ikke installere VS-verktøyet i det hele tatt.
.NET Core CLI-verktøykommandoen er som følger:
.NET kommandolinjeverktøy (2.1.301)
Bruk: dotnet [runtime-options] [path-to-application]
Bruk: dotnet [sdk-options] [kommando] [argumenter] [kommando-alternativer]
path-to-application:
Veien til applikasjonen .dll fil som skal kjøres.
SDK-kommandoer:
new initialiserer .NET-prosjektet.
gjenopprette avhengighetene spesifisert i .NET-prosjektet.
kjør og kjør .NET-prosjektet umiddelbart.
bygg .NET-prosjektet.
publish publiserer et .NET-prosjekt for distribusjon (inkludert kjøretiden).
Testkjører enhetstester ved bruk av testrunneren som er spesifisert i prosjektet.
pakke for å lage en NuGet-pakke.
migrerer project.json-baserte prosjekter til MSBuild-baserte prosjekter.
Ren, ren generert utgang.
SLN Modification Solution (SLN)-fil.
Legg til i referansen.
Fjern fra prosjektet.
List opp verktøyene prosjektet refererer til eller installerer.
NuGet gir flere NuGet-kommandoer.
msbuild kjører Microsoft Build Engine (MSBuild).
vstest kjører kommandolinjeverktøyet Microsoft Test Execution.
Store lagrer den spesifiserte samlingen i runtime-butikken.
verktøy for å installere eller bruke verktøy som utvider .NET-opplevelsen.
Build-Server samhandler med serveren som startes av build-versjonen.
Hjelp viser hjelp.
Vanlige alternativer:
-v|--ordrikdom bestemmer detaljnivået i kommandoen. De tillatte verdiene er Q[UIET], M[inimal], N[Ormal], D[etailed] og diag[nostic].
-H|--Hjelp viser hjelp.
Kjør dotnet-kommandoen – hjelp til å få mer informasjon om kommandoen.
sdk-options:
--versjonen viser versjonen av .NET Core SDK som er i bruk.
--info viser .NET Core-informasjon.
--list-sdks for å vise det installerte SDK-et.
--list-runtimes viser den installerte kjøretiden.
-d|--diagnostikk muliggjør diagnostisk utgang.
runtime-options:
--additionalprobingpath <path> Stien som inneholder probe-policyen og sammensetningen til probe.
--fx-versjonen <version> av den installerte versjonen av det delte rammeverket som skal brukes til å kjøre applikasjonen.
--roll-forward-on-no-candidate-fx "No roll forward to Candidate Shared Framework" er aktivert.
--adderal-deps <path> til stien til andre deps.json-filer.
Ytterligere verktøy ('dotnet [verktøynavn] --hjelp' for mer informasjon):
Dev-sertifikater Opprett og administrer utviklingssertifikater.
ef Entity Framework Core kommandolinjeverktøy.
sql-cache SQL Server cache-kommandolinjeverktøy.
brukerhemmeligheter Administrer utviklingsbrukerhemmeligheter.
se Start en filovervåker som kjører en kommando når filer endres.
2. Samling og utgivelse
Publiser et .NET-prosjekt for distribusjon (inkludert kjøretiden).
dotnet publish
C:\project\dotnet\test1>dotnet publish --help
Bruk: dotnet publish [alternativer]
Alternativer:
-H, --Hjelp viser hjelpeinformasjon.
-o, --output <OUTPUT_DIR> brukes til å plassere utdatakatalogen til det publiserte elementet.
-f, --rammeverk <FRAMEWORK> Målrammen som skal publiseres. Målrammen må spesifiseres i prosjektdokumentet.
-r, --<RUNTIME_IDENTIFIER>runtime-publiser prosjektet for en gitt runtime. Bruk dette når du lager selvstendige distribusjoner. Standardhandlingen er å publisere en app som er avhengig av rammeverket.
-c, --konfigurasjon <CONFIGURATION> brukes til å generere prosjektets konfigurasjon. Standardverdien for de fleste prosjekter er "Debug".
--version-suffiks <VERSION_SUFFIX> definerer verdien av egenskapen $(VersionSuffix) i prosjektet ditt.
--manifest <manifest.xml> Sti til målmanifestfilen som inneholder en liste over pakker som skal kjøres gjennom publiseringssteget.
--nei-bygg ikke bygg prosjektet før publisering. Innebærer --no-restore.
--selvstendige medfølgende applikasjoner publiserer .NET Core-kjøretider, noe som eliminerer behovet for å installere kjøretiden på målmaskinen. Hvis en runtime-identifikator er spesifisert, går den som standard til "true".
--no-restore Ikke utfør en implisitt gjenoppretting mens kommandoen utføres.
-v, --ordrikdom bestemmer detaljnivået på kommandoen. De tillatte verdiene er Q[UIET], M[inimal], N[Ormal], D[etailed] og diag[nostic].
--no-dependencies setter dette flagget til å ignorere prosjekt-til-prosjekt-referanser og kun gjenopprette rotprosjektet.
--tving til å tvinge alle avhengigheter til å løses, selv om den siste gjenopprettelsen har vært vellykket. Dette tilsvarer å slette project.assets.json.
Denne kommandoen publiserer applikasjonen til pub-mappen ved hjelp av Publiser-konfigurasjonen. Internt oversettes denne kommandoen til følgende MSBuild-kall:
Definer målplattformen for applikasjonen din
Lag en tagg i delen av csproj-filen (som brukes til å definere målplattformen for appen din), <PropertyGroup> <RuntimeIdentifiers> og spesifiser deretter runtime-identifikatoren (RID) for hver målplattform. Merk at semikolon også kreves for å skille RID-er. Sjekk Runtime Identifier Catalog for en liste over runtime-identifikatorer.
For eksempel <PropertyGroup> indikerer følgende avsnitt at appen kjører på et 64-bits Windows 10-operativsystem og en 64-bits OS X versjon 10.11-versjon av operativsystemet.
Hvis vi kun ønsker å generere en distribusjon under win10 x64-plattformen, kan vi utføre følgende kommando:
Utdatamappe: C:\project\dotnet\test1\bin\release\netcoreapp2.1\win10-x64\publish, hele mappen har 66M, som er ganske stort, som vist i figuren nedenfor:
Generer release-pakken under centos.7-x64-plattformen, det er 70M, som også er ganske stort, la oss prøve å publisere det på centos 7 for å kjøre det :(.NET Core SDK er ikke installert på CentOS 7-systemer）。
Systeminformasjonen er som følger:
[root@master ~]# uname -a
Linux master 3.10.0-862.el7.x86_64 #1 SMP fre 20. apr 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@master ~]# katt /osv/redhat-release
CentOS Linux-utgivelse 7.6.1810 (Kjerne)
[root@master ~]# mkdir temp
[root@master ~]# cd temp/
[root@master temp]# ./test1
-bash: ./test1: Ikke nok tillatelser
[root@master temp]# CD ..
[root@master ~]# chmod -R 777 temp/
[root@master ~]# cd temp/
[root@master temp]# ./test1
Hallo verden!
[root@master temp]# ekko "http://www.itsvse.com"
http://www.itsvse.com
[root@master midlertidig] #
3、. NET Core Run Identifier
.NET Core RID, RID er en forkortelse for Runtime Identifier. RID-verdier brukes til å identifisere målplattformen applikasjonen kjører på. .NET-pakker bruker dem til å representere plattformspesifikke ressurser i NuGet-pakker. Følgende verdier er eksempler på RID: linux-x64, ubuntu.14.04-x64, win7-x64, eller osx.10.12-x64. For pakker med native avhengigheter spesifiserer RID plattformen hvor pakken kan gjenopprettes.
<RuntimeIdentifier> Du kan sette en RID i elementet i prosjektfilen. Flere RID-er kan defineres som en <RuntimeIdentifiers> liste (adskilt med semikolon) i elementene i en prosjektfil.
RID-er som representerer et spesifikt operativsystem følger vanligvis følgende mønster: [os]. [versjon]-[arkitektur]-[tilleggsforbehold], hvor:
- [OS] er navnet på operativsystemet/plattformsystemet. For eksempel ubuntu.
- [versjon] er OS-versjonen, som er formatert med et prikk (.) versjonsnummer. For eksempel, 15.10. Versjoner bør ikke være markedsføringsutgivelser, da de vanligvis representerer flere separate versjoner av operativsystemet med ulike plattform-API-tilbehør.
- [arkitektur] er prosessorarkitekturen. For eksempel: x86, x64, arm, eller arm64.
- [Tilleggsforbehold] Skiller ytterligere mellom ulike plattformer. For eksempel AOT eller Corert.
Spesifikk introduksjon:https://docs.microsoft.com/zh-cn/dotnet/core/rid-catalog
4、. NET Core lager NuGet-pakker
For .NET Standard og .NET Core bør alle biblioteker utgis som NuGet-pakker. Faktisk er det slik alle .NET-standardbiblioteker publiseres og brukes. Dette kan enkelt oppnås ved hjelp av dotnet pack-kommandoen.
(Slutt)
|
Publisert på 21.01.2019 17:10:26
|
|
|
|
