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

WPF-alkalmazás fordítása és összeállítása

A Windows Presentation Foundation (WPF) alkalmazások .NET keretrendszerű végrehajtható fájlokként (.exe), könyvtárakként (.dll), vagy a kettő kombinációjaként hozhatók létre. Ez a témakör bemutatja, hogyan hozhat létre WPF-alkalmazásokat, és ismerteti a buildelési folyamat főbb lépéseit.

WPF-alkalmazás létrehozása

A WPF-alkalmazások a következő módokon állíthatók össze:

  • Parancssor. Az alkalmazásnak csak kódot (XAML nélkül) és alkalmazásdefiníciós fájlt kell tartalmaznia. További információ: parancssori épület csc.exe vagy Épület a parancssorból (Visual Basic).

  • Microsoft Build Engine (MSBuild). A kód- és XAML-fájlok mellett az alkalmazásnak tartalmaznia kell egy MSBuild projektfájlt is. További információ: "MSBuild".

  • Visual Studio. A Visual Studio egy integrált fejlesztői környezet, amely WPF-alkalmazásokat fordít le az MSBuild használatával, és tartalmaz egy vizuális tervezőt a felhasználói felület létrehozásához. További információ: Kód írása és kezelése a Visual Studio használatával, valamint XAML tervezése a Visual Studiohasználatával.

WPF buildfolyamat

A WPF-projekt létrehozásakor a rendszer meghívja a nyelvspecifikus és a WPF-specifikus célok kombinációját. A célok végrehajtásának folyamatát buildelési folyamatnak nevezzük, a fő lépéseket pedig az alábbi ábra szemlélteti.

WPF-buildelési folyamat

Build előtti inicializálások

Az MSBuild az építés előtt meghatározza a fontos eszközök és kódtárak helyét, beleértve a következőket:

  • A .NET-keretrendszer.

  • A Windows SDK-címtárak.

  • A WPF-referenciaszerelvények helye.

  • A szerelvény keresési útvonalainak tulajdonsága.

Az ELSŐ hely, ahol az MSBuild szerelvényeket keres, a referenciaszerelvény könyvtára (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\). Ebben a lépésben a buildelési folyamat inicializálja a különböző tulajdonságokat és elemcsoportokat, és elvégzi a szükséges karbantartási műveleteket.

Hivatkozások feloldása

A buildelési folyamat megkeresi és összeköti az alkalmazásprojekt létrehozásához szükséges szerelvényeket. Ezt a logikát a ResolveAssemblyReference feladat tartalmazza. A projektfájlban Reference-ként deklarált összes szerelvényt a feladat megkapja, a keresési útvonalakkal és a már a rendszeren telepített szerelvények metaadataival együtt. A feladat megkeresi a szerelvényeket, és a telepített szerelvény metaadataival kiszűri azokat az alapvető WPF-szerelvényeket, amelyeknek nem kell megjelennie a kimeneti jegyzékekben. Ez azért történik, hogy elkerülje a ClickOnce-jegyzékek redundáns információit. Például, mivel a PresentationFramework.dll tekinthető egy WPF-en és WPF-re épített alkalmazás reprezentatív példájának, és mivel minden WPF-szerelvény ugyanazon a helyen található minden gépen, ahol a .NET-keretrendszer telepítve van, nem szükséges az összes .NET-keretrendszer referencia-szerelvényről minden információt feltüntetni a jegyzékekben.

Jelölők összeállítása – Első kör

Ebben a lépésben az XAML-fájlok elemzése és fordítása úgy történik, hogy a futtatókörnyezet ne töltsön időt az XML elemzése és a tulajdonságértékek érvényesítése során. A lefordított XAML-fájl előre jogkivonatos, így futásidőben sokkal gyorsabbnak kell lennie, mint egy XAML-fájl betöltése.

Ebben a lépésben a következő tevékenységek történnek minden olyan XAML-fájl esetében, amely egy Page buildelem:

  1. Az XAML-fájlt a korrektúrafordító elemzi.

  2. Az XAML-hez lefordított reprezentáció jön létre, és az obj\Release mappába másolódik.

  3. Létrejön egy új részleges osztály CodeDOM-reprezentációja, és átmásolódik az obj\Release mappába.

Emellett minden XAML-fájlhoz létrehoz egy nyelvspecifikus kódfájlt. Egy Visual Basic-projekt Page1.xaml-lapja esetében például Page1.g.vb jön létre; Egy C#-projekt Page1.xaml-lapja esetén a rendszer létrehoz egy Page1.g.cs. A fájlnévben szereplő ".g" azt jelzi, hogy a fájl olyan kód jön létre, amely részleges osztálydeklarációval rendelkezik a korrektúrafájl legfelső szintű eleméhez (például Page vagy Window). Az osztály deklarálva van a C# partial módosítójával (Extends a Visual Basicben), hogy jelezze, hogy az osztály máshol is deklarálva van, általában a kód mögötti fájlban Page1.xaml.cs.

