Duplicar AssemblyVersion Atributo

Tengo un proyecto que genera siguiente error en la compilación:Duplicar AssemblyVersion Atributo

CS0579 de error: atributo duplicado 'AssemblyVersion'

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

Encontré this article on MSDN que soluciona un problema similar y siguiendo la sugerencia en este artículo soluciona el problema también.

¿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?

Fuente

2012-04-25 Aamir

solo una conjetura pero, ¿intentó cerrar y abrir nuevamente la solución? quizás eso podría resolverlo? – Stefto

Si convierte un proyecto a .NET Core, consulte https://elanderson.net/2017/06/duplicate-system-reflection-assemblycompanyattribute-attribute/ –

Como también he tenido este problema en el pasado, asumo que su proceso de compilación también proporciona información de ensamblaje por separado para proporcionar el control de versiones. Y eso causa una duplicación ya que su proyecto también tiene esa información en el archivo AssembleyInfo.cs. Así que elimine el archivo y creo que debería funcionar.

Fuente

2012-04-25 09:15:12 luqi

Por lo tanto, el proceso de construcción no debería sobrescribir la versión de montaje existente en lugar de crear una nueva ¿entrada? Sé que nuestro proceso de compilación lo hace, pero tengo curiosidad de 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 maneras de proporcionar versiones de ensamblado, a través de los parámetros de compilación de cmdline y mediante AssemblyInfo.cs, y debe asegurarse de que solo se utilice un método, ya que la duplicación de atributos es un error de compilación de .net. – luqi

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

Fuente

2014-01-17 12:15:58

que tenían el mismo error y se sirven de fundamento al vesrion y Asamblea Asamblea la versión del archivo de modo de leer la respuesta Luqi Sólo les añade como comentarios y el error fue resuelto

// 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")]

Fuente

2015-06-25 21:46:48

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

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

Al eliminar estos archivos se solucionó el problema.

Fuente

2016-02-26 00:56:34

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 está funcionando correctamente.

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

Fuente

2017-03-16 10:38:54

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 encontrar una línea dentro de su Assemblyinfo.cs. Puede haber un duplicado en alguna parte.

Fuente

2017-03-23 16:09:07

A partir de Visual Studio 2017 otra solución que seguir usando el archivo AssemblyInfo.cs es apagar la generación automática de información de montaje de esta manera:

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

Personalmente me parece muy útil para proyectos que deben soportar tanto .NET Framework y .NET Standard.

Fuente

2017-06-12 15:05:17

Sí, eso funcionó para mí, borrar las carpetas obj y bin no fue suficiente. –

Desafortunadamente, cada vez que cambio el archivo '.csproj' utilizando sus páginas de propiedades (Aplicación, Construir, Crear Eventos, etc.), el' PropertyGroup' con 'GenerateAssemblyInfo' desaparece :-( –

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

El Eric L. Anderson's post "Duplicate ‘System.Reflection.AssemblyCompanyAttribute’ attribute" describe 3 opciones:

eliminar los elementos en conflicto desde el archivo AssemblyInfo.cs,
eliminar por completo el archivo o
desactivar GenerateAssemblyInfo (como se sugiere en another answer by Serge Semenov)

Fuente

2017-09-07 11:57:22

Lo encuentro más intuitivo y más "Visual Studio" para especificar estos atributos en el proyecto ('.csproj'), porque son metadatos en lugar de códigos 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 en 'AssemblyInfo.cs'.) –

Otra solución al actualizar el núcleo a VS2017 es eliminarlos en el archivo properties \ assemblyinfo.cs.

Dado que ahora están almacenados en el proyecto.

Fuente

2017-10-19 07:56:57

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

sistema de archivos:
- c: \ proyectos \ WebAPI \ wepapi.csproj
- c: \ proyectos \ WebAPI \ pruebas \ wepapitests.csproj
solución
- WebAPI (carpeta y del proyecto)
  - pruebas (carpeta)
- pruebas (carpeta y de proyectos)

Luego tuve que quitar la subcarpeta " prueba "del proyecto" webapi ".

Fuente

2017-12-12 12:25:14 heringer

Respuesta

Cuestiones relacionadas