2008-09-15 13 views
148

Tengo una solución con proyecto múltiple. Estoy tratando de optimizar los archivos AssemblyInfo.cs vinculando un archivo de información de conjunto de una solución amplia. ¿Cuáles son las mejores prácticas para hacer esto? ¿Qué atributos deberían estar en un archivo de solución amplia y cuáles son específicos del proyecto/ensamblaje?¿Cuáles son las mejores prácticas para usar los atributos de ensamblaje?


Editar: Si está interesado hay una pregunta de seguimiento What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion?

Respuesta

194

Estamos utilizando un archivo global llamado GlobalAssemblyInfo.cs y uno local llamado AssemblyInfo.cs. El archivo global contiene los siguientes atributos:

[assembly: AssemblyProduct("Your Product Name")] 

[assembly: AssemblyCompany("Your Company")] 
[assembly: AssemblyCopyright("Copyright © 2008 ...")] 
[assembly: AssemblyTrademark("Your Trademark - if applicable")] 

#if DEBUG 
[assembly: AssemblyConfiguration("Debug")] 
#else 
[assembly: AssemblyConfiguration("Release")] 
#endif 

[assembly: AssemblyVersion("This is set by build process")] 
[assembly: AssemblyFileVersion("This is set by build process")] 

Los AssemblyInfo.cs local contiene los siguientes atributos:

[assembly: AssemblyTitle("Your assembly title")] 
[assembly: AssemblyDescription("Your assembly description")] 
[assembly: AssemblyCulture("The culture - if not neutral")] 

[assembly: ComVisible(true/false)] 

// unique id per assembly 
[assembly: Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx")] 

puede agregar el GlobalAssemblyInfo.cs mediante el siguiente procedimiento:

  • Seleccione Agregar/elemento existente ... en el menú contextual del proyecto
  • Seleccionar GlobalAssemblyInfo.cs
  • Expandir el complemento botón haciendo clic en la pequeña flecha hacia abajo a la derecha
  • Seleccione "añadir como Enlace" en los botones de la lista desplegable
+0

¿Cuál es el propósito de mantener los archivos antiguos de AssemblyInfo.cs? Cuando automatizo mi sello de versión de compilación en GlobalAssemblyInfo.cs, ¿cómo actualiza los archivos AssemblyInfo.cs que tengo en mi solución? – D3vtr0n

+3

@Devtron Los archivos individuales de AssemblyInfo deben proporcionar información exclusiva del ensamblaje en el que residen (por ejemplo, título, descripción y cultura, como en el ejemplo anterior). Las entradas comunes, como el nombre del producto y la información de versiones deben eliminarse (y causarán un error del compilador si están duplicadas). Lo ideal es que el proceso de compilación no actualice los archivos de AssemblyInfo. –

+2

^Correcto. Desde entonces lo he descubierto a través de prueba y error. Un poco ingenioso y genial :) – D3vtr0n

1

Uso de un archivo AseemblyInfo.cs individuales para múltiples proyectos no se recomienda. El archivo AssemblyInfo incluye información que podría ser relevante solo para ese ensamblaje específico. Las dos piezas de información más obvias son AssemblyTitle y AssemblyVersion.

Una mejor solución podría ser utilizar el archivo targets, que son manejados por MSBuild, para "inyectar" atributos de ensamblaje a más de un proyecto.

+0

¿y si tienes más de 20 proyectos? Eso requiere que mantenga más de 20 entradas en mi configuración de compilación, solo para control de versiones. Eso parece realmente cojo ¿Qué sucede si agrego 2 o 3 proyectos nuevos? Eso definitivamente romperá el proceso de construcción ... ¿Alguna idea de cómo solucionar eso? – D3vtr0n

+0

@ D3vtr0n Creo que la idea es generar el ensamblaje relevate dinámicamente y no mantener configuraciones individuales para cada proyecto. Las Tareas Comunitarias, creo, manejan ese caso. – Roman

3

Para compartir un archivo entre proyectos múltiples puede agregar un archivo existente como un enlace.

Para hacer esto, agregue un archivo existente y haga clic en "Agregar como enlace" en el selector de archivos. Add As Link http://laurent.etiemble.free.fr/dotclear/images/AddLinkedFile03_tn.png

En cuanto a qué poner en el archivo compartido, sugeriría poner elementos que se compartirían entre los ensamblados. Cosas como copyright, compañía, quizás versión.

15

En mi caso, estamos creando un producto para el que tenemos una solución de Visual Studio, con varios componentes en sus propios proyectos. Los atributos comunes van. En la solución, hay cerca de 35 proyectos, y un montaje de información común (CommonAssemblyInfo.cs), que tiene los siguientes atributos:

[assembly: AssemblyCompany("Company")] 
[assembly: AssemblyProduct("Product Name")] 
[assembly: AssemblyCopyright("Copyright © 2007 Company")] 
[assembly: AssemblyTrademark("Company")] 