A részleges osztály a megfelelő alaposztálytól (például egy lap Page) terjed ki, és implementálja a System.Windows.Markup.IComponentConnector felületet. A IComponentConnector felület metódusokkal inicializálhat egy összetevőt, és összekapcsolhatja a tartalmának elemein lévő neveket és eseményeket. Következésképpen a létrehozott kódfájl egy olyan metódus-implementációval rendelkezik, mint a következő:

public void InitializeComponent() {
    if (_contentLoaded) {
        return;
    }
    _contentLoaded = true;
    System.Uri resourceLocater =
        new System.Uri(
            "window1.xaml",
            System.UriKind.RelativeOrAbsolute);
    System.Windows.Application.LoadComponent(this, resourceLocater);
}

Public Sub InitializeComponent() _

    If _contentLoaded Then
        Return
    End If

    _contentLoaded = True
    Dim resourceLocater As System.Uri = _
        New System.Uri("mainwindow.xaml", System.UriKind.Relative)

    System.Windows.Application.LoadComponent(Me, resourceLocater)

End Sub

Alapértelmezés szerint a jelölőnyelv fordítás ugyanabban a AppDomain fut, mint az MSBuild motor. Ez jelentős teljesítménynövekedést biztosít. Ez a viselkedés a AlwaysCompileMarkupFilesInSeparateDomain tulajdonsággal kapcsolható. Ennek az az előnye, hogy az összes referenciaszerelvényt a külön AppDomainkipakolásával távolítja el.

Jelölési összeállítás – Pass 2

Nem minden XAML-oldal van lefordítva a jelölési fordítás első lépése során. Az olyan XAML-fájlok, amelyek helyileg meghatározott típushivatkozásokkal rendelkeznek (a kódban meghatározott típusokra mutató hivatkozások ugyanabban a projektben máshol) jelenleg mentesülnek a fordítás alól. Ennek az az oka, hogy ezek a helyileg meghatározott típusok csak a forrásban léteznek, és még nem lettek lefordítva. Ennek meghatározásához az elemző heurisztikus elemeket használ, amelyek olyan elemeket keresnek, mint például a x:Name a korrektúrafájlban. Ha ilyen példányt talál, a jelölőfájl fordítása el lesz halasztva addig, amíg a kódfájlok le nem fordulnak, ezután a második jelölőfordítási lépés ezeket a fájlokat dolgozza fel.

Fájlbesorolás

A buildelési folyamat különböző erőforráscsoportokba helyezi a kimeneti fájlokat attól függően, hogy melyik alkalmazásszerelvénybe helyezik őket. Egy tipikus nem lokalizált alkalmazásban az Resource jelölt összes adatfájl a fő összeállításba kerül (végrehajtható vagy könyvtár). Ha UICulture be van állítva a projektben, az összes lefordított XAML-fájl és a kifejezetten nyelvspecifikusként megjelölt erőforrások a műholdas erőforrás-szerelvénybe kerülnek. Ezenkívül minden nyelvsemleges erőforrás a fő szerelvénybe kerül. A buildelési folyamat ezen lépésében ez a meghatározás történik.

A projektfájlban található ApplicationDefinition, Pageés Resource buildelési műveletek bővíthetők a Localizable metaadatokkal (az elfogadható értékek true és false), amely meghatározza, hogy a fájl nyelvspecifikus vagy nyelvsemleges-e.

Fő összeállítás

Az alapvető fordítási lépés magában foglalja a kódfájlok fordítását. Ezt a microsoft.CSharp.targets és a Microsoft.VisualBasic.targets nyelvspecifikus célfájlok logikája vezényli. Ha a heurisztika meghatározta, hogy a jelölő fordító egyetlen futtatására van szükség, akkor létrejön a fő összeszerelési egység. Ha azonban a projekt egy vagy több XAML-fájlja helyileg meghatározott típusokra hivatkozik, akkor egy ideiglenes .dll fájl jön létre, így a végleges alkalmazásszerelvények a korrektúra-fordítás második sikeres befejezése után hozhatók létre.

Manifesztum generálása

A buildelési folyamat végén, miután az összes alkalmazásszerelvény és tartalomfájl elkészült, létrejön az alkalmazás ClickOnce-jegyzékfájlja.

