Atributo de versión de ensamblaje duplicado


147

Tengo un proyecto que genera el siguiente error en la compilación:

error CS0579: atributo duplicado 'AssemblyVersion'

He comprobado el archivo AssemblyInfo.csy parece que no hay duplicación allí.

Encontré este artículo en MSDN que aborda un problema similar y, siguiendo la sugerencia de este artículo, también soluciona el problema.

¿Alguien puede decirme qué está pasando aquí? ¿Sucede solo en caso de tener dos o más proyectos con clases con nombres similares? ¿O es otra cosa?


solo una suposición pero, ¿intentaste cerrar y abrir la solución nuevamente? tal vez eso podría resolverlo?
Stefto

44
Si convierte un proyecto a .NET Core, consulte elanderson.net/2017/06/…
Michael Freidgeim

Estoy usando Visual Studio 2017 Community edition en Mac. Tenía una aplicación de consola y luego agregué una referencia a un nuevo proyecto de biblioteca de clases. Estos errores comenzaron a aparecer cuando hice una compilación. Todo lo que hice fue eliminar la referencia al proyecto de la biblioteca de clases y luego volver a agregarla y los errores desaparecieron.
Pulga

Respuestas:


126

También me he encontrado con este problema en el pasado, por lo que voy a suponer que su proceso de compilación proporciona información de ensamblaje por separado para proporcionar versiones. Y eso provoca una duplicación ya que su proyecto también tiene esa información en el AssemblyInfo.csarchivo. Así que elimine el archivo y creo que debería funcionar.


3
Entonces, ¿no debería el proceso de compilación sobrescribir la versión de ensamblaje existente en lugar de crear una nueva entrada? Sé que nuestro proceso de compilación hace eso, pero tengo curiosidad por saber por qué no sobrescribe el existente. ¿Está mal implementado o es una limitación?
Aamir

Creo que para los ensamblados .net, la mejor manera sería usar el método de inyección de versión. Pero esa es una historia separada. En su caso, el problema es que existen diferentes formas de proporcionar versiones de ensamblaje, a través de parámetros de compilación de cmdline y mediante AssemblyInfo.cs, y debe asegurarse de que solo se esté utilizando un método, ya que la duplicación de atributos es un error de compilación .net.
luqi

eliminar qué exactamente?
roberto tomás

193

A partir de Visual Studio 2017, otra solución para seguir usando el AssemblyInfo.csarchivo es desactivar la generación automática de información de ensamblaje de esta manera:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
  </PropertyGroup>
</Project>

Personalmente, lo encuentro muy útil para proyectos que necesitan ser compatibles con .NET Framework y .NET Standard.


44
Sí, eso funcionó para mí, eliminar las carpetas obj y bin no fue suficiente.
Nick Josevski