//This shows up as Product Version in Windows Explorer 
//We make this the same for all files in a particular product version. And increment it globally for all projects. 
//We then use this as the Product Version in installers as well (for example built using Wix). 
[assembly: AssemblyInformationalVersion("0.9.2.0")] 

Los otros atributos tales como AssemblyTitle, AssemblyVersion etc., suministramos en un per- base de montaje. Al construir un ensamblado, tanto AssemblyInfo.cs como CommonAssemblyInfo.cs están integrados en cada ensamblaje. Esto nos brinda lo mejor de ambos mundos, donde es posible que desee tener algunos atributos comunes para todos los proyectos y valores específicos para algunos otros.

Espero que ayude.

+0

¿Tiene más de 35 entradas en su configuración de compilación para manejar esto? Parece bastante redundante. ¿Qué sucede si agrega 2 o 3 proyectos nuevos, eso rompe su construcción hasta que los agregue a la tarea de control de versiones? – D3vtr0n

+1

@ D3vtr0n, ¿por qué una "configuración de compilación" (qué quiere decir con eso) necesita tantas entradas? Supongo que este archivo está incluido en cada .csproj a través de '', una directiva MSBuild que incluso puede estar en un archivo 'Common.targets' compartido . Yay código de reutilización. – binki

8

MSBuild Community Tasks contiene una tarea personalizada llamada AssemblyInfo que puede usar para generar su assemblyinfo.cs. Requiere una pequeña edición manual de sus archivos csproj para usar, pero vale la pena.

12

La solución presentada por @JRoppert es casi la misma que yo. La única diferencia es que puse las siguientes líneas en el archivo AssemblyInfo.cs locales, ya que pueden variar con cada montaje:

#if DEBUG 
[assembly: AssemblyConfiguration("Debug")] 
#else 
[assembly: AssemblyConfiguration("Release")] 
#endif 
[assembly: AssemblyVersion("This is set by build process")] 
[assembly: AssemblyFileVersion("This is set by build process")] 
[assembly: CLSCompliant(true)] 

también (por lo general) usar una información ensamblaje común por la solución, con la suposición de que uno la solución es una sola línea de producto/producto liberable. El montaje de archivo de información común también tiene:

[assembly: AssemblyInformationalVersion("0.9.2.0")] 

que permitirá establecer el valor "ProductVersion" mostrada por el Explorador de Windows.

4

En mi opinión, usar GlobalAssemblyInfo.cs es más problemático de lo que vale, porque necesita modificar cada archivo de proyecto y no olvide modificar cada nuevo proyecto, mientras que obtiene un AssemblyInfo.cs por defecto.

Para los cambios en los valores globales (es decir, empresa, producto, etc.) los cambios suelen ser tan infrecuentes y fáciles de administrar que no creo que DRY sea una consideración. Sólo tiene que ejecutar el siguiente script MSBuild (dependiente de la MSBuild Extension Pack) cuando se desea cambiar manualmente los valores en todos los proyectos como un hecho aislado:

<?xml version="1.0" encoding="utf-8"?> 
<Project ToolsVersion="4.0" DefaultTargets="UpdateAssemblyInfo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> 

    <ItemGroup> 
     <AllAssemblyInfoFiles Include="..\**\AssemblyInfo.cs" /> 
    </ItemGroup> 

    <Import Project="MSBuild.ExtensionPack.tasks" /> 

    <Target Name="UpdateAssemblyInfo"> 
    <Message Text="%(AllAssemblyInfoFiles.FullPath)" /> 
    <MSBuild.ExtensionPack.Framework.AssemblyInfo 
     AssemblyInfoFiles="@(AllAssemblyInfoFiles)" 
     AssemblyCompany="Company" 
     AssemblyProduct="Product" 
     AssemblyCopyright="Copyright" 
     ... etc ... 
     /> 
    </Target> 

</Project> 
1

Una cosa que he encontrado útil es para generar los elementos AssemblyVersion (etc.) mediante la aplicación de sustitución de token en la fase previa a la construcción.

Yo uso TortoiseSvn, y es fácil de usar su SubWCRev.exe para convertir una plantilla AssemblyInfo.wcrev en AssemblyInfo.cs. La línea relevante en la plantilla puede verse más o menos así:

[assembly: AssemblyVersion("2.3.$WCREV$.$WCMODS?1:0$$WCUNVER?1:0$")] 

El tercer elemento es el número de revisión. Utilizo el cuarto elemento para comprobar que no he olvidado confirmar ningún archivo nuevo o modificado (el cuarto elemento es 00 si todo está bien).

Por cierto, agregue AssemblyInfo.wcrev a su control de versión y ignoreAssemblyInfo.cs si utiliza esto.

Cuestiones relacionadas