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 közzéteheti a vágott változatot, hogy csökkentse a vágáskompatibilis alkalmazások teljes méretét. 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 projekt fá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ó 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 kizárása a beágyazásból

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ó magába a szerelvénybe (.dll). 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

Fontos

Az IIS nem támogatja ASP.NET Core-alkalmazások üzemeltetését, amelyek egyfájlos üzembe helyezést használnak a folyamatban lévő üzemeltetési modellel. Ha ASP.NET Core-alkalmazást üzemeltet az IIS-ben, tegye közzé az alkalmazást a standard mappatelepítési modellel, vagy használja inkább a folyamaton kívüli üzemeltetési modellt. További információ: Host ASP.NET Core on Windows with IIS.

Az egyfájlos alkalmazásoknál az összes kapcsolódó PDB-fájl az alkalmazás mellett található, alapértelmezés szerint nem egy csomagban. Ha PDB-ket szeretne belefoglalni az assembly-be az ön projektekhez, állítsa a DebugType-t a 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: .

A IncludeAllContentForSelfExtract paraméter megadása kicsomagolja az összes fájlt, beleértve a felügyelt szerelvényeket is, a végrehajtható fájl futtatása előtt. 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.

Megjegyzé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 .

Egy jó systemd alternatíva, ha a szolgáltatás egységfájljában definiálja a DOTNET_BUNDLE_EXTRACT_BASE_DIR, amely %h/.net megfelelően kibővíthető systemd a szolgáltatást futtató fiók számára.

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

API-inkompatibilitá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 Megjegyzés
Assembly.CodeBase Kivételt dob.PlatformNotSupportedException
Assembly.EscapedCodeBase Kivételt dob.PlatformNotSupportedException
Assembly.GetFile Kivételt dob.IOException
Assembly.GetFiles Kivételt dob.IOException
Assembly.Location Üres sztringet ad vissza.
AssemblyName.CodeBase Visszaadja null.
AssemblyName.EscapedCodeBase Visszaadja null.
Module.FullyQualifiedName Visszaad egy sztringet a <Unknown> értékével, vagy kivételt dob.
Marshal.GetHINSTANCE -1 értéket ad vissza.
Module.Name Egy karakterláncot ad vissza, amelynek értéke: <Unknown>.

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

Bináris fájlok utófeldolgozása a csomagolá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 EnableCompressionInSingleFile tulajdonságot true értékre. 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