Por desgracia, cada vez que cambia el .csprojarchivo usando sus páginas de propiedades (de aplicación, urbanizado, Eventos de generación, etc.), la PropertyGroupde los GenerateAssemblyInfodesaparece :-(
Palo Mraz

3
Moverlo a un archivo Directory.Build.props
Bryan

2
¿Existe algún riesgo o resultado negativo posible con esta solución?
mrcoulson

¡Solucioné mi problema perfectamente!
Daniel Maclean

19

Tuve el mismo error y subrayaba la Vesrion de la Asamblea y la Versión del Archivo de la Asamblea, así que leyendo la respuesta de Luqi, simplemente los agregué como comentarios y el error se resolvió

// AssemblyVersion is the CLR version. Change this only when making breaking    changes
//[assembly: AssemblyVersion("3.1.*")]
// AssemblyFileVersion should ideally be changed with each build, and should help identify the origin of a build
//[assembly: AssemblyFileVersion("3.1.0.0")]

Intenté esto, y no cambió nada en mi caso :-(
Gertsen

18

Al convertir un proyecto anterior a .NET Core, la mayoría de la información que estaba en AssemblyInfo.cs ahora se puede configurar en el proyecto mismo. Abra las propiedades del proyecto y seleccione la pestaña Paquete para ver la nueva configuración.

La publicación de Eric L. Anderson "Duplicar 'System.Reflection.AssemblyCompanyAttribute' atributo" describe 3 opciones:

  • eliminar los elementos en conflicto del archivo AssemblyInfo.cs,
  • eliminar completamente el archivo o
  • deshabilitar GenerateAssemblyInfo (como se sugiere en otra respuesta de Serge Semenov )

Me resulta más intuitivo y más "Visual Studio" especificar estos atributos en el proyecto ( .csproj), porque son metadatos en lugar de código que describen la lógica real. ¡Espero que en el futuro todo se pueda especificar en el proyecto! (Actualmente no puedo especificar la visibilidad COM, así que lo dejo AssemblyInfo.cs.)
Franklin Yu

9

En mi caso, algunos archivos temporales * .cs generados durante la compilación se agregaron accidentalmente al proyecto.

Los archivos eran del obj\Debugdirectorio, por lo que definitivamente no deberían haberse agregado a la solución. Un *.cscomodín se volvió un poco loco y los agregó incorrectamente.

Eliminar estos archivos solucionó el problema.


9

En mi caso, allí donde una subcarpeta en un proyecto que era una carpeta de proyecto en sí misma:

  • sistema de archivos:

    • c: \ projects \ webapi \ wepapi.csproj
    • c: \ projects \ webapi \ tests \ wepapitests.csproj
  • solución

    • webapi (carpeta y proyecto)
      • pruebas (carpeta)
    • pruebas (carpeta y proyecto)

Luego tuve que eliminar la subcarpeta "pruebas" del proyecto "webapi".


4

Para mí fue que AssembyInfo.cs y SolutionInfo.cs tenían valores diferentes. Así que revise estos archivos también. Acabo de eliminar la versión de uno de ellos.


3

Mi error ocurrió porque, de alguna manera, había una carpeta obj creada dentro de mi carpeta de controladores. Simplemente haga una búsqueda en su aplicación para una línea dentro de su Assemblyinfo.cs. Puede haber un duplicado en alguna parte.


Del mismo modo, tenía un archivo .csproj (A) dentro de otra carpeta que pertenece a otro .csproj (B).
taylorswiftfan

2

Esto generalmente me sucede si compilé el proyecto en Visual Studio 2017 y luego trato de reconstruirlo y ejecutarlo con .NET Core con el comando de línea de comandos "dotnet run".

Simplemente eliminar todas las carpetas "bin" y "obj", tanto dentro de "ClientApp" como directamente en la carpeta del proyecto, permitió que el comando .NET Core "dotnet run" se reconstruyera y ejecutara con éxito.


2

Ya debe haber un archivo AssemblyInfo.cs en el proyecto aquí: ingrese la descripción de la imagen aquí

Para resolver: - Elimine cualquiera de los AssemblyInfo.cs


1

Otra solución más cuando se actualiza el núcleo a VS2017 es eliminarlos en el archivo properties \ assemblyinfo.cs.

Ya que ahora están almacenados en el proyecto.



1

Encontré lo mismo cuando intenté agregar la herramienta GitVersion para actualizar mi versión en AssemblyInfo.cs. Use VS2017 y .NET Core project. Así que simplemente mezclé ambos mundos. My AssemblyInfo.cs contiene solo información de versión que fue generada por la herramienta GitVersion, mi csproj contiene remaingin things. Tenga en cuenta que no utilizo <GenerateAssemblyInfo>false</GenerateAssemblyInfo>utilizo atributos relacionados solo con la versión (ver más abajo). Más detalles aquí Propiedades de información de ensamblaje .

AssemblyInfo.cs

[assembly: AssemblyVersion("0.2.1.0")]
[assembly: AssemblyFileVersion("0.2.1.0")]
[assembly: AssemblyInformationalVersion("0.2.1+13.Branch.master.Sha.119c35af0f529e92e0f75a5e6d8373912d457818")]

my.csproj contiene todo lo relacionado con otros atributos de ensamblado:

<PropertyGroup>
...
<Company>SOME Company </Company>
<Authors>Some Authors</Authors>
<Product>SOME Product</Product>
...
<GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
<GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute><GenerateAssemblyInformationalVersionAttribute>false</GenerateAssemblyInformationalVersionAttribute>

csproj se asigna a la pestaña del paquete en las propiedades del proyecto


1

Tuve este problema cuando mi proyecto principal estaba en la misma carpeta que la solución, luego tuve un proyecto separado en la misma solución ubicada en una subcarpeta, y ese proyecto separado usó el proyecto principal como referencia. Esto provocó que el proyecto principal detectara las carpetas bin y obj de la subcarpeta que creaban referencias duplicadas.


¡Esto me ayudó mucho! Un proyecto hizo referencia a otro como una dependencia de tiempo de compilación, pero un error en el csproj hizo que las carpetas obj fueran diferentes, generando este error.
Chad Jessup

0

Mi error fue que también estaba haciendo referencia a otro archivo en mi proyecto, que también contenía un valor para el atributo "AssemblyVersion". Eliminé ese atributo de uno de los archivos y ahora funciona correctamente.

La clave es asegurarse de que este valor no se declare más de una vez en ningún archivo de su proyecto.


0

Edite AssemblyInfo.cs y #if! NETCOREAPP3_0 ... #endif

using System.Reflection;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.

#if !NETCOREAPP3_0  

[assembly: AssemblyTitle(".Net Core Testing")]
[assembly: AssemblyDescription(".Net Core")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct(".Net Core")]
[assembly: AssemblyCopyright("Copyright ©")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]

// Setting ComVisible to false makes the types in this assembly not visible
// to COM components.  If you need to access a type in this assembly from
// COM, set the ComVisible attribute to true on that type.
[assembly: ComVisible(false)]

// The following GUID is for the ID of the typelib if this project is exposed to COM
[assembly: Guid("000b119c-2445-4977-8604-d7a736003d34")]

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

#endif

0

Recibí este error cuando puse 2 proyectos en el mismo directorio. Si tengo un directorio con una solución y pongo un directorio web y de datos por separado, se compila correctamente.


0

Si tiene este problema en Build Pipeline en Azure DevOps, intente colocar la Acción de compilación como "Contenido" y Copiar al directorio de salida igual a "Copiar si es más reciente" en las propiedades del archivo AssembyInfo.cs.


0
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(15,12): error CS0579: Duplicate 'System.Reflection.AssemblyConfigurationAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(16,12): error CS0579: Duplicate 'System.Reflection.AssemblyFileVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(17,12): error CS0579: Duplicate 'System.Reflection.AssemblyInformationalVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(18,12): error CS0579: Duplicate 'System.Reflection.AssemblyProductAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(19,12): error CS0579: Duplicate 'System.Reflection.AssemblyTitleAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]
obj\Debug\netstandard2.0\PacktLibrary.AssemblyInfo.cs(20,12): error CS0579: Duplicate 'System.Reflection.AssemblyVersionAttribute' attribute [c:\Users\John_Tosh1\Documents\C#8.0and.NetCore3.0\Code\Chapter05\PacktLibrary\PacktLibrary.csproj]

Creo que mi carpeta de la Biblioteca se corrompió por la creación accidental de otra biblioteca de clases. Eliminé la biblioteca y todos los archivos asociados, pero el problema persistió. Encontré una solución al eliminar TODAS las carpetas bin y obj en el directorio. La compilación estaba bien anteriormente, pero encontró una subcarpeta que tenía el mismo archivo assemblyinfo.cs.


0

Este problema es un conflicto de referencia que es principalmente peculiar de VS 2017.

Resolví este mismo error simplemente comentando las líneas 7 a 14, así como los códigos de versión de ensamblaje en la parte inferior de la página en AssemblyInfo.cs

Eliminó todas las referencias duplicadas y el proyecto pudo volver a construirse.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.