Duplicate AssemblyVersion Attributo

Ho un progetto che genera seguente errore di compilazione:Duplicate AssemblyVersion Attributo

errore CS0579: attributo duplicato 'AssemblyVersion'

Ho verificato il file AssemblyInfo.cs e sembra che non v'è alcuna duplicazione lì.

Ho trovato this article on MSDN che risolve un problema simile e seguendo il suggerimento in questo articolo risolve anche il problema.

Qualcuno può dirmi cosa sta succedendo qui? Succede solo in caso di due o più progetti con classi con nomi simili? O è qualcos'altro?

fonte

2012-04-25 Aamir

solo una supposizione ma, hai provato a chiudere e ad aprire nuovamente la soluzione? forse potrebbe risolverlo? – Stefto

Se si converte un progetto in .NET Core, consultare https://landerson.net/2017/06/duplicate-system-reflection-assemblycompanyattribute-attribute/ –

Dal momento che ho anche avuto questo problema in passato, quindi presumo che il processo di compilazione fornisca anche informazioni di assemblaggio separatamente per fornire il controllo delle versioni. E questo causa una duplicazione poiché il tuo progetto ha anche queste informazioni nel file AssembleyInfo.cs. Quindi rimuovi il file e penso che dovrebbe funzionare.

fonte

2012-04-25 09:15:12 luqi

Quindi, il processo di creazione non deve sovrascrivere la versione Assembly esistente anziché crearne una nuova iscrizione? So che il nostro processo di compilazione lo fa, ma sono curioso di sapere perché non sovrascrive quello esistente. È implementato male o è una limitazione? – Aamir

Penso che per gli assembly .net il modo migliore sarebbe utilizzare il metodo di iniezione della versione. Ma questa è una storia separata. Nel tuo caso il problema è che ci sono diversi modi di fornire versioni di assembly, attraverso i parametri di costruzione di cmdline e attraverso AssemblyInfo.cs e devi assicurarti che sia utilizzato un solo metodo come duplicazione degli attributi è un errore di compilazione .net. – luqi

Per me era che AssembyInfo.cs e SolutionInfo.cs avevano valori diversi. Quindi controlla anche questi file. Ho appena rimosso la versione da uno di essi.

fonte

2014-01-17 12:15:58

Ho avuto lo stesso errore ed è stata sottolineando la vesrion Assemblea e montaggio della versione dei file in modo da leggere Luqi risposta che ho appena li aggiunsi come commenti e l'errore è stato risolto

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

fonte

2015-06-25 21:46:48

Nel mio caso, alcuni cs temporanee * i file generati durante la compilazione sono stati accidentalmente aggiunti al progetto.

I file provenivano dalla directory obj\Debug, quindi sicuramente non avrebbero dovuto essere aggiunti alla soluzione. Una wildcard *.cs è diventata un po 'folle e le ha aggiunte in modo errato.

L'eliminazione di questi file ha risolto il problema.

fonte

2016-02-26 00:56:34

Il mio errore era che stavo anche riferendo un altro file nel mio progetto, che conteneva anche un valore per l'attributo "AssemblyVersion". Ho rimosso quell'attributo da uno dei file e ora funziona correttamente.

La chiave è assicurarsi che questo valore non sia dichiarato più di una volta in qualsiasi file nel progetto.

fonte

2017-03-16 10:38:54

Il mio errore si è verificato perché, in qualche modo, c'era una cartella obj creata all'interno della mia cartella dei controller. Basta fare una ricerca nella tua applicazione per una riga all'interno del tuo Assemblyinfo.cs. Potrebbe esserci un duplicato da qualche parte.

fonte

2017-03-23 16:09:07

A partire da Visual Studio 2017 un'altra soluzione per continuare ad usare il file AssemblyInfo.cs è quello di spegnere la generazione automatica informazioni di montaggio in questo modo:

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

Personalmente trovo molto utile per i progetti che hanno bisogno di supportare sia .NET Framework e .NET Standard.

fonte

2017-06-12 15:05:17

Sì, quello ha funzionato per me, eliminare le cartelle obj e bin non era abbastanza. –

Sfortunatamente, ogni volta che cambio il file '.csproj' usando le sue pagine di proprietà (Application, Build, Build Events, ecc.), Il' PropertyGroup' con 'GenerateAssemblyInfo' scompare :-( –

Quando si converte un progetto precedente in .NET Core, la maggior parte delle informazioni contenute in AssemblyInfo.cs possono ora essere impostate sul progetto stesso. Aprire le proprietà del progetto e selezionare la scheda Pacchetto per vedere le nuove impostazioni.

Il Eric L. Anderson's post "Duplicate ‘System.Reflection.AssemblyCompanyAttribute’ attribute" descrive 3 opzioni:

rimuovere gli elementi in conflitto dal file AssemblyInfo.cs,
cancellare completamente il file o la
disabilitare GenerateAssemblyInfo (come suggerito in another answer by Serge Semenov)

fonte

2017-09-07 11:57:22

Lo trovo più intuitivo e più "Visual Studio" per specificare questi attributi nel progetto ('.csproj'), perché sono metadati anziché codice che descrivono la logica effettiva. Spero che in futuro tutto possa essere specificato nel progetto! (Attualmente non posso specificare la visibilità di COM, quindi lo lascio in 'AssemblyInfo.cs'.) –

Un'altra soluzione quando si aggiorna il core a VS2017 è rimuoverli nel file properties \ assemblyinfo.cs.

Poiché ora vengono memorizzati nel progetto.

fonte

2017-10-19 07:56:57

Nel mio caso, là dove una sottocartella in un progetto che era una cartella di progetto è di per sé:

file system:
- c: \ projects \ WebAPI \ wepapi.csproj
- c: \ progetti \ WebAPI \ test \ wepapitests.csproj
soluzione
- WebAPI (cartella e di progetto)
  - test (cartella)
- test (cartella e progetto)

poi ho dovuto rimuovere la sottocartella " prove "dal progetto" webapi ".

fonte

2017-12-12 12:25:14 heringer

risposta

Problemi correlati