Building a WPF Application (WPF)

Os aplicativos Windows Presentation Foundation (WPF) podem ser criados como bibliotecas (.dll), executáveis (.exe) .NET Framework, ou uma combinação de ambos os tipos de conjuntos de módulos (assemblies). Este tópico inicialmente mostra como criar aplicativos WPF simples a partir do prompt de comando, antes de mostrar como WPF aproveita a extensibilidade de Mecanismo de compilação Microsoft (MSBuild) para criar aplicativos mais complexos. Para concluir, este tópico fornece uma discussão detalhada sobre as principais etapas no processo de compilação de MSBuild.

Este tópico contém as seguintes seções.

• Criando um aplicativo WPF por meio de compilação na linha de comando
• Criando um aplicativo WPF usando MSBuild
• Arquivos de projeto MSBuild para WPF
• Criando um projeto do MSBuild para WPF usando Visual Studio
• Compilando um projeto do MSBuild para WPF
• Linha de produção da compilação em Windows Presentation Foundation
• Suporte a compilação incremental
• Tópicos relacionados

Criando um aplicativo WPF por meio de compilação na linha de comando

Um aplicativo WPF escrito inteiramente em código (nenhuma marcação) pode ser criado com um compilador de linha de comando. Por exemplo, considere um aplicativo WPF C# autônomo que inclui os seguintes arquivos de código-fonte:

• Um arquivo de definição de aplicativo (app.cs).

• Uma janela (mainwindow.cs).

Este aplicativo pode ser compilado usando o compilador C#, csc.exe, a partir de um prompt de comando, como no exemplo a seguir:

csc.exe
  /out:WPFApplication.exe
  /target:winexe 
  app.cs mainwindow.cs 
  /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\presentationframework.dll" 
  /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\windowsbase.dll" 
  /reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\presentationcore.dll"

Nesse exemplo:

• O parâmetro /out especifica o nome do assembly executável interno (WPFApplication.exe).

• O parâmetro /target especifica o tipo de assembly que é compilado (um executável Microsoft Windows).

• Os arquivos de código-fonte C# que compõem o aplicativo (app.cs e mainwindow.cs)

• O parâmetro /reference que identifica os assemblies referenciados que implementam os tipos usados pelo aplicativo.

Compilação por linha de comando pode ser usada para criar aplicativos com mais complexidade, embora o compilador não suporte aplicativos WPF que incluam código-fonte em Extensible Application Markup Language (XAML). Além disso, compilação por linha de comando não tem suporte para a gama completa de requisitos de compilação de aplicativos WPF típicos, incluindo gerenciamento de configuração e geração de manifesto ClickOnce. Para dar suporte a esses e outros requisitos de criação mais complexos, WPF integra-se com e estende MSBuild.

Observação:
Para obter mais informações sobre o comando - linha de compilação, consulte Linha de comando criando com csc.exe ou Criando a partir da linha de comando (Visual Basic).

Criando um aplicativo WPF usando MSBuild

MSBuild é uma tecnologia robusta e extensível que foi introduzida com o .NET Framework. O núcleo da tecnologia MSBuild é implementado através dos conjuntos de módulos (assemblies) que são descritos na tabela a seguir.

