Generar una aplicación de WPF (WPF)
Actualización: Julio de 2008
Las aplicaciones de Windows Presentation Foundation (WPF) pueden generarse como aplicaciones ejecutables de .NET Framework (.exe), bibliotecas (.dll) o una combinación de ambos tipos de ensamblados. En este tema se explica inicialmente cómo generar aplicaciones de WPF simples desde el símbolo del sistema, antes de mostrar cómo WPF aprovecha la extensibilidad de Microsoft build engine (MSBuild) para generar aplicaciones más complejas. Finalmente, en el tema se proporciona una descripción detallada de los pasos clave en el proceso de compilación de MSBuild.
Este tema contiene las secciones siguientes.
- Generar una aplicación de WPF con la compilación desde la línea de comandos
- Generar una aplicación de WPF mediante MSBuild
- Archivos de proyecto de MSBuild para WPF
- Crear un proyecto de MSBuild para WPF utilizando Visual Studio
- Generar un proyecto de MSBuild para WPF
- Canalización de compilación de Windows Presentation Foundation
- Compatibilidad con la compilación incremental
- Temas relacionados
Generar una aplicación de WPF con la compilación desde la línea de comandos
Una aplicación de WPF escrita totalmente en código (sin marcado) puede generarse con un compilador de la línea de comandos. Considere, por ejemplo, una aplicación independiente de WPF escrita en C# que incluya los archivos de código fuente siguientes:
Un archivo de definición de aplicación (app.cs).
Una ventana (mainwindow.cs).
Esta aplicación se genera con el compilador de C#, csc.exe, desde un símbolo del sistema, como en el ejemplo siguiente:
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"
En este ejemplo:
El parámetro /out especifica el nombre del ensamblado ejecutable (WPFApplication.exe) compilado.
El parámetro /target especifica el tipo de ensamblado que se genera (un ejecutable de Microsoft Windows).
Los archivos de código fuente de C# que componen la aplicación (app.cs y mainwindow.cs)
El parámetro /reference que identifica los ensamblados a los que se hace referencia que implementan los tipos utilizado por la aplicación.
Para generar aplicaciones más complejas se puede utilizar la compilación desde la línea de comandos, aunque el compilador no admite aplicaciones de WPF que incluyan código fuente Lenguaje de marcado de aplicaciones extensible (XAML). Asimismo, la compilación desde la línea de comandos no admite el conjunto completo de requisitos de compilación de las aplicaciones de WPF típicas, incluida la administración de la configuración y la generación de manifiestos ClickOnce. Para admitir éstos y otros requisitos de compilación más complejos, WPF se integra con MSBuild y extiende su funcionalidad.
Nota
Para obtener más información sobre la compilación desde la línea de comandos, vea Generar la línea de comandos con csc.exe o Generar desde la línea de comandos (Visual Basic).
Generar una aplicación de WPF mediante MSBuild
MSBuild es una tecnología robusta y extensible que se introdujo con .NET Framework. El núcleo de la tecnología MSBuild está implementado en todos los ensamblados que se describen en la tabla siguiente.
Ensamblado |
Descripción |
|---|---|
Microsoft.Build.Engine.dll |
Lee y procesa los archivos de proyecto de MSBuild. |
Microsoft.Build.Tasks.dll |
Implementa la funcionalidad común a todos los proyectos de MSBuild, incluida la invocación del compilador desde la línea de comandos (por ejemplo, csc.exe para C# y vbc.exe para Visual Basic). |
Microsoft.Build.Utilities.dll |
Expone clases de utilidad que extienden MSBuild con funcionalidad de compilación personalizada. |
Microsoft.Build.Framework.dll |
Implementa interfaces que definen cómo interactúa la funcionalidad de MSBuild con el motor de MSBuild. |
Microsoft.Build.Conversion.dll |
Permite la conversión del formato de los archivos de proyecto de Microsoft Visual Studio .NET 2002 y Microsoft Visual Studio .NET 2003 heredados al formato del archivo de proyecto de Microsoft Visual Studio 2005MSBuild. |
Nota
Para obtener más información sobre los ensamblados de MSBuild, vea Referencia de MSBuild.
Archivos de proyecto de MSBuild para WPF
Los ensamblados que componen MSBuild reciben el nombre de motor de MSBuild. Para generar aplicaciones, el motor de MSBuild requiere normalmente la siguiente información:
Referencias a los archivos de código fuente.
Referencias a los ensamblados dependientes.
Detalles de configuración.
Requisitos de compilación.
Esta información se empaqueta en archivos de XML compatibles con el esquema de MSBuild personalizado para que MSBuild pueda procesarla (vea Referencia de esquemas del archivo de proyecto MSBuild). Estos archivos se denominan archivos de proyecto de MSBuild. A continuación, se incluye un archivo de proyecto de MSBuild para una versión de la aplicación de WPF que generamos previamente mediante un compilador de la línea de comandos, al que se incorporaron archivos de código fuente de Lenguaje de marcado de aplicaciones extensible (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 ejemplo contiene los elementos que son comunes a la mayoría de los archivos de proyecto de MSBuild, incluida la etiqueta Project, las propiedades, los elementos, los destinos y las tareas.
El elemento Project
Según se especifica en el esquema de archivo de proyecto de MSBuild, un archivo de proyecto de MSBuild es un archivo XML con Project como elemento de nivel superior:
<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
...
</Project>
El elemento Project es donde el motor de MSBuild inicia el procesamiento de un archivo de proyecto. Para especificar la versión de MSBuild utilizada para el archivo de proyecto de MSBuild, se proporciona una declaración de espacio de nombres XML adecuada.
Propiedades
Las propiedades son variables que se utilizan para configurar los proyectos de MSBuild y proporcionar información específica de la compilación al motor de MSBuild. Las propiedades se incluyen en elementos PropertyGroup, como se muestra en el ejemplo siguiente.
<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<AssemblyName>WPFApplication</AssemblyName>
<OutputType>winexe</OutputType>
</PropertyGroup>
...
</Project>
Algunas propiedades, como AssemblyName y OutputType, son comunes a todos los tipos de aplicación y se describen en Propiedades comunes de proyectos de MSBuild. En la tabla siguiente se muestran las propiedades de MSBuild específicas de WPF.
Propiedad |
Descripción |
|---|---|
OutputType |
Especifica el tipo de ensamblado que se genera y tiene alguno de los valores siguientes:
|
HostInBrowser |
Especifica si una aplicación de WPF se hospeda en un explorador, y tiene alguno de los valores siguientes:
Si HostInBrowser es true, OutputType debe ser winexe. |
Install |
Especifica si XBAP se instala en el cliente. Install puede ser true o false, y tiene el valor contrario de HostInBrowser. |
GenerateManifests |
Especifica si una aplicación independiente se publica utilizando la implementación de ClickOnce, y tiene alguno de los valores siguientes:
GenerateManifests se utiliza únicamente cuando Install tiene un valor de true. |
UICulture |
Especifica la configuración regional para la que se va a generar el ensamblado. Cuando se especifica, los archivos declarados como elementos de proyecto Resource y los recursos específicos del idioma se generan en un ensamblado satélite para la configuración regional deseada. Sin embargo, el contenido neutral en cuanto al idioma se genera en el ensamblado principal. De forma predeterminada, las aplicaciones no se traducen y, por tanto, los archivos de recursos están incrustados en el ensamblado principal. Nota Cuando se establece UICulture, se debe especificar el idioma de recursos neutral mediante NeutralResourcesLanguageAttribute. Este atributo se debe agregar al archivo AssemblyInfo de una aplicación de WPF. |
Elementos
Los elementos son entradas de MSBuild que procesa el motor de MSBuild durante el proceso de compilación. Los elementos se incluyen dentro de un 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>
El tipo de un elemento se puede configurar con metadatos; en el ejemplo anterior, las referencias de ensamblado se configuran como elementos Reference y los archivos de código fuente se configuran como elementos Compile. Los elementos Reference y Compile son comunes a todas las aplicaciones de .NET Framework y se describen con más detalle en Elementos comunes de proyectos de MSBuild.
En la tabla siguiente se muestran los elementos de MSBuild específicos de WPF.
Propiedad |
Descripción |
|---|---|
ApplicationDefinition |
Identifica el archivo de marcado de XAML que contiene la definición de aplicación (un archivo de marcado XAML cuyo elemento raíz es Application). ApplicationDefinition es obligatorio cuando Install es true y OutputType es winexe. Una aplicación de WPF y, por tanto, un proyecto de MSBuild sólo pueden tener un elemento ApplicationDefinition. |
Page |
Identifica un archivo de marcado de XAML cuyo contenido se convierte a un formato binario y se genera en un ensamblado. Los elementos Page se suelen implementar junto con una clase de código subyacente. Los elementos Page más comunes son archivos de XAML cuyos elementos de nivel superior son alguno de los siguientes:
|
Resource |
Identifica un archivo de recursos que se genera en un ensamblado de aplicación. Como se mencionó anteriormente, UICulture procesa los elementos Resource. |
Content |
Identifica un archivo de contenido que se distribuye con una aplicación. Los metadatos que describen el archivo de contenido se generan en la aplicación (mediante AssemblyAssociatedContentFileAttribute). |
SplashScreen |
Identifica un archivo de imagen que se utiliza para la ventana de inicio de la aplicación. El ensamblado PresentationBuildTasks genera código en App.g.cs o Application.g.vb que crea una instancia de SplashScreen y la presenta mientras se carga la aplicación. Este elemento está disponible a partir de Visual Studio 2008 SP1. |
Destinos
Los destinos determinan cómo se generan los proyectos y dependen de las propiedades y los elementos. Una aplicación de WPF debe tener un destino específico del lenguaje y un 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>
Los destinos son archivos independientes que terminan con la extensión .targets. Los archivos de destino que se incluyen con .NET Framework se instalan en la ubicación siguiente:
%WINDIR%\Microsoft.NET\Framework\vX.X.X
El destino específico del lenguaje genera código fuente específico del lenguaje. El destino específico del lenguaje de C# es Microsoft.CSharp.targets y Microsoft.VisualBasic.targets para Visual Basic. Ambos destinos se derivan y extienden el destino Microsoft.Common.targets, que realiza la mayoría del trabajo de compilación común independiente del lenguaje. Para obtener más información sobre los destinos comunes y específicos del lenguaje de MSBuild, vea Archivos .Targets de MSBuild.
El destino Microsoft.WinFX.targets realiza el trabajo de compilación específico de WPF. Entre sus tareas se incluye la compilación del marcado XAML, la generación de manifiestos para las aplicaciones XBAP y el procesamiento de los recursos y archivos de contenido de WPF.
Tareas
Una tarea es una clase que realiza una acción de compilación específica. Los destinos combinan una o varias tareas para definir un proceso de compilación; cuando MSBuild procesa un destino, ejecuta las tareas incluidas en él. Las tareas utilizadas por los destinos comunes y específicos del lenguaje se implementan mediante el ensamblado Microsoft.Build.Tasks, y las tareas específicas de WPF se implementan mediante el ensamblado PresentationBuildTasks.
Los destinos proporcionan compatibilidad para generar todas las aplicaciones de WPF estándar. También es posible utilizar combinaciones alternativas de tareas para implementar un comportamiento de compilación personalizado. Por ejemplo, la tarea MSBuildGetWinFXPath siguiente se utiliza para detectar la ruta de acceso nativa del motor en tiempo de ejecución de .NET Framework, que depende de si la tarea se ejecuta en un procesador 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 obtener más información sobre las tareas comunes de MSBuild, vea Referencia de tareas de MSBuild.
Ejemplos de proyectos de MSBuild para Windows Presentation Foundation
El Kit de desarrollo de software de Windows (SDK) incluye varios archivos de proyecto de MSBuild de ejemplo para los tipos más comunes de aplicaciones de WPF:
Crear un proyecto de MSBuild para WPF utilizando Visual Studio
Visual Studio genera automáticamente archivos de proyecto de MSBuild cuando se crean nuevas aplicaciones de WPF mediante plantillas de proyecto de Visual Studio. Por ejemplo, la plantilla de proyecto de aplicación de WPF genera el archivo de proyecto siguiente (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>
El nombre de la extensión de archivo de proyecto de MSBuild generado incorpora el lenguaje del código fuente:
Para los proyectos escritos en C#, la extensión es .csproj.
Para los proyectos escritos en Visual Basic, la extensión es **.**vbproj.
El archivo de proyecto es más grande que el de los ejemplos anteriores, debido en parte a varias propiedades adicionales. Sin embargo, la información adicional es específica de Visual Studio e incluye lo siguiente:
Configuración del proyecto.
Configuración de compilación.
Asociación de archivos de código fuente.
Administración de las propiedades, recursos y configuración del proyecto predeterminados.
Configuración del proyecto
Los detalles de configuración del proyecto incluyen un identificador único para el proyecto, un identificador único para el tipo de proyecto y varios datos que identifican la versión de .NET Framework y 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>
Configuración de compilación
Un proyecto escrito en Visual Studio predeterminado tiene dos configuraciones de compilación: Debug y Release (vea Configuraciones de compilación). En un archivo de proyecto de MSBuild, éstas se configuran mediante propiedades:
<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>
La propiedad Configuration especifica la configuración de compilación actual:
<Project ... >
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">
Debug
</Configuration>
...
</PropertyGroup>
...
</Project>
Asociación de archivos de código fuente
Visual Studio mantiene una asociación entre los archivos de código fuente relacionados, como los archivos de marcado y de código subyacente. Esto permite que Visual Studio visualice la asociación en la ventana Explorador de soluciones de Visual Studio:
.png)
La asociación entre los archivos de código fuente relacionados se realiza utilizando los metadatos DependentUpon y 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>
En este proyecto, App.xaml (archivo de marcado) está asociado a App.xaml.cs (archivo de código subyacente), y Window1.xaml (archivo de marcado) está asociado a Window1.xaml.cs (archivo de código subyacente).
Administración de las propiedades, recursos y configuración del proyecto predeterminados
Visual Studio permite modificar visualmente las propiedades de un proyecto escrito en Visual Studio. La mayoría de estas propiedades afectan al proceso de compilación y se almacenan en el archivo de proyecto de Visual Studio administrado por Visual Studio. Las plantillas de proyecto de Windows Presentation Foundation (WPF) generan también archivos para proporcionar compatibilidad con los recursos y valores con establecimiento inflexible de tipos. Todo esto se muestra en la siguiente ilustración:
.png)
Se administran mediante el archivo de proyecto de MSBuild del modo siguiente:
<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>
Generar un proyecto de MSBuild para WPF
Los proyectos de MSBuild se pueden generar desde un símbolo del sistema o en Visual Studio.
Generar un proyecto de MSBuild para WPF desde el símbolo del sistema
Los proyectos de MSBuild se pueden generar llamando a msbuild.exe desde el símbolo del sistema de Windows o desde el símbolo del sistema de Kit de desarrollo de software de Windows (SDK).
Generar un proyecto
Para generar un proyecto de MSBuild, ejecute msbuild.exe, pasando el nombre de archivo del proyecto de MSBuild deseado:
msbuild.exe msbuildprojectfile.proj
Generar un proyecto específico del lenguaje generado por Visual Studio
Los archivos de proyecto de MSBuild específicos del lenguaje generados por Visual Studio:
Tienen una extensión de archivo relevante (.csproj, .vbproj).
Incluyen un destino específico del lenguaje (Microsoft.CSharp.targets, Microsoft.VisualBasic.targets).
A continuación, se muestra cómo generar un proyecto de C# desde el símbolo del sistema:
msbuild.exe VSGeneratedProjectFileForCSharp.csproj
A continuación, se muestra cómo generar un proyecto de Visual Basic desde el símbolo del sistema:
msbuild.exe VSGeneratedProjectFileForVisualBasic.vbproj
Generar una solución generada por Visual Studio
msbuild.exe generará también archivos de solución (.sln) generados por Visual Studio:
msbuild.exe VSGeneratedSolutionFile.sln
Generar un proyecto de MSBuild para WPF en Visual Studio
Si utiliza Visual Studio, no necesita generar los proyectos y las soluciones desde el símbolo del sistema; Visual Studio permite generar ambos desde el IDE.
Generar un proyecto en Visual Studio
Para generar un proyecto en Visual Studio, haga clic con el botón secundario del mouse en el proyecto en el Explorador de soluciones y elija Generar.
Generar una solución en Visual Studio
Para generar una solución, realice el procedimiento siguiente:
Presione F6 para generar la solución.
Presione F5 para iniciar la depuración de la solución.
Elija Generar | Generar solución.
Elija Depurar | Iniciar depuración.
Elija Depurar | Iniciar sin depurar.
Al realizar alguna de estas operaciones para un proyecto o solución, Visual Studio ejecuta msbuild.exe para generar los archivos MSBuild correspondientes.
Canalización de compilación de Windows Presentation Foundation
Cuando se genera un proyecto de WPF, se invoca la combinación de destinos específicos del lenguaje y de WPF. El proceso de ejecución de estos destinos se denomina canalización de compilación y los pasos principales se muestran en la siguiente ilustración.
.png)
Estos pasos se describen con mayor detalle en la siguientes secciones.
Inicializaciones previas a la compilación
Antes de generar, MSBuild determina la ubicación de herramientas y bibliotecas importantes, entre las que se incluyen las siguientes:
.NET Framework.
Los directorios de Windows SDK.
La ubicación de los ensamblados de referencia de WPF.
La propiedad de las rutas de búsqueda de ensamblados.
El directorio de los ensamblados de referencia (%ProgramFiles%\Reference Assemblies\Microsoft\Framework\v3.0\) es la primera ubicación en la que se buscan los ensamblados. Durante este paso, el proceso de compilación inicializa también las distintas propiedades y grupos de elementos, y efectúa el trabajo de limpieza necesario.
Resolver referencias
El proceso de compilación busca y enlaza los ensamblados necesarios para generar el proyecto de aplicación. Esta lógica se incluye en la tarea ResolveAssemblyReference. Todos los ensamblados declarados como Reference en el archivo de proyecto se proporcionan a la tarea junto con información sobre las rutas de búsqueda y los metadatos de los ensamblados que ya están instalados en el sistema. La tarea busca los ensamblados y utiliza los metadatos del ensamblado instalado para filtrar los ensamblados de WPF básicos que no deben mostrarse en los manifiestos de salida. Esto es necesario para evitar información redundante en los manifiestos de ClickOnce. Por ejemplo, como PresentationFramework.dll se puede considerar representativo de una compilación de aplicación y de WPF y, puesto que todos los ensamblados de WPF están en la misma ubicación en cada equipo que tiene .NET Framework instalado, no hay necesidad de incluir toda la información sobre todos los ensamblados de referencia de .NET Framework en los manifiestos.
Generación del marcado: Paso 1
En este paso, los archivos de XAML se analizan y generan para que el motor en tiempo de ejecución no tenga que encargarse de analizar XML y validar los valores de las propiedades. El archivo de XAML generado se convierte en un token para que pueda cargarse mucho más rápido en tiempo de ejecución.
Durante este paso, se realizan las siguientes operaciones para cada archivo de XAML que es un elemento de compilación Page:
El compilador de marcado analiza el archivo XAML.
Se crea una representación generada para el XAML y se copia a la carpeta obj\Release.
Se crea una representación de CodeDOM de una nueva clase parcial y se copia a la carpeta obj\Release.
Además, se genera un archivo de código específico del lenguaje para cada archivo XAML. Por ejemplo, para una página Page1.xaml de un proyecto escrito en Visual Basic se genera un archivo Page1.g.vb; para una página Page1.xaml de un proyecto escrito en C# se genera un archivo Page1.g.cs. ".g" en el nombre de archivo indica que el archivo es código generado que tiene una declaración de clase parcial para el elemento de nivel superior del archivo de marcado (como Page o Window). La clase se declara con el modificador partial de C# (Extends en Visual Basic) para indicar que es otra declaración de la clase en otro lugar, normalmente en el archivo Page1.xaml.cs de código subyacente.
La clase parcial se extiende desde la clase base correspondiente (como Page para una página) e implementa la interfaz System.Windows.Markup.IComponentConnector. La interfaz IComponentConnector tiene métodos que inicializan un componente y conectan los nombres y eventos en elementos en su contenido. Por consiguiente, el archivo de código generado tiene una implementación de métodos como la siguiente:
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);
}
De forma predeterminada, la compilación del marcado se ejecuta en el mismo AppDomain que el motor de MSBuild. Esto proporciona una mejora del rendimiento importante. Este comportamiento se puede activar o desactivar alternativamente con la propiedad AlwaysCompileMarkupFilesInSeparateDomain. Esto presenta la ventaja de descargar todos los ensamblados de referencia descargando el objeto AppDomain independiente.
Generación del marcado: Paso 2
No todas las páginas XAML se generan en el paso 1 de la compilación de marcado. Los archivos XAML que tienen referencias de tipos definidos localmente (referencias a tipos definidos en el código en otro lugar del mismo proyecto) no se generan en este momento. Esto se debe a que estos tipos definidos localmente sólo existen en el código fuente y aún no están generados. Para determinar esto, el analizador utiliza heurística que implica la búsqueda de elementos como x:Name en el archivo de marcado. Cuando se encuentra este tipo de instancia, la compilación del archivo de marcado se pospone hasta que se hayan generado los archivos de código y, en ese momento, el segundo paso de la compilación de marcado procesa estos archivos.
Clasificación de archivos
El proceso de compilación coloca los archivos de resultados en grupos de recursos diferentes en función del ensamblado de aplicación en el que se van a incluir. En una aplicación no traducida típica, todos los archivos de datos marcados como Resource se colocan en el ensamblado principal (ejecutable o biblioteca). Cuando UICulture se establece en el proyecto, todos los archivos XAML generados y los recursos explícitamente marcados como específicos del lenguaje se colocan en el ensamblado de recursos satélite. Asimismo, todos los recursos neutrales en cuanto al idioma se colocan en el ensamblado principal. Esta determinación de ubicación de los archivos se realiza en este paso del proceso de compilación.
Las acciones de compilación de ApplicationDefinition, Page y Resource del archivo de proyecto se pueden incrementar con los metadatos de Localizable (los valores permitidos son true y false), que indican si el archivo es específico del idioma o neutral en cuanto al idioma.
Compilación básica
El paso básico de compilación implica la compilación de los archivos de código. Esta compilación está controlada por los archivos de destino específicos del lenguaje Microsoft.CSharp.targets y Microsoft.VisualBasic.targets. Si la heurística ha determinado que basta con un solo paso del compilador de marcado, se genera el ensamblado principal. Sin embargo, si uno o varios archivos XAML del proyecto tienen referencias a tipos definidos localmente, se genera un archivo .dll temporal para que los ensamblados de aplicación finales se puedan crear una vez completado el segundo paso de compilación del marcado.
Generación de manifiestos
Al final del proceso de compilación, cuando todos los ensamblados de aplicación y archivos de contenido están listos, se generan los manifiestos de ClickOnce para la aplicación.
El archivo de manifiesto de implementación describe el modelo de implementación: la versión actual, el comportamiento de actualización y la identidad del editor junto con la firma digital. Se supone que este manifiesto lo crean los administradores que controlan la implementación. La extensión de archivo es .xbap (para Aplicaciones del explorador XAML (XBAPs)) y .application para las aplicaciones instaladas. La primera se indica a través de la propiedad HostInBrowser del proyecto y, como resultado, el manifiesto identifica la aplicación como hospedada en el explorador.
El manifiesto de aplicación (un archivo .exe.manifest) describe los ensamblados de la aplicación y las bibliotecas dependientes, e incluye los permisos necesarios para la aplicación. Se supone que este archivo lo crea el desarrollador de la aplicación. Para iniciar una aplicación ClickOnce, un usuario abre el archivo de manifiesto de implementación de la aplicación.
Estos archivos de manifiesto siempre se crean para XBAPs. Para las aplicaciones instaladas, no se crean a menos que la propiedad GenerateManifests se especifique en el archivo de proyecto con el valor true
Los XBAPs obtienen dos permisos adicionales además de los permisos asignados a las aplicaciones típicas de zona de Internet: WebBrowserPermission y MediaPermission. El sistema de compilación de WPF declara esos permisos en el manifiesto de la aplicación.
Compatibilidad con la compilación incremental
El sistema de compilación de WPF proporciona compatibilidad con compilaciones incrementales. Es bastante inteligente a la hora de detectar los cambios efectuados en el marcado o el código, y sólo detecta los artefactos afectados por el cambio. El mecanismo de compilación incremental utiliza los archivos siguientes:
Un archivo $(nombreDeEnsamblado)_MarkupCompiler.Cache para mantener el estado del compilador.
Un archivo $(nombreDeEnsamblado)_MarkupCompiler.lref para almacenar en caché los archivos XAML con referencias a tipos definidos localmente.
A continuación, se incluye un conjunto de reglas que rigen la compilación incremental:
El archivo es la unidad más pequeña en la que el sistema de compilación detecta un cambio. Por tanto, para un archivo de código, el sistema de compilación no puede determinar si se ha cambiado un tipo o se ha agregado código. Lo mismo se aplica a los archivos de proyecto.
El mecanismo de compilación incremental debe saber que una página XAML define una clase o utiliza otras clases.
Si las entradas Reference cambian, vuelva a generar todas las páginas.
Si un archivo de código cambia, vuelva a generar todas las páginas con referencias de tipos definidos localmente.
Si un archivo XAML cambia:
Si XAML se declara como Page en el proyecto: si XAML no tiene referencias de tipos definidos localmente, vuelva a generar ese XAML además de todas las páginas XAML con referencias locales; si XAML tiene referencias locales, vuelva a generar todas las páginas XAML con referencias locales.
Si XAML se declara como ApplicationDefinition en el proyecto: vuelva a generar todas las páginas XAML (razón: cada XAML hace referencia a un tipo Application que puede haber cambiado).
Si el archivo de proyecto declara un archivo de código como definición de aplicación en lugar de un archivo XAML:
Compruebe si el valor de ApplicationClassName en el archivo de proyecto ha cambiado (¿hay un nuevo tipo de aplicación?). En ese caso, vuelva a generar toda la aplicación.
De lo contrario, vuelva a generar todas las páginas XAML con referencias locales.
Si un archivo de proyecto cambia: aplique todas las reglas anteriores y determine lo que tiene que volver a generar. Los cambios en las propiedades siguientes desencadenan una recompilación completa: AssemblyName, IntermediateOutputPath, RootNamespace y HostInBrowser.
Las situaciones de recompilación posibles son las siguientes:
Se vuelve a generar toda la aplicación.
Sólo se vuelven a generar los archivos XAML que tienen referencias de tipos definidos localmente.
No se vuelve a generar nada (si no ha cambiado nada en el proyecto).
Vea también
Conceptos
Implementar una aplicación de WPF
URIs de paquete en Windows Presentation Foundation
Archivos c Windows Presentation Foundation
Otros recursos
Referencia de MSBuild para Windows Presentation Foundation
Historial de cambios
Fecha |
Historial |
Motivo |
|---|---|---|
|
Julio de 2008 |
Se ha agregado información sobre la propiedad de compilación SplashScreen. |
Cambio de características de SP1. |