Az üzembehelyezési jegyzékfájl a telepítési modellt írja le: az aktuális verziót, a frissítési viselkedést és a közzétevő identitását, valamint a digitális aláírást. Ezt a jegyzékfájlt az üzembe helyezést kezelő rendszergazdáknak szánták. A fájlkiterjesztés .xbap (XAML böngészőalkalmazásokhoz (XBAPs)) és .application a telepített alkalmazásokhoz. Az előbbiet a HostInBrowser projekttulajdonság szabja meg, ezért a jegyzék az alkalmazást böngésző által üzemeltetettként azonosítja.

Az alkalmazásjegyzék (egy .exe.manifest fájl) leírja az alkalmazásszerelvényeket és a függő kódtárakat, valamint felsorolja az alkalmazás által igényelt engedélyeket. Ezt a fájlt az alkalmazás fejlesztőjének kell létrehoznia. ClickOnce-alkalmazás indításához a felhasználó megnyitja az alkalmazás üzembehelyezési jegyzékfájlját.

Ezek a jegyzékfájlok mindig XBAP-khez jönnek létre. A telepített alkalmazások csak akkor jönnek létre, ha a GenerateManifests tulajdonság meg van adva a projektfájlban trueértékkel.

Az XBAP-k két további engedélyt kapnak a tipikus internetzóna-alkalmazásokhoz rendelt engedélyek felett: WebBrowserPermission és MediaPermission. A WPF buildrendszer deklarálja ezeket az engedélyeket az alkalmazásjegyzékben.

Növekményes fordítási támogatás

A WPF buildrendszer támogatja a növekményes buildeket. Meglehetősen intelligens a korrektúra vagy a kód módosításainak észleléséhez, és csak a módosítás által érintett összetevőket fordítja le. A növekményes buildelési mechanizmus a következő fájlokat használja:

  • $(AssemblyName)_MarkupCompiler.Cache fájl az aktuális fordítóállapot fenntartásához.

  • $(AssemblyName)_MarkupCompiler.lref fájl az XAML-fájlok gyorsítótárazásához helyileg meghatározott típusokra mutató hivatkozásokkal.

A növekményes buildet szabályozó szabályok a következők:

  • A fájl a legkisebb egység, amelyben a buildrendszer észleli a változást. Egy kódfájl esetében tehát a buildelési rendszer nem tudja megállapítani, hogy módosították-e a típust, vagy hozzáadták-e a kódot. Ugyanez vonatkozik a projektfájlokra is.

  • A növekményes buildelési mechanizmusnak biztosnak kell lennie abban, hogy egy XAML-oldal vagy osztályt határoz meg, vagy más osztályokat használ.

  • Ha Reference bejegyzései megváltoznak, akkor az összes oldalt újrafordítással végezze el.

  • Ha megváltozik egy kódfájl, fordítsa újra az összes oldalt, amelyek helyileg definiált típushivatkozásokat tartalmaznak.

  • Ha egy XAML-fájl megváltozik:

    • Ha az XAML Page-ként van deklarálva a projektben: ha az XAML nem rendelkezik helyileg meghatározott típushivatkozásokkal, akkor fordítsa újra az XAML-t és az összes XAML-lapot helyi hivatkozásokkal; különben, ha az XAML helyi hivatkozásokkal rendelkezik, az összes XAML-lapot újra kell fordítani helyi hivatkozásokkal.

    • Ha az XAML ApplicationDefinition deklarálva van a projektben: az összes XAML-lap újrafordítása (ok: minden XAML hivatkozik egy Application típusra, amely esetleg megváltozott).

  • Ha a projektfájl XAML-fájl helyett alkalmazásdefinícióként deklarál egy kódfájlt:

    • Ellenőrizze, hogy megváltozott-e a projektfájl ApplicationClassName értéke (van-e új alkalmazástípus?). Ha igen, akkor a teljes alkalmazást újra kell fordítani.

    • Máskülönben az összes XAML-lapot helyi hivatkozásokkal újra kell fordítani.

  • Ha megváltozik egy projektfájl: alkalmazza az összes előző szabályt, és nézze meg, mit kell újrafordíteni. A következő tulajdonságok módosításai teljes újrafordítást váltanak ki: AssemblyName, IntermediateOutputPath, RootNamespaceés HostInBrowser.

A következő újrafordítási forgatókönyvek lehetségesek:

  • A teljes alkalmazás újrafordításra kerül.

  • Csak azok az XAML-fájlok lesznek újra lefordítva, amelyek helyileg definiált típushivatkozásokkal rendelkeznek.

  • Semmi sem lesz újrafordítve (ha a projektben semmi sem változott).

Lásd még

  • Last updated on