El editor de propiedades de Visual Studio, aparte de servirnos para establecer los valores de propiedades de controles, también sirve para examinar y cambiar las propiedades de los archivos que tengamos seleccionados en el Explorador de Soluciones.
Puedes verlo abriendo Visual Studio y creando o abriendo un proyecto nuevo de cualquier tipo (por ejemplo, uno Web). Si vas al explorador de soluciones, haces clic en cualquier archivo y luego pulsas F4 aparecerá el editor de propiedades con las propiedades del archivo que tienes seleccionado. Entre sus diversas propiedades existe una denominada Build Action:
¿Para qué sirve y qué efecto tiene sobre los archivos el hecho de cambiarla?
Este valor decide qué va a ocurrir con el archivo a la hora de compilar el proyecto. Por ejemplo: ¿se copiará junto con los demás al proyecto final o se dejará solo para tiempo de desarrollo? ¿Se incluirá como un recurso dentro de algún ensamblado?, etc, etc...
Como podemos ver en la figura anterior, dispone de un montón de valores posibles, muchos relacionadas con XAML y WPF, que paso a explicar someramente a continuación:
- None: no hace nada con el archivo, como parece evidente :-)
- Compile: compila el contenido del archivo. Se usa para archivos con código fuente (.cs, .vb, etc..). Si quieres dejar fuera de la compilación a uno de estos archivos puedes ponerle 'None' como acción.
- Content: se usa para marcar archivos que deben ser distribuidos con la aplicación (y por lo tanto copiados a la carpeta de compilación) pero que son únicamente de contenido, no de código. Por ejemplo un archivo de configuración, un gráfico, un archivo .js o .css en una aplicación web, un archivo XML, etc... Son contenido, sin más.
- Embedded Resource: cuando un archivo (por ejemplo un gráfico) prefieres que no se distribuya como archivo independiente sino que se incluya dentro del ensamblado de proyecto como un recurso embebido. Esto hace que a la hora de compilar el proyecto el elemento se incluya dentro del ensamblado resultante (DLL o EXE) como un recurso que podremos utilizar mediante la API correspondiente. Por ejemplo, si añades un archivo "logo.jpg" a tu proyecto y le asignas este valor para la compilación, luego puedes leer el gráfico para usarlo del siguiente modo:
Bitmap miLogo = new Bitmap(this.GetType(), "logo.jpg");
- CodeAnalysisDictionary: esto sirve para marcar un archivo XML como origen de diccionario de palabras personalizado. Esto tiene que ver con el análisis de código que hace Visual Studio (lo que antiguamente se llamaba FxCop y que quizá te suene más si llevas tiempo en esto). Básicamente, cuando estableces las normas que debe cumplir tu código y le realizas un análisis para que te proporcione advertencias, una de las opciones que puedes marcar es exigir que los nombres de métodos, campos y variables estén bien escritos (no tengan faltas de ortografía) para lo cual se usa un diccionario del mismo modo que en Word, por ejemplo. Si hay palabras que no están en el diccionario pero que tú consideras correctas (por ejemplo, el nombre de tu empresa) puedes incluirlas en un archivo de diccionario personalizado (como en Word, de hecho) que en este caso es un .xml que contiene una serie de palabras y está marcado con este atributo. Por ejemplo, puedes incluirle esto:
<?xml version="1.0" encoding="utf-8" ?>
<Dictionary>
<Words>
<Recognized>
<Word>Krasis</Word>
<Word>campusMVP</Word>
</Recognized>
</Words>
</Dictionary>
y así te reconoce estas dos palabras como válidas y no se quejará el analizador de código.
- ApplicationDefinition: Esta opción se usa para identificar a los archivos de marcado XAML que contienen la definición de una aplicación WPF, esto es, un archivo XAML cuyo nodo raíz es <application>. También se puede marcar un archivo .cs o .vb si la definición de la aplicación se hace directamente por código. Sólo puede haber un archivo en todo el proyecto marcado con esta acción de compilación.
- Page: También relacionada con WPF. Se usa para marcar archivos XAML de tipo página (normalmente con un archivo CodeBehind asociado) cuyo contenido se convierte a formato binario y se compila en un ensamblado. Suelen contener nodos de tipo Window, Page, FlowDocument o UserControl.
- Resource: similar a Embedded Resource porque incluye elementos como recursos en un ensamblado, pero en este caso un ensamblado utilizado para aplicaciones WPF.
- SplashScreen: también exclusivo de aplicaciones WPF. Sirve para marcar una imagen como la imagen de lanzamiento de la aplicación, de modo que se muestra mientras carga el resto de la aplicación.
- DesignData: se utiliza para definir ciertos archivos .xaml como controles de ejemplo para visualizar en vistas previas de WPF. Por ejemplo, si un control no es instanciable en tiempo de diseño o tiene propiedades de solo lectura a las que queremos darle valores por defecto. Está explicado con detalle aquí.
- DesignDataWithDesignTimeCreatableTypes: es muy similar al anterior, pero en lugar de usar tipos falsos creados para simular datos en tiempo de diseño, en este caso se utilizan los tipos reales, solo que los datos de tiempo de diseño se generan en el constructor por defecto. Nuevamente en el enlace anterior hay más información al respecto.
- EntityDeploy: Entity Framework marca los archivos .edmx con este atributo. Los archivos .edmx contienen las tres capas de definición (o artefactos) de un modelo de Entity Framework: conceptual, mapeado y almacenamiento. De este modo, al compilar el proyecto se extraen automáticamente esas tres secciones del .edmx en otros tantos archivos independientes: La sección CSDL se extra a un archivo .csdl, la sección MSL se extrae a un archivo .msl, y la sección SSDL se extrae a uno .ssdl. Esto se combina con el hecho de que normalmente la propiedad Metadata Artifact Processing se establece como “Embed”, y los tres archivos se incluyen embebidos como recursos en el ensamblado final de la aplicación. Si se cambia este valor a “Copy” entonces los tres archivos se generan a disco y se despliegan con la aplicación tal cual.
- XamlAppDef: se usa para indicar que un archivo .xaml contiene una definición de clase y que se debe compilar. Este valor suele dar problemas cuando se usan archivos .xaml para definir flujos de trabajo con Windows Workflow Foundation, en cuyo caso conviene cambiarlo a otro valor.
- Fakes: este valor está relacionado con el framework para creación de prototipos (Mocks) en testeo unitario de aplicaciones denominado Microsoft Fakes y que fue introducido en Visual Studio 2012. Los archivos con extensión .fake llevan por defecto este valor para indicar que son clases “falsas” usadas para sustentar las pruebas unitarias.
Lo cierto es que sobre algunos de estos valores no hay apenas información por parte de Microsoft, así que espero que al menos este artículo te sirva para saber por donde pisas.