Assembly	Descrição
Microsoft.Build.Engine.dll	Lê e processa arquivos de projeto MSBuild.
Microsoft.Build.Tasks.dll	Implementa funcionalidade que é comum a todos os projetos MSBuild, incluindo a chamada ao compilador de linha de comando (por exemplo, csc.exe para C#, vbc.exe para Visual Basic).
Microsoft.Build.Utilities.dll	Expõe classes-utilitário que estendem MSBuild com funcionalidades personalizadas de compilação.
Microsoft.Build.Framework.dll	Implementa as interfaces que definem como funcionalidades de MSBuild interagem com o mecanismo de MSBuild.
Microsoft.Build.Conversion.dll	Oferece suporte à conversão de arquivos de projeto no formato antigo Microsoft Visual Studio .NET 2002 e Microsoft Visual Studio .NET 2003 para o formato do MSBuild em Microsoft Visual Studio 2005.

Observação:
Para obter mais informações sobre o MSBuild assemblies, consulte Referência do MSBuild.

Arquivos de projeto MSBuild para WPF

Os assemblies que compõem o MSBuild são conhecidos pelo nome de "mecanismo de MSBuild". Para compilar aplicativos, o mecanismo de MSBuild normalmente exige as seguintes informações:

• Referências dos arquivos de código-fonte.

• Referências de assemblies dependentes.

• Detalhes de configuração.

• Requisitos de compilação.

Para que sejam processados pelo MSBuild, essas informações são empacotadas em arquivos XML que estão de acordo com o esquema personalizado do MSBuild (consulte Referência de esquema do arquivo de projeto do MSBuild). Esses arquivos são conhecidos como "arquivos de projeto MSBuild". A seguir, encontra-se o arquivo de projeto MSBuild de uma versão do aplicativo WPF que nós criamos anteriormente com um compilador de linha de comando, acrescido de arquivos de código-fonte Extensible Application Markup Language (XAML).

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     <PropertyGroup>
         <AssemblyName>WPFApplication</AssemblyName>
         <OutputType>winexe</OutputType>
     </PropertyGroup>
     <ItemGroup>
         <Reference Include="System" />
         <Reference Include="WindowsBase" />
         <Reference Include="PresentationCore" />
         <Reference Include="PresentationFramework" />
     </ItemGroup>
     <ItemGroup>
         <ApplicationDefinition Include="App.xaml" />
         <Compile Include="App.xaml.cs" />
         <Page Include="MainWindow.xaml" />
         <Compile Include="MainWindow.xaml.cs" />
     </ItemGroup>
     <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
     <Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />
</Project>

Este exemplo contém os elementos que são comuns para a maioria dos arquivos de projeti MSBuild, incluindo a marca Project, propriedades , items, destinos e tarefas.

O elemento do projeto

Conforme especificado pelo esquema de arquivo de projeto MSBuild, um arquivo de projeto MSBuild é um arquivo XML com Project como o elemento de nível superior:

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     ...
</Project>

O elemento Project é onde o mecanismo MSBuild começa a processar uma arquivo de projeto. Para especificar a versão do MSBuild para a qual o arquivo de projeto MSBuild se destina, é fornecida uma declaração de namespace XML adequada.

Propriedades

As propriedades são variáveis que são usadas para configurar projetos MSBuild e fornecem informações específicas à compilação para o mecanismo MSBuild. As propriedades estão contidas em elementos PropertyGroup, como mostrado no exemplo o seguir.

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     <PropertyGroup>
         <AssemblyName>WPFApplication</AssemblyName>
         <OutputType>winexe</OutputType>
     </PropertyGroup>
     ...
</Project>

Algumas propriedades (p.ex., AssemblyName e OutputType) são comuns a todos os tipos de aplicativos e são descritas em Propriedades de projeto MSBuild ComComumComum. As propriedades MSBuild que são específicas a WPF estão listadas na tabela a seguir.

Propriedade	Descrição
OutputType	Especifica o tipo de conjunto de módulos (assembly) que é criado, e é um dos seguintes valores: winexe: Cria um assembly executável (.exe). Aplicativos autônomos e XBAPs são configurados com esse tipo de saída. library Cria um assembly de biblioteca (.dll). Assemblies compartilhados e bibliotecass de controle personalizado são configurados com esse tipo de saída.
HostInBrowser	Especifica se um aplicativo WPF é hospedado em um navegador, e é um dos seguintes valores: true: Cria uma XBAP, que inclui o assembly principal de aplicativos (.exe), um manifesto de implantação (applicationName.xbap), e um manifesto de aplicativo (applicationName.exe.manifest). false: Cria um aplicativo autônomo. Se HostInBrowser é true, OutputType deve ser winexe.
Install	Especifica se um XBAP é instalado no cliente. Install pode ser uma true ou false, e o valor oposto HostInBrowser.
GenerateManifests	Especifica se um aplicativo autônomo é publicado usando implantação ClickOnce, e é um dos seguintes valores: true: Cria o aplicativo executável principal, um manifesto de implantação (applicationName.application), e um manifesto de aplicativo (applicationName.exe.manifest). false: Cria apenas o aplicativo executável (.exe). GenerateManifests é usado somente quando Install possui um valor de true.
UICulture	Especifica o local para o qual o assembly será criado. Quando especificado, arquivos declarados como itens de projeto Resource e recursos específicos do idioma são compilados em um assembly satélite para a localidade desejada. Conteúdo neutro ao idioma, por outro lado, é compilado no assembly principal. Por padrão, os aplicativos não são localizados, e os arquivos de recurso, consequentemente, são incorporados no assembly principal. Observação: Quando UICulture é conjunto, o recurso neutro de linguagem deve ser especificado usando o NeutralResourcesLanguageAttribute. Esse atributo deve ser adicionado ao arquivo AssemblyInfo de um aplicativo WPF.

Itens

Os itens são entradas para MSBuild que são processadas pelo mecanismo MSBuild durante o processo de compilação. Os itens estão contidos em um elemento ItemGroup.

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     ...
     <ItemGroup>
         <Reference Include="System" />
         <Reference Include="WindowsBase" />
         <Reference Include="PresentationCore" />
         <Reference Include="PresentationFramework" />
     </ItemGroup>
     <ItemGroup>
         <ApplicationDefinition Include="App.xaml" />
         <Compile Include="App.xaml.cs" />
         <Page Include="MainWindow.xaml" />
         <Compile Include="MainWindow.xaml.cs" />
     </ItemGroup>
     ...
</Project>

Tipo do item pode ser configurado com metadados; no exemplo anterior, referências de assembly são configuradas sistema autônomo Reference itens e arquivos de código-fonte são configurados sistema autônomo Compile itens. Reference e Compile são comuns a todos os itens .NET Framework aplicativos e são descritos posteriormente na Itens de projeto MSBuild ComComumComum.

Os itens MSBuild específicos para WPF são listados na tabela a seguir.

Propriedade	Descrição
ApplicationDefinition	Identifica o XAML arquivo de marcação que contém a definição de aplicativo (uma XAML elemento cujo raiz é o arquivo de marcação Application). ApplicationDefinition é obrigatório quando Install é true e OutputType é winexe. Um aplicativo WPF e, consequentemente, um projeto MSBuild só pod ter um ApplicationDefinition.
Page	Identifica um XAML arquivo de marcação cujo conteúdo é convertido em um formato binário e compilado em um assembly. Page itens são geralmente implementados em conjunto com uma classe code-behind. Os itens Page mais comuns são arquivos XAML cujos elementos de nível superior são uma das seguintes opções: Window (System.Windows.Window). Page (System.Windows.Controls.Page). PageFunction (System.Windows.Navigation.PageFunction<T>). ResourceDictionary (System.Windows.ResourceDictionary). FlowDocument (System.Windows.Documents.FlowDocument). UserControl (System.Windows.Controls.UserControl).
Resource	Identifica um arquivo de recurso que é compilado em um assembly de aplicativo. Como mencionado anteriormente, UICulture processa itens de Resource.
Content	Identifica um arquivo de conteúdo que é distribuído com um aplicativo. Os metadados que descrevem o arquivo de conteúdo são compilados no aplicativo (usando AssemblyAssociatedContentFileAttribute).
SplashScreen	Identifica um arquivo de imagem que é usado para a janela de inicialização do aplicativo. O assembly PresentationBuildTasks gera código para App.g.cs ou Application.g.vb cria um SplashScreen instância e exibe-o enquanto o aplicativo é carregado. Este item está disponível a partir de Visual Studio 2008 SP1.

Destinos

Destinos determinam como os projetos são compilados e dependem tanto de propriedades quando de itens. Um aplicativo WPF deve ter um destino específico de linguagem e um destino específico de WPF.

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     ...
     <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
     <Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />
</Project>

Destinos são arquivos separados que terminam com a extensão .targets. Os arquivos de destino que estão incluídos com .NET Framework são instalados no seguinte local:

%WINDIR%\Microsoft.NET\Framework\vX.X.X

O destino específico da linguagem compila código-fonte específico da linguagem. The language-specific target for C# is Microsoft.CSharp.targets and Microsoft.VisualBasic.targets for Visual Basic. Esses dois destinos derivam e estendem o destino Microsoft.Common.targets, que executa a maior parte do trabalho de compilação comum e independente de linguagem. Para mais informações sobre destinos MSBuild comuns e específicos de linguagem, consulte O MSBuild .Targets arquivos.

Trabalho de compilação específico de WPF é executado pelo destino Microsoft.WinFX.targets. Este trabalho inclui compilação da marcação XAML, geração de manifestos para aplicativos XBAP, e processamento de arquivos de conteúdo e recursos WPF.

Tarefas

Uma tarefa é uma classe que executa uma ação de compilação específica. Uma ou mais tarefas são combinadas por destinos para definir um processo de compilação; quando MSBuild processa um destino, ele executa as tarefas que são contidas pelo destino. As tarefas que são usadas por destinos comuns e específicos de linguagem são implementadas pelo assembly de Microsoft.Build.Tasks, e as tarefas que são específicas para WPF são implementadas pelo assembly PresentationBuildTasks.

Destinos fornecem o suporte para compilar todos os aplicativos WPF padrão. Também é possível usar combinações alternativas de tarefas para implementar comportamento personalizado de compilação. Por exemplo, a seguinte tarefa MSBuild GetWinFXPath é usada para detectar o caminho nativo para o ambiente de execução .NET Framework, que depende do fato de a tarefa estar executando em um processador de 64 bits:

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
     <UsingTask 
         TaskName="Microsoft.Build.Tasks.Windows.GetWinFXPath" 
         AssemblyFile="C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationBuildTasks.dll" />
     <Target Name="GetWinFXPathTask">
         <GetWinFXPath
             WinFXNativePath="c:\DOTNet3Native" 
             WinFXWowPath="c:\DOTNet3WowNative" />
     </Target>
     <Import Project="$(MSBuildBinPath)\Microsoft.WinFX.targets" />
</Project>

Para mais informações sobre as tarefas MSBuild comuns, consulte Referência de tarefas do MSBuild.

Exemplos de projetos MSBuild para Windows Presentation Foundation

O Windows Software Development Kit (SDK) inclui vários exemplos de arquivos de projeto MSBuild para os tipos mais comuns de aplicativos WPF:

• Como: Criar um arquivo de exemplo do projeto para um aplicativo autônomo do Windows Presentation Foundation

• Como: Criar um arquivo de exemplo do projeto para um aplicativo de navegação autônomo do Windows Presentation Foundation

• Como: Criar um arquivo de exemplo do projeto para um aplicativo Windows Presentation Foundation XAML navegador

• Como: Criar um arquivo de projeto exemplo para uma biblioteca de controle personalizada do Windows Presentation Foundation

• Como: Criar um arquivo de exemplo do projeto para um somente código de aplicativo do Windows Presentation Foundation autônomo

Criando um projeto do MSBuild para WPF usando Visual Studio

Visual Studio gera automaticamente arquivos de projeto MSBuild quando novos aplicativos WPF são criados usando os modelos de projeto Visual Studio. Por exemplo, o modelo de projeto de Aplicativo WPF gera o seguinte arquivo de projeto (para C#):

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <ProductVersion>9.0.20726</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{E0EA3EBA-718C-4122-B20C-EB97B7DC6604}</ProjectGuid>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>WpfApplication1</RootNamespace>
    <AssemblyName>WpfApplication1</AssemblyName>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
    <FileAlignment>512</FileAlignment>
    <ProjectTypeGuids>
      {60dc8134-eba5-43b8-bcc9-bb4bc16c2548};
      {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
    </ProjectTypeGuids>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <DebugSymbols>true</DebugSymbols>
    <DebugType>full</DebugType>
    <Optimize>false</Optimize>
    <OutputPath>bin\Debug\</OutputPath>
    <DefineConstants>DEBUG;TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
    <DebugType>pdbonly</DebugType>
    <Optimize>true</Optimize>
    <OutputPath>bin\Release\</OutputPath>
    <DefineConstants>TRACE</DefineConstants>
    <ErrorReport>prompt</ErrorReport>
    <WarningLevel>4</WarningLevel>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Core">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Xml.Linq">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Data.DataSetExtensions">
      <RequiredTargetFramework>3.5</RequiredTargetFramework>
    </Reference>
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="WindowsBase" />
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
  </ItemGroup>
  <ItemGroup>
    <ApplicationDefinition Include="App.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </ApplicationDefinition>
    <Page Include="Window1.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </Page>
    <Compile Include="App.xaml.cs">
      <DependentUpon>App.xaml</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
    <Compile Include="Window1.xaml.cs">
      <DependentUpon>Window1.xaml</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
  </ItemGroup>
  <ItemGroup>
    <Compile Include="Properties\AssemblyInfo.cs">
      <SubType>Code</SubType>
    </Compile>
    <Compile Include="Properties\Resources.Designer.cs">
      <AutoGen>True</AutoGen>
      <DesignTime>True</DesignTime>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
    <Compile Include="Properties\Settings.Designer.cs">
      <AutoGen>True</AutoGen>
      <DependentUpon>Settings.settings</DependentUpon>
      <DesignTimeSharedInput>True</DesignTimeSharedInput>
    </Compile>
    <EmbeddedResource Include="Properties\Resources.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>Resources.Designer.cs</LastGenOutput>
      <SubType>Designer</SubType>
    </EmbeddedResource>
    <None Include="Properties\Settings.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
      <LastGenOutput>Settings.Designer.cs</LastGenOutput>
    </None>
    <AppDesigner Include="Properties\" />
  </ItemGroup>
  <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
  <!-- To modify your build process, add your task inside one of the targets below and uncomment it. 
       Other similar extension points exist, see Microsoft.Common.targets.
  <Target Name="BeforeBuild">
  </Target>
  <Target Name="AfterBuild">
  </Target>
  -->
</Project>

A extensão do arquivo de projeto MSBuild gerado incorpora a linguagem do código-fonte:

• Para projetos C#, a extensão é .csproj.

• Para projetos Visual Basic, a extensão é . vbproj.

O arquivo de projeto é maior do que os exemplos anteriores, o que se deve parcialmente a várias propriedades adicionais. No entanto, as informações adicionais são específicas para Visual Studio e incluem o seguinte:

• Configurações do projeto

• Configurações de compilação

• Associação de arquivo de código-fonte.

• Gerenciamento de configurações, recursos, e propriedades de projeto padrão.

Configurações do projeto

Os detalhes de configuração do projeto incluem um identificador exclusivo para o projeto, um identificador exclusivo para o tipo de projeto, e vários dados identificando a versão do .NET Framework e Visual Studio:

<Project 
  ToolsVersion="3.5"
  DefaultTargets="Build"
  xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <ProductVersion>9.0.20726</ProductVersion>
    <SchemaVersion>2.0</SchemaVersion>
    <ProjectGuid>{E0EA3EBA-718C-4122-B20C-EB97B7DC6604}</ProjectGuid>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
    <ProjectTypeGuids>
      {60dc8134-eba5-43b8-bcc9-bb4bc16c2548};
      {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
    </ProjectTypeGuids>
  </PropertyGroup>
  ...
</Project>

Configurações de compilação

Um padrão de Visual Studio projeto tem duas configurações de compilação: Debug e Release (consulte a Criar configurações). Em um arquivo de projeto MSBuild, eles são configurados usando propriedades:

<Project ... >
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">
      Debug
    </Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <OutputType>WinExe</OutputType>
    <AppDesignerFolder>Properties</AppDesignerFolder>
    <RootNamespace>WpfApplication1</RootNamespace>
    <AssemblyName>WpfApplication1</AssemblyName>
    <FileAlignment>512</FileAlignment>
    <WarningLevel>4</WarningLevel>
    ...
  </PropertyGroup>
  ...
</Project>

A configuração atual de compilação é especificada pela propriedade Configuration:

<Project ... >
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">
      Debug
    </Configuration>
    ...
  </PropertyGroup>
  ...
</Project>

Associação de arquivo de código-fonte.

Visual Studio mantém uma associação entre arquivos de código-fonte relacionados (p.ex., marcação e code-behind). Isso permite que Visual Studio visualize a associação na janela Solution Explorer do Visual Studio:

A associação entre arquivos de código-fonte relacionados é feita usando metadados de DependentUpon e SubType:

<Project ... >
  ...
  <ItemGroup>
    <ApplicationDefinition Include="App.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </ApplicationDefinition>
    <Page Include="Window1.xaml">
      <Generator>MSBuild:Compile</Generator>
      <SubType>Designer</SubType>
    </Page>
    <Compile Include="App.xaml.cs">
      <DependentUpon>App.xaml</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
    <Compile Include="Window1.xaml.cs">
      <DependentUpon>Window1.xaml</DependentUpon>
      <SubType>Code</SubType>
    </Compile>
  </ItemGroup>
  ...
</Project>

Nesse projeto, App.xaml (marcação) está associado a App.xaml.cs (code-behind) e Window1.xaml (marcação) está associado a Window1.xaml.cs (code-behind).

Gerenciamento de configurações, recursos, e propriedades de projeto padrão

Visual Studio permite que você edite visualmente as propriedades de um projeto Visual Studio. A maioria dessas alterações afetam o processo de compilação e são armazenadas no arquivo de projeto Visual Studio gerenciado pelo Visual Studio. Os modelos de projeto Windows Presentation Foundation (WPF) também geram arquivos para fornecer configurações de forte tipagem e suporte a recursos. Todos são mostrados na figura a seguir:

Esses são gerenciados pelo arquivo de projeto MSBuild usando o seguinte:

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
  ...
  <ItemGroup>
    <Compile Include="Properties\AssemblyInfo.cs">
      <SubType>Code</SubType>
    </Compile>
    <Compile Include="Properties\Resources.Designer.cs">
      <AutoGen>True</AutoGen>
      <DesignTime>True</DesignTime>
      <DependentUpon>Resources.resx</DependentUpon>
    </Compile>
    <Compile Include="Properties\Settings.Designer.cs">
      <AutoGen>True</AutoGen>
      <DependentUpon>Settings.settings</DependentUpon>
      <DesignTimeSharedInput>True</DesignTimeSharedInput>
    </Compile>
    <EmbeddedResource Include="Properties\Resources.resx">
      <Generator>ResXFileCodeGenerator</Generator>
      <LastGenOutput>Resources.Designer.cs</LastGenOutput>
      <SubType>Designer</SubType>
    </EmbeddedResource>
    <None Include="Properties\Settings.settings">
      <Generator>SettingsSingleFileGenerator</Generator>
      <LastGenOutput>Settings.Designer.cs</LastGenOutput>
    </None>
    <AppDesigner Include="Properties\" />
  </ItemGroup>
  ...
</Project>

Compilando um projeto do MSBuild para WPF

Projetos MSBuild podem ser compilados a partir de um prompt de comando ou Visual Studio.

Compilando um projeto do MSBuild para WPF a partir do prompt de comando

Projetos MSBuild podem ser compilados ao chamar o msbuild.exe a partir do prompt de comando Windows ou do prompt de comando Windows Software Development Kit (SDK).

Compilando um projeto

Para compilar um projeto MSBuild, você executa MSBuild.exe, passando o nome de arquivo do projeto MSBuild desejado:

msbuild.exe msbuildprojectfile.proj

Compilando um projeto de linguagem específica gerado pelo Visual Studio

Arquivos de projeto MSBuild de linguagem específica gerados pelo Visual Studio:

• Ter um extensão de arquivo relevante (.csproj, .vbproj).

• Incluir um destino específico de linguagem (Microsoft.CSharp.targets, Microsoft.VisualBasic.targets).

O comando a seguir mostra como compilar um projeto C# a partir do prompt de comando:

msbuild.exe VSGeneratedProjectFileForCSharp.csproj

O comando a seguir mostra como compilar um projeto Visual Basic a partir do prompt de comando:

msbuild.exe VSGeneratedProjectFileForVisualBasic.vbproj

Compilando uma solução gerada por Visual Studio

MSBuild.exe também compilará arquivos de solução (.sln) que foram gerados por Visual Studio:

msbuild.exe VSGeneratedSolutionFile.sln

Compilando um projeto do MSBuild para WPF em Visual Studio

Se você estiver usando Visual Studio, não é necessário compilar seus projetos e soluções a partir do prompt de comando; Visual Studio permite que você faça os dois na própria IDE.

Compilando um projeto no Visual Studio.

Para compilar um projeto no Visual Studio, clique com o botão direito do mouse no projeto na janela Solution Explorer e escolha Build.

Compilando uma solução em Visual Studio

Para compilar uma solução, siga um destes procedimentos:

• Press F6 to build the solution.

• Pressione F5 para iniciar a depuração da solução.

• escolher Compilação | Criar solução.

• escolher Depurar | Iniciar a depuração.

• escolher Depurar | Iniciar sem depuração.

Fazer qualquer uma dessas para um um projeto ou uma solução faz com que Visual Studio execute MSBuild.exe para compilar os arquivos MSBuild adequados.

Linha de produção da compilação em Windows Presentation Foundation

Quando um WPF projeto é compilado, invoca-se a combinação de destinos específicos de linguagem e específicos de WPF. O processo de executar esses destinos denomina-se linha de produção de compilação, e as principais etapas estão ilustradas pela figura a seguir.

Essas etapas são descritas em detalhes nas seções seguintes.

Inicializações pré-compilação

Antes de compilar, MSBuild determina o local das ferramentas importantes e bibliotecas, incluindo o seguinte:

• O .NET Framework.

• Os diretórios Windows SDK.

• O local dos assemblies de referência da WPF.

• A propriedade para os caminhos de pesquisa dos assemblies.

O diretório dos assemblies de referência (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\) é o primeiro local onde os assemblies são procurados. Durante esta etapa, o processo de compilação também inicializa as várias propriedades e os grupos de itens e executa qualquer trabalho de limpeza necessário.

Resolvendo referências

O processo de compilação localiza e vincula os assemblies necessários para compilar o projeto de aplicativo. Essa lógica está contida na tarefa ResolveAssemblyReference. Todos os assemblies declarados como Reference no arquivo de projeto são fornecidos para a tarefa junto com informações sobre os caminhos de pesquisa e metadados sobre os assemblies já instalados no sistema. A tarefa procura assemblies e usa metadados do assembly instalado para filtrar os assemblies principais da WPF que não precisam aparecer nos manifestos de saída. Isso é feito para evitar informações redundantes nos manifestos ClickOnce. Por exemplo, como PresentationFramework.dll pode ser considerados representante de um aplicativo criado na e para a WPF e além disso visto que todos os assemblies da WPF existem no mesmo local em cada computador que possui o .NET Framework instalado, não é necessário incluir todas as informações em todos os assemblies de referência .NET Framework nos manifestos.

Compilação da marcação — passo 1

Nesta etapa, arquivos XAML são analisados e compilados de modo que o ambiente de execução não gaste tempo analisando XML e validando valores de propriedade. O arquivo XAML compilado é pré-tokenizado de modo que, em tempo de execução, carregá-lo deve ser muito mais rápido do que ao carregar um arquivo XAML.

Durante esta etapa, as seguintes atividades ocorrem para cada arquivo XAML que é um item de compilação Page:

1. O arquivo XAML é analisado pelo compilador de marcação.

2. Uma representação compilada é criada para aquele XAML e copiada para a pasta obj\Release.

3. Uma representação CodeDOM de uma nova classe parcial é criada e copiada para a pasta obj\Release.

Além disso, um específico a um linguagem arquivo de código é gerado para cada XAML arquivo. Por exemplo, para uma página Page1.xaml em um Visual Basic projeto, é gerado um Page1.g.vb; para um Page1.xaml página em um C# projeto, um Page1.g.cs é gerado. O ".g" no nome de arquivo indica que o arquivo é código gerado que tem uma declaração de classe parcial para o elemento de nível superior do arquivo de marcação (p.ex., Page ou Window). A classe é declarada com o modificador partial em C# (Extends no Visual Basic) para indicar que há outra declaração para a classe em outro lugar, geralmente no arquivo code-behind Page1.xaml.cs.

O classe parcial estende a classe-base adequada (p.ex., Page para uma página) e implementa a interface System.Windows.Markup.IComponentConnector. A interface IComponentConnector tem métodos para inicializar um componente e conectar nomes e eventos aos elementos em seu conteúdo. Consequentemente, o arquivo de código gerado tem uma implementação de métodos semelhante à seguinte:

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);
}

Por padrão, a compilação de marcação é executada no mesmo AppDomain que o mecanismo MSBuild. Isso fornece ganhos significativos no desempenho. Esse comportamento pode ser alternado com a propriedade AlwaysCompileMarkupFilesInSeparateDomain. Isso tem a vantagem de descarregar todos os assemblies de referência ao descarregar o AppDomain separado.

Compilação da marcação — passo 2

Nem todos os XAML páginas são compiladas em durante a etapa 1 de compilação da marcação. XAML arquivos localmente definiu referências de tipo (referências a tipos definidos no código em outro lugar no projeto mesmo) são isentos de compilação neste momento. Isso ocorre porque os tipos definidos localmente existem somente na fonte e ainda não foram compilados. Para determinar isso, o analisador usa heurísticas que envolvem a procura de itens tais como x:Name no arquivo de marcação. Quando uma dessas instâncias for encontrada, a compilação daquele arquivo de marcação é adiada até que os arquivos de código tenham sido compilados, após o qual o segundo passo de compilação de marcação processa esses arquivos.

Classificação de arquivos

Os arquivos de saída compilação processo coloca em grupos diferentes de recursos com base no qual conjunto de módulos (assembly) de aplicativo que eles serão colocados no. Em um aplicativo típico nonlocalized, todos sistema autônomo arquivos de dados marcados sistema autônomo Resource são colocados no assembly principal (executável ou biblioteca). Quando UICulture é definido no projeto, todos os arquivos XAML compilado e os recursos especificamente marcados como específicos do idioma são colocados no assembly de recursos de satélite. Além disso, todos os recursos independentes de idioma são colocados no assembly principal. Nesta etapa do processo de compilação, essa determinação é feita.

As ações de compilação ApplicationDefinition, Page, e Resource no arquivo de projeto podem ser aumentadas com os metadados Localizable (os valores aceitáveis são true e false), que determina se o arquivo é específico de um idioma ou independente de idioma.

Compilação principal

A etapa de compilação principal envolve a compilação de arquivos de código. Isso é coordenado pelo lógica nos arquivos específicos do linguagem destinos Microsoft.CSharp.targets e Microsoft.VisualBasic.targets. Se heurística determinou que uma única passagem do compilador marcação é suficiente e, em seguida, o assembly principal é gerado. No entanto, se um ou mais arquivos XAML no projeto têm referências a tipos definidos localmente, então um arquivo .dll temporário é gerado para que os assemblies do aplicativo final possam ser criados quando a segunda passada da compilação de marcação estiver concluída.

Geração de manifestos

No final do processo de compilação, quando todos os assemblies de aplicativos e arquivos de conteúdo estiverem prontos, os manifestos ClickOnce para o aplicativo são gerados.

O arquivo de manifesto de implantação descreve o modelo de implantação: a versão corrente, comportamento da atualização e identidade do publicador juntamente com assinatura digital. Este manifesto se destina a ser criado pelos administradores que lidam com a implantação. O extensão de arquivo é .xbap (abreviação de aplicativos de navegador XAML (XBAPs)) e .application para aplicativos instalados. O primeiro é determinado pela propriedade HostInBrowser do projeto e, consequentemente, o manifesto identifica o aplicativo como hospedado pelo navegador.

O manifesto do aplicativo (um arquivo .exe.manifest) descreve os assemblies do aplicativo e bibliotecas dependentes e lista as permissões necessárias para a execução do aplicativo. Esse arquivo se destina a ser criado pelo desenvolvedor do aplicativo. Para executar um aplicativo ClickOnce, um usuário abre o arquivo de manifesto de implantação do aplicativo.

Esses arquivos de manifesto sempre são criados para XBAPs. Para aplicativos instalados, eles não são criados a menos que a propriedade GenerateManifests seja especificada no arquivo de projeto com o valor true.

XBAPs obter duas permissões adicionais sobre e acima essas permissões atribuídas a aplicativos típicos de zona de Internet: WebBrowserPermission e MediaPermission. O sistema de compilação WPF declara as permissões no manifesto do aplicativo.

Suporte a compilação incremental

O sistema de compilação WPF oferece suporte para compilações incrementais. Ele é bastante inteligente para detectar as alterações feitas na marcação ou no código, e ele compila somente os artefatos afetados pela alteração. O mecanismo de compilação incremental usa os seguintes arquivos:

• Um arquivo $(AssemblyName)_MarkupCompiler.Cache para manter o estado atual do compilador.

• Um arquivo $(AssemblyName)_MarkupCompiler.lref para armazenar em cache os arquivos XAML com referências aos tipos definidos localmente.

Este é um conjunto de regras que regem a compilação incremental:

• O arquivo é a menor unidade na qual o sistema de compilação detecta alterações. Portanto, para um arquivo de código, o sistema de compilação não pode determinar se um tipo foi alterado ou se foi adicionado código. O mesmo vale para arquivos de projetos.

• O mecanismo de compilação incremental deve estar ciente que uma página XAML define uma classe ou usa outras classes.

• Se entradas Reference sofrerem alterações, então recompile todas as páginas.

• Se um arquivo de código for alterado, recompile todas as páginas com referências a tipos definidos localmente.

• Se um arquivo XAML sofrer alterações:

  • If XAML é declarada sistema autônomo Page no projeto: Se o XAML não possui referências de tipo definidos localmente, recompilar que XAML Além de tudo XAML páginas com referências locais; se a XAML tem referências locais, recompilar tudo XAML páginas com referências locais.

  • If XAML é declarada sistema autônomo ApplicationDefinition no projeto: recompilar todos os XAML páginas (razão: cada XAML possui referência a um Application tipo que pode ter sido alterado).

• Se o arquivo de projeto declara um arquivo de código como definição de aplicativo em vez de um arquivo XAML:

  • Verifique se o valor ApplicationClassName no arquivo de projeto foi alterado (existe um novo tipo de aplicativo?). Em caso afirmativo, recompile o aplicativo inteiro.

  • Caso contrário, recompile todas as páginas XAML com referências locais.

• Se mudar de um arquivo de projeto: Aplicar todas as regras precedentes e veja o que precisa ser recompilado. As alterações feitas às propriedades seguintes acionam uma recompilação completa: AssemblyName, IntermediateOutputPath, RootNamespace, e HostInBrowser.

As seguintes situações de recompilação são possíveis:

• Todo o aplicativo é recompilado.

• Somente os arquivos XAML que têm referências a tipos definidos localmente são recompilados.

• Nada é recompilado (se nada no projeto tiver sido alterado).

Consulte também

Conceitos

Implantar um aplicativo WPF (WPF)

URIs de Pacotes no Windows Presentation Foundation

Arquivos de Recurso, Conteúdo e Dados de Aplicações Windows Presentation Foundation

Outros recursos

Referência do Windows Presentation Foundation MSBuild

Date	History	Motivo
Julho de 2008	Informações sobre a propriedade de compilação SplashScreen adicionadas.	Alteração de recurso do SP1.