Megosztás a következőn keresztül:

Egyfájlos üzembe helyezés

Ha az összes alkalmazásfüggő fájlt egyetlen bináris fájlba osztja, az alkalmazásfejlesztő számára vonzó lehetőséget kínál az alkalmazás egyetlen fájlként való üzembe helyezésére és terjesztésére. Az egyfájlos üzembe helyezés a keretrendszertől függő üzemi modellhez és az önálló alkalmazásokhoz is elérhető.

Az önálló alkalmazásokban lévő egyetlen fájl mérete nagy, mivel tartalmazza a futtatókörnyezetet és a keretrendszertárakat. A .NET 6-ban a vágáskompatibilis alkalmazások teljes méretének csökkentése érdekében közzéteheti a levágott elemeket. Az egyetlen fájltelepítési lehetőség kombinálható a ReadyToRun és a Trim közzétételi lehetőségekkel.

Fontos

Egyetlen fájlalkalmazás Windows 7 rendszeren való futtatásához a .NET Runtime 6.0.3 vagy újabb verzióját kell használnia.

Minta projektfájl

Íme egy mintaprojektfájl, amely egyetlen fájl közzétételét határozza meg:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <PublishSingleFile>true</PublishSingleFile>
    <SelfContained>true</SelfContained>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>

</Project>

Ezek a tulajdonságok a következő függvényekkel rendelkeznek:

  • PublishSingleFile. Engedélyezi az egyetlen fájl közzétételét. Emellett lehetővé teszi az egyetlen fájlra vonatkozó figyelmeztetéseket is a .dotnet build
  • SelfContained. Meghatározza, hogy az alkalmazás önálló vagy keretrendszerfüggő-e.
  • RuntimeIdentifier. Megadja a megcélzott operációs rendszert és processzortípust . Emellett alapértelmezés szerint be van kapcsolva <SelfContained>true</SelfContained> .

Az önálló fájlalkalmazások mindig operációs rendszer- és architektúraspecifikusak. Minden konfigurációhoz közzé kell tennie, például Linux x64, Linux Arm64, Windows x64 stb.

A futtatókörnyezet konfigurációs fájljai, például a *.runtimeconfig.json és a *.deps.json, egyetlen fájlban találhatók.

Egyfájlos alkalmazás közzététele

Egyetlen fájlalkalmazás közzététele a dotnet publish paranccsal.

  1. Adja hozzá <PublishSingleFile>true</PublishSingleFile> a projektfájlhoz.

    Ez a módosítás egyetlen fájlalkalmazást hoz létre önálló közzétételhez. Emellett egyetlen fájlkompatibilitási figyelmeztetést is jelenít meg a buildelés során.

    <PropertyGroup>
    <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

  2. Az alkalmazás közzététele egy adott futtatókörnyezet-azonosítóhoz a következő használatával: dotnet publish -r <RID>

    Az alábbi példa a Windowshoz készült alkalmazást önálló önálló fájlalkalmazásként teszi közzé.

    dotnet publish -r win-x64

    Az alábbi példa a Linuxhoz készült alkalmazást egy keretrendszerfüggő egyetlen fájlalkalmazásként teszi közzé.

    dotnet publish -r linux-x64 --self-contained false

<PublishSingleFile> a projektfájlban be kell állítani a fájlelemzés engedélyezéséhez a buildelés során, de az alábbi beállítások argumentumként dotnet publish is megadhatóak:

dotnet publish -r linux-x64 -p:PublishSingleFile=true --self-contained false

További információt a .NET-alkalmazások közzétételi áttekintésében talál.

Fájlok beágyazása kizárása

Bizonyos fájlok kifejezetten kizárhatók az egyetlen fájlba való beágyazásból a következő metaadatok beállításával:

<ExcludeFromSingleFile>true</ExcludeFromSingleFile>

Ha például egyes fájlokat a közzétételi könyvtárba szeretne helyezni, de nem csomagolja őket a fájlba:

<ItemGroup>
  <Content Update="Plugin.dll">
    <CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
    <ExcludeFromSingleFile>true</ExcludeFromSingleFile>
  </Content>
</ItemGroup>

PDF-fájlok belefoglalása a csomagba

A szerelvény PDB-fájlja az alábbi beállítással beágyazható a szerelvénybe (a .dll) is. Mivel a szimbólumok a szerelvény részét képezik, az alkalmazás részét képezik:

<DebugType>embedded</DebugType>

Adja hozzá például a következő tulajdonságot egy szerelvény projektfájljába, hogy beágyazza a PDB-fájlt az adott szerelvénybe:

<PropertyGroup>
  <DebugType>embedded</DebugType>
</PropertyGroup>

Egyéb szempontok

Az egyfájlos alkalmazások az alkalmazás mellett az összes kapcsolódó PDB-fájlt is tartalmazza, alapértelmezés szerint nem kötegelve. Ha pdf-eket szeretne belefoglalni a szerelvénybe az ön által létrehozott projektekhez, állítsa a DebugType következőre embedded: . Lásd: PDF-fájlok belefoglalása a csomagba.

A felügyelt C++ összetevők nem alkalmasak egyetlen fájl üzembe helyezésére. Javasoljuk, hogy az alkalmazásokat C# nyelven vagy más nem felügyelt C++ nyelven írja, hogy egyetlen fájlkompatibilis legyen.

Natív kódtárak

Csak a felügyelt DLL-ek vannak egyetlen végrehajtható fájlba csomagolva az alkalmazással. Az alkalmazás indításakor a rendszer kinyeri és betölti a felügyelt DLL-eket a memóriába, elkerülve a mappa kinyerését. Ezzel a módszerrel a felügyelt bináris fájlok az egyetlen fájlcsomagba vannak beágyazva, de maga a központi futtatókörnyezet natív bináris fájljai különálló fájlok.

A fájlok kinyeréshez való beágyazásához és egy kimeneti fájl lekéréséhez állítsa a tulajdonságot IncludeNativeLibrariesForSelfExtract a következőre true: .

IncludeAllContentForSelfExtract A végrehajtható fájl futtatása előtt adja meg az összes fájlt, beleértve a felügyelt szerelvényeket is. Ez hasznos lehet ritka alkalmazáskompatibilitási problémák esetén.

Fontos

Ha extrakciót használ, a rendszer az alkalmazás elindítása előtt kinyeri a fájlokat a lemezre:

  • Ha a DOTNET_BUNDLE_EXTRACT_BASE_DIR környezeti változó elérési útra van állítva, a rendszer kinyeri a fájlokat az elérési út alatti könyvtárba.
  • Ellenkező esetben, ha Linuxon vagy macOS rendszeren fut, a rendszer kinyeri a fájlokat a következő könyvtárba $HOME/.net: .
  • Ha Windows rendszeren fut, a rendszer kinyeri a fájlokat a következő könyvtárba %TEMP%/.net: .

Az illetéktelen módosítás megakadályozása érdekében ezeket a könyvtárakat nem szabad a különböző jogosultságokkal rendelkező felhasználók vagy szolgáltatások számára írhatóvá tenni. A legtöbb Linux- és macOS-rendszeren ne használja a /tmp vagy a /var/tmp parancsot.

Feljegyzés

Egyes Linux-környezetekben, például az alatt systemd, az alapértelmezett kinyerés nem működik, mert $HOME nincs definiálva. Ilyen esetekben javasoljuk, hogy kifejezetten állítsa be a beállításokat $DOTNET_BUNDLE_EXTRACT_BASE_DIR .

Jó systemdalternatíva, ha a szolgáltatás egységfájljában definiálja DOTNET_BUNDLE_EXTRACT_BASE_DIR a következőt %h/.net, amely systemd megfelelően $HOME/.net kiterjeszthető a szolgáltatást futtató fiókra.

[Service]
Environment="DOTNET_BUNDLE_EXTRACT_BASE_DIR=%h/.net"

API-kompatibilitás

Egyes API-k nem kompatibilisek egyetlen fájltelepítéssel. Előfordulhat, hogy az alkalmazások módosítást igényelnek, ha ezeket az API-kat használják. Ha harmadik féltől származó keretrendszert vagy csomagot használ, lehetséges, hogy ezen API-k valamelyikét használják, és módosítást igényelnek. A problémák leggyakoribb oka az alkalmazással szállított fájlok vagy DLL-ek fájlelérési útvonalától való függőség.

Az alábbi táblázat tartalmazza a futtatókörnyezeti kódtár API-jának részleteit az önálló fájlhasználathoz.

API Feljegyzés
Assembly.CodeBase Dob.PlatformNotSupportedException
Assembly.EscapedCodeBase Dob.PlatformNotSupportedException
Assembly.GetFile Dob.IOException
Assembly.GetFiles Dob.IOException
Assembly.Location Üres sztringet ad vissza.
AssemblyName.CodeBase A visszaadott érték.null
AssemblyName.EscapedCodeBase A visszaadott érték.null
Module.FullyQualifiedName Egy kivétel értékével <Unknown> rendelkező sztringet ad vissza.
Marshal.GetHINSTANCE -1 értéket ad vissza.
Module.Name Egy sztringet ad vissza a következő <Unknown>értékkel: .

Néhány javaslatunk van a gyakori forgatókönyvek megoldására:

Bináris fájlok utófeldolgozása a kötegelés előtt

Egyes munkafolyamatokhoz a bináris fájlok utófeldolgozása szükséges a kötegelés előtt. Gyakori példa az aláírás. A dotnet SDK MSBuild kiterjesztési pontokat biztosít, amelyek lehetővé teszik a bináris fájlok feldolgozását az egyfájlos kötegelés előtt. Az elérhető API-k a következők:

  • Egy cél PrepareForBundle, amelyet GenerateSingleFileBundle előtt hívnak meg.
  • A <ItemGroup><FilesToBundle /></ItemGroup> kötegbe foglalandó összes fájlt tartalmazó fájl
  • Az apphost-sablont megadó tulajdonság AppHostFile . A feldolgozás után előfordulhat, hogy ki szeretné zárni az apphostot a feldolgozásból.

Ennek csatlakoztatásához létre kell hozni egy célfeladatot, amely PrepareForBundle és GenerateSingleFileBundle között lesz végrehajtva.

Fontolja meg a következő .NET-projektcsomópont Target példáját:

<Target Name="MySignedBundledFile" BeforeTargets="GenerateSingleFileBundle" DependsOnTargets="PrepareForBundle">

Előfordulhat, hogy az eszközöknek fájlokat kell másolniuk az aláírás során. Ez akkor fordulhat elő, ha az eredeti fájl egy megosztott elem, amely nem a build tulajdonában van, például a fájl egy NuGet-gyorsítótárból származik. Ilyen esetben az eszköz várhatóan módosítja a megfelelő FilesToBundle elem elérési útját, hogy a módosított másolatra mutasson.

Szerelvények tömörítése egyfájlos alkalmazásokban

Az egyfájlos alkalmazások a beágyazott szerelvényeken engedélyezett tömörítéssel hozhatók létre. Állítsa be a tulajdonságot a EnableCompressionInSingleFile következőre true: . A létrehozott egyetlen fájlban az összes beágyazott szerelvények tömörítve vannak, ami jelentősen csökkentheti a végrehajtható fájl méretét.

A tömörítés teljesítményköltséggel jár. Az alkalmazás indításakor a szerelvényeket memóriába kell bontani, ami némi időt vesz igénybe. Javasoljuk, hogy használat előtt mérje meg a tömörítés engedélyezésének méretváltozási és indítási költségeit is. A hatás jelentősen eltérhet a különböző alkalmazásoktól.

Egy fájlból álló alkalmazás vizsgálata

Az önálló fájlalkalmazások az ILSpy eszközzel vizsgálhatók. Az eszköz megjelenítheti az alkalmazásba csomagolt összes fájlt, és megvizsgálhatja a felügyelt szerelvények tartalmát.

Lásd még

  • Last updated on