Ik heb een project dat de volgende fout genereert bij het compileren:
fout CS0579: Dubbel ‘AssemblyVersion’-kenmerk
Ik heb het bestand AssemblyInfo.csgecontroleerd en het lijkt erop dat daar geen duplicatie is.
Ik vond dit artikel op MSDNdie een soortgelijk probleem aanpakt en het volgen van de suggestie in dit artikel lost het probleem ook op.
Kan iemand me vertellen wat hier aan de hand is? Gebeurt het alleen in het geval van twee of meer projecten met klassen met vergelijkbare namen? Of is het iets anders?
Antwoord 1, autoriteit 100%
Vanaf Visual Studio 2017is een andere oplossing om het bestand AssemblyInfo.cste blijven gebruiken, het automatisch genereren van assemblagegegevens als volgt uit te schakelen:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
</Project>
Persoonlijk vind ik het erg handig voor projecten die zowel .NET Framework als .NET Standard moeten ondersteunen.
Antwoord 2, autoriteit 62%
Ik ben in het verleden ook tegen dit probleem aangelopen, dus ik ga ervan uit dat je bouwproces assemblage-informatie apart van versiebeheer levert. En dat veroorzaakt een duplicatie omdat uw project die informatie ook in het bestand AssemblyInfo.csheeft. Dus verwijder het bestand en ik denk dat het zou moeten werken.
Antwoord 3, autoriteit 8%
Bij het converteren van een ouder project naar .NET Core, kan de meeste informatie in de AssemblyInfo.cs nu worden ingesteld op het project zelf. Open de projecteigenschappen en selecteer het tabblad Pakket om de nieuwe instellingen te zien.
Het bericht van Eric L. Anderson
“Duplicaat ‘System.Reflection.AssemblyCompanyAttribute’ attribuut”beschrijft 3 opties:
- verwijder de conflicterende items uit het bestand AssemblyInfo.cs,
- het bestand volledig verwijderen of
- schakel GenerateAssemblyInfo uit (zoals voorgesteld in een ander antwoord van Serge Semenov)
Antwoord 4, autoriteit 8%
Ik had dezelfde fout en het onderstreepte de Assembly Vesrion en Assembly File Version, dus toen ik het antwoord van Luqi las, heb ik ze gewoon als opmerkingen toegevoegd en de fout was opgelost
// 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")]
Antwoord 5, autoriteit 7%
In mijn geval was er een submap in een project die zelf een projectmap was:
-
bestandssysteem:
- c:\projects\webapi\wepapi.csproj
- c:\projects\webapi\tests\wepapitests.csproj
-
oplossing
- webapi (map en project)
- tests (map)
- tests (map en project)
- webapi (map en project)
Vervolgens moest ik de submap “tests” uit het “webapi”-project verwijderen.
Antwoord 6, autoriteit 4%
In mijn geval zijn enkele tijdelijke *.cs-bestanden die tijdens het compileren zijn gegenereerd, per ongeluk aan het project toegevoegd.
De bestanden kwamen uit de obj\Debugdirectory, dus ze hadden absoluut niet aan de oplossing moeten worden toegevoegd. Een wildcard *.cswerd een beetje gek en voegde ze verkeerd toe.
Het verwijderen van deze bestanden loste het probleem op.
Antwoord 7, autoriteit 3%
Er moet hier al een AssemblyInfo.cs-bestand in het project aanwezig zijn:
Oplossen:
– Verwijder een willekeurige AssemblyInfo.cs
Antwoord 8, autoriteit 2%
Ik kwam hetzelfde tegen toen ik probeerde GitVersion-tool toe te voegen om mijn versie bij te werken in AssemblyInfo.cs. Gebruik VS2017 en .NET Core-project. Dus ik heb gewoon beide werelden gemengd. Mijn AssemblyInfo.cs bevat alleen versie-informatie die is gegenereerd door de GitVersion-tool, mijn csproj bevat resterende dingen. Houd er rekening mee dat ik <GenerateAssemblyInfo>false</GenerateAssemblyInfo>niet gebruik. Ik gebruik alleen kenmerken met betrekking tot versie (zie hieronder). Meer details hier AssemblyInfo-eigenschappen.
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.csprojbevat alles gerelateerd aan andere assembly-attributen:
<PropertyGroup>
...
<Company>SOME Company </Company>
<Authors>Some Authors</Authors>
<Product>SOME Product</Product>
...
<GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
<GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
<GenerateAssemblyInformationalVersionAttribute>false</GenerateAssemblyInformationalVersionAttribute>
</PropertyGroup>
Antwoord 9
Voor mij was het dat AssembyInfo.cs en SolutionInfo.cs verschillende waarden hadden. Controleer dus ook deze bestanden. Ik heb zojuist de versie van een van hen verwijderd.
Antwoord 10
Mijn fout deed zich voor omdat er op de een of andere manier een obj-map was gemaakt in mijn controllers-map. Zoek gewoon in uw toepassing naar een regel in uw Assemblyinfo.cs. Er kan ergens een duplicaat zijn.
Antwoord 11
Nog een andere oplossing bij het upgraden van core naar VS2017 is om ze te verwijderen in het bestand properties\assemblyinfo.cs.
Sinds ze nu worden opgeslagen in het project.
Antwoord 12
Dit gebeurt meestal voor mij als ik het project in Visual Studio 2017 & dan probeer ik & voer het uit met .NET Core met de opdrachtregelopdracht “dotnet run”.
Gewoon alle “bin” & “obj” mappen – zowel binnen “ClientApp” & direct in de projectmap – stond het .NET Core-commando “dotnet run” toe om & succesvol uitgevoerd.
Antwoord 13
Ik kwam dit onlangs tegen zonder wijzigingen in de bron, maar na te hebben geëxperimenteerd met enkele nieuwe projectreferenties. Ik kwam in een staat terecht waarin deze fout verscheen, zelfs nadat ik alle wijzigingen in de vertakking had teruggedraaid.
Het schoonmaken van de tak loste het voor mij op:
git clean -xfd
Antwoord 14
U kunt de bestanden binen objverwijderen en de cache van het project wissen. Vanaf dat moment was mijn probleem opgelost.
Antwoord 15
Ik vond dit antwoord op msdn, dat verklaart het bestand te markeren als inhoud en vervolgens te kopiëren naar uitvoer = indien nieuwer. Zie artikel hieronder:
GH
Antwoord 16
Ik kreeg deze foutmelding toen ik 2 projecten in dezelfde map plaatste. Als ik een map heb met een oplossing en ik zet er een aparte web- en gegevensmap in, dan compileert het goed.
Antwoord 17
Ik had dit probleem toen mijn hoofdproject in dezelfde map stond als de oplossing, ik had toen een apart project in dezelfde oplossing in een submap en dat aparte project gebruikte het hoofdproject als referentie. Dit zorgde ervoor dat het hoofdproject de submap bin & obj-mappen die dubbele referenties hebben gemaakt.
Antwoord 18
Als u dit probleem ondervindt in een Build Pipeline op Azure DevOps, probeer dan de Build Action als ‘Content’ en Copy to Output Directory gelijk aan ‘Copy if newer’ in de AssembyInfo.cs-bestandseigenschappen te zetten.
Antwoord 19
Als u een projectmaakt, stelt Visual Studio het in om & genereer een overeenkomstige assemblage. Elk project genereert 1 assemblage, en dus heeft elk een corresponderende assemblageconfiguratieom de assemblage van te genereren.
Het probleem is wanneer u meer dan één projectmaakt waarvan elk hun eigen assembly kan genereren, en vervolgens een van deze projecten in het andere opneemt.
In dit scenario raakt Visual Studio in de war en weet niet welk configuratiebestand moet worden gebruikt om de enkele assembly voor het projectte genereren — het vindt de tweede assembly-configuratie in de inbegrepenproject en zegt “HEY, DUPLICATE! Je hebt me twee sets instructies gegeven voor het genereren van mijn assembly!”
Maar soms wil je nog steeds dat het inbegrepenproject op zichzelf een assembly kan genereren, maar niet wanneer het wordt opgenomen in een ander project.
Om dit te verkrijgen, is een oplossing om voorwaardelijke definities toe te voegen aan het inclusiefproject (te vinden in projecteigenschappen). Wijzig vervolgens de configuratie van de assembly in het meegeleverde-project om naar deze voorwaardelijke definitie te zoeken. Als het is gedefinieerd (door het inclusiefproject), dan kan de configuratie de inhoud overslaan — dit zal resulteren in slechts 1 configuratie gevonden door VS — die van de inclusiefem>project — probleem opgelost!
Antwoord 20
Mijn fout was dat ik ook verwees naar een ander bestand in mijn project, dat ook een waarde voor het attribuut “AssemblyVersion” bevatte. Ik heb dat kenmerk uit een van de bestanden verwijderd en het werkt nu naar behoren.
De sleutel is om ervoor te zorgen dat deze waarde niet meer dan één keer wordt gedeclareerd in een bestand in uw project.
Antwoord 21
Bewerk je AssemblyInfo.cs en #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
Antwoord 22
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]
Ik geloof dat mijn bibliotheekmap is beschadigd door het per ongeluk aanmaken van een andere klassenbibliotheek. Ik heb de bibliotheek en alle bijbehorende bestanden verwijderd, maar het probleem bleef bestaan. Ik vond een oplossing door ALLE bin- en obj-mappen in de map te verwijderen. De build was eerder ok, maar vond een submap met hetzelfde assemblyinfo.cs-bestand.
Antwoord 23
Dit probleem is een referentieconflict dat vooral kenmerkend is voor VS 2017.
Ik heb dezelfde fout opgelost door simpelweg de regels 7 -14 en de Assembly-versiecodes onderaan de pagina op AssemblyInfo.cs te becommentariëren
Het heeft alle dubbele referenties verwijderd en het project kon opnieuw worden opgebouwd.
Antwoord 24
Ik kreeg de fout net na het overschakelen van .NET Framework naar .NET Core. Ik heb 2 klassenbibliotheekprojecten in mijn Visual Studio-oplossing. Ik realiseerde me dat 1 van de projecten een bestand heeft met de naam AssemblyInfo.csterwijl het andere project het bestand niet heeft. Het bestand bevindt zich onder de map Properties. Ik verwijder gewoon de map Eigenschappen en alles werkt prima.
Antwoord 25
Ik heb moeite met dit probleem, maar mijn probleem was veel gemakkelijker op te lossen.
Ik had de OBJ-map gekopieerd naar de naam “OBJ___” om enkele compilatietests uit te voeren.
Dus, ik weet niet waarom, deze map werd ook gecompileerd, waardoor de assembly-attributen duplicatie werden gecreëerd.
Ik heb gewoon de map “OBJ___” verwijderd en kon met succes compileren.
Antwoord 26
Ik heb zojuist een teamlid geholpen dit probleem op te lossen door de repo-map te hernoemen en de repo opnieuw te klonen. Dit was slechts een probleem voor één ontwikkelaar, aangezien alle anderen in het team masterkonden bouwen zonder deze fout te krijgen, dus we wisten dat het probleem geen bronprobleem was.
We hebben geprobeerd de bin- en obj-mappen te verwijderen en een git clean -xfduit te voeren, maar geen van beide loste het probleem op. Opnieuw beginnen met een schone kopie van de repo was in dit geval voldoende.
Antwoord 27
Ik worstel ook met dit probleem.
In mijn geval had ik de oplossing en het project op dezelfde plaats gezet. Dus ik had een probleem. Nadat ik een map voor de oplossing had gekozen en het project in deze oplossing had geplaatst, werkte het naar behoren.
Antwoord 28
In mijn geval had een van mijn collega’s een console-app verwijderd die voor testdoeleinden werd gebruikt, die in dezelfde map als onze API was geplaatst en vervolgens werd vastgelegd in Git.
Toen ik later uit Git trok, was de console-app zelf natuurlijk verdwenen, maar de bin en obj-mappen waren er nog steeds, wat ertoe leidde dat het bestand AssemblyInfo.cs aanwezig was in zowel de hoofdmap van de applicatie als de subdir voor de oude console-app. Door simpelweg de bin- en obj-mappen voor de oude console-app te verwijderen, is het probleem opgelost.
ASP.NET CORE 3.1
Antwoord 29
Ik heb deze fouten omdat ik probeerde de OBJ-map tijdelijk te hernoemen tot obj_, en dan is het automatisch in het project opgenomen. Dan begonnen de assembly.cs erin te vechten met de juiste in Obj-map die later werd gegenereerd.
Antwoord 30
Voor iemand anders die dit probleem inloopt, diagnosteerde ik het voor een collega, die beweerde dat ze niets had gewijzigd, maar wie het bleek dat het per ongeluk een codemap had gekopieerd en het niet had gerealiseerd. Dus dat was leuk om erachter te komen.
Les: neem aan dat iedereen ligt.