Zduplikowany atrybut AssemblyVersion

147

Mam projekt, który generuje następujący błąd podczas kompilacji:

błąd CS0579: zduplikowany atrybut „AssemblyVersion”

Sprawdziłem plik AssemblyInfo.csi wygląda na to, że nie ma tam duplikatów.

Znalazłem ten artykuł w witrynie MSDN, który dotyczy podobnego problemu, a zastosowanie się do sugestii z tego artykułu rozwiązuje również problem.

Czy ktoś może mi powiedzieć, co się tutaj dzieje? Czy dzieje się tak tylko w przypadku posiadania dwóch lub więcej projektów z klasami o podobnych nazwach? A może to coś innego?

Aamir
źródło
tylko zgadywanie, ale czy próbowałeś zamknąć i ponownie otworzyć rozwiązanie? może to mogłoby to rozwiązać?
Stefto
4
Jeśli konwertujesz projekt na .NET Core, zobacz elanderson.net/2017/06/ ...
Michael Freidgeim
Używam Visual Studio 2017 Community Edition na komputerze Mac. Miałem aplikację konsolową, a następnie dodałem odniesienie do nowego projektu biblioteki klas. Te błędy zaczęły się pojawiać, kiedy tworzyłem kompilację. Wszystko, co zrobiłem, to usunięcie odniesienia do projektu biblioteki klas, a następnie dodanie go z powrotem, a błędy zniknęły.
Flea

Odpowiedzi:

127

W przeszłości napotkałem również ten problem, więc zamierzam założyć, że proces kompilacji dostarcza informacje o zestawie oddzielnie, aby zapewnić wersjonowanie. A to powoduje duplikację, ponieważ Twój projekt również zawiera te informacje w AssemblyInfo.cspliku. Więc usuń plik i myślę, że powinien działać.

luqi
źródło
3
Czy zatem proces kompilacji nie powinien nadpisywać istniejącej wersji AssemblyVersion zamiast tworzyć nowy wpis? Wiem, że robi to nasz proces kompilacji, ale jestem ciekawy, dlaczego nie zastępuje istniejącego. Czy jest źle wdrożony, czy jest ograniczeniem?
Aamir,
Myślę, że dla zestawów .net lepszym sposobem byłoby użycie metody wstrzykiwania wersji. Ale to osobna historia. W twoim przypadku problem polega na tym, że istnieją różne sposoby dostarczania wersji asemblera, poprzez parametry kompilacji cmdline i przez AssemblyInfo.cs i musisz upewnić się, że tylko jedna metoda jest używana jako duplikacja atrybutów, jest błędem kompilacji .net.
luqi,
co dokładnie usunąć?
roberto tomás
193

Począwszy od programu Visual Studio 2017 innym rozwiązaniem umożliwiającym dalsze korzystanie z AssemblyInfo.cspliku jest wyłączenie automatycznego generowania informacji o zestawie w następujący sposób:

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

Osobiście uważam, że jest to bardzo przydatne w projektach, które wymagają wsparcia zarówno .NET Framework, jak i .NET Standard.

Serge Semenov
źródło
4
Tak, to zadziałało, usunięcie folderów obj i bin nie wystarczyło.
Nick Josevski
Niestety, za każdym razem zmienić .csprojplik za pomocą swoich stron właściwości (zgłoszenie, budować, budować Wydarzenia, itp), przy czym PropertyGroupz GenerateAssemblyInfoznika :-(
Palo Mraz
3
Przenieś go do pliku Directory.Build.props
Bryan,
2
Czy takie rozwiązanie wiąże się z ryzykiem lub negatywnym skutkiem?
mrcoulson
Doskonale rozwiązałem mój problem!
Daniel Maclean
19

Miałem ten sam błąd i to było podkreślanie wersji Assembly Vesrion i Assembly File, więc czytając odpowiedź Luqi, po prostu dodałem je jako komentarze i błąd został rozwiązany

// 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")]
Pantelitsa Mavrovounioti
źródło
Próbowałem tego i nic to nie zmieniło w moim przypadku :-(
Gertsen
18

Podczas konwertowania starszego projektu na .NET Core większość informacji, które znajdowały się w AssemblyInfo.cs, można teraz ustawić w samym projekcie. Otwórz właściwości projektu i wybierz kartę Pakiet, aby wyświetlić nowe ustawienia.

W poście Erica L. Andersona „Duplicate 'System.Reflection.AssemblyCompanyAttribute'” opisano 3 opcje:

  • usunąć sprzeczne elementy z pliku AssemblyInfo.cs,
  • całkowicie usuń plik lub
  • wyłącz GenerateAssemblyInfo (jak sugeruje w innej odpowiedzi Serge Semenov )
Michael Freidgeim
źródło
Uważam, że określenie tych atrybutów w projekcie ( .csproj) jest bardziej intuicyjne i bardziej „Visual Studio” , ponieważ są one metadanymi, a nie kodem opisującym rzeczywistą logikę. Mam nadzieję, że w przyszłości wszystko da się określić w projekcie! (Obecnie nie mogę określić widoczności COM, więc zostawiam to AssemblyInfo.cs.)
Franklin Yu,
9

W moim przypadku niektóre tymczasowe pliki * .cs wygenerowane podczas kompilacji zostały przypadkowo dodane do projektu.

Pliki pochodziły z obj\Debugkatalogu, więc zdecydowanie nie powinno się ich dodawać do rozwiązania. *.csWieloznaczny poszedł trochę szalony i dodaje je nieprawidłowo.

Usunięcie tych plików rozwiązało problem.

Nate Barbettini
źródło
9

W moim przypadku tam, gdzie podfolder w projekcie, który sam był folderem projektu:

  • system plików:

    • c: \ projekty \ webapi \ wepapi.csproj
    • c: \ projects \ webapi \ tests \ wepapitests.csproj
  • rozwiązanie

    • webapi (folder i projekt)
      • testy (folder)
    • testy (folder i projekt)

Następnie musiałem usunąć podfolder „testy” z projektu „webapi”.

Heringer
źródło
4

Dla mnie było to, że AssembyInfo.cs i SolutionInfo.cs miały różne wartości. Więc sprawdź również te pliki. Właśnie usunąłem wersję z jednego z nich.

Mariusz W.
źródło
3

Mój błąd wystąpił, ponieważ w jakiś sposób w folderze moich kontrolerów został utworzony folder obj. Po prostu wyszukaj w swojej aplikacji wiersz w pliku Assemblyinfo.cs. Gdzieś może być duplikat.

Dwayne Love
źródło
Podobnie miałem plik .csproj (A) w innym folderze należącym do innego .csproj (B).
taylorswiftfan
2

Zwykle dzieje się tak, gdy skompilowałem projekt w programie Visual Studio 2017, a następnie próbuję go przebudować i uruchomić z .NET Core za pomocą polecenia wiersza polecenia „dotnet run”.

Po prostu usunięcie wszystkich folderów „bin” i „obj” - zarówno w „ClientApp”, jak i bezpośrednio w folderze projektu - umożliwiło pomyślne odtworzenie i uruchomienie polecenia .NET Core „dotnet run”.

William
źródło
2

W projekcie musi już istnieć plik AssemblyInfo.cs: wprowadź opis obrazu tutaj

Aby rozwiązać: - Usuń dowolny plik AssemblyInfo.cs

Tejas Katakdhond
źródło
1

Jeszcze innym rozwiązaniem w przypadku aktualizacji rdzenia do VS2017 jest usunięcie ich w pliku properties \ assemblyinfo.cs.

Ponieważ są teraz przechowywane w projekcie.

Thomas Koelle
źródło
1

Natknąłem się na to samo, gdy próbowałem dodać narzędzie GitVersion, aby zaktualizować moją wersję w AssemblyInfo.cs. Użyj projektu VS2017 i .NET Core. Więc po prostu zmieszałem oba światy. Moje AssemblyInfo.cs zawiera tylko informacje o wersji, które zostały wygenerowane przez narzędzie GitVersion, mój csproj zawiera pozostałe rzeczy. Pamiętaj, że nie używam <GenerateAssemblyInfo>false</GenerateAssemblyInfo>atrybutów związanych tylko z wersją (patrz poniżej). Więcej szczegółów tutaj Właściwości AssemblyInfo .

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 zawiera wszystkie powiązane z innymi atrybutami assemblera:

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

csproj mapuje na kartę pakietu we właściwościach projektu

Alezis
źródło
1

Miałem ten problem, gdy mój główny projekt znajdował się w tym samym folderze co rozwiązanie, a następnie miałem oddzielny projekt w tym samym rozwiązaniu znajdujący się w podfolderze, a ten oddzielny projekt używał głównego projektu jako odniesienia. To spowodowało, że główny projekt wykrył podfoldery bin & obj foldery, które utworzyły zduplikowane odniesienia.

Mark Entingh
źródło
To mi bardzo pomogło! Jeden projekt odwoływał się do innego jako zależność w czasie kompilacji, ale błąd w csproj spowodował, że foldery obj były inne, generując ten błąd.
Chad Jessup
0

Mój błąd polegał na tym, że odwoływałem się również do innego pliku w moim projekcie, który również zawierał wartość atrybutu „AssemblyVersion”. Usunąłem ten atrybut z jednego z plików i teraz działa poprawnie.

Kluczem jest upewnienie się, że ta wartość nie jest zadeklarowana więcej niż raz w żadnym pliku w projekcie.

Antoine Dijoux
źródło
0

Edytuj AssemblyInfo.cs i #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
Sourcephy
źródło
0

Otrzymałem ten błąd, gdy umieściłem 2 projekty w tym samym katalogu. Jeśli mam katalog z rozwiązaniem i umieszczam w nim osobny katalog Web and Data, kompiluje się dobrze.

Herman Van Der Blom
źródło
0

Jeśli masz ten problem w potoku kompilacji w usłudze Azure DevOps, spróbuj ustawić akcję kompilacji jako „Zawartość” i Kopiuj do katalogu wyjściowego równą „Kopiuj, jeśli nowsza” we właściwościach pliku AssembyInfo.cs.

Marcello Teófilo Fonteles
źródło
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]

Uważam, że mój folder biblioteki został uszkodzony przez nieumyślne utworzenie innej biblioteki klas. Usunąłem bibliotekę i wszystkie skojarzone z nią pliki, ale problem nadal występował. Znalazłem obejście, usuwając WSZYSTKIE foldery bin i obj w katalogu. Kompilacja poprzednio przebiegała prawidłowo, ale znaleziono podfolder zawierający ten sam plik assemblyinfo.cs.

John Flurkey
źródło
0

Ten problem jest konfliktem odniesień, który jest głównie charakterystyczny dla VS 2017.

Rozwiązałem ten sam błąd, po prostu wykomentowując wiersze 7-14, a także kody wersji zestawu na dole strony AssemblyInfo.cs

Usunięto wszystkie zduplikowane odniesienia i projekt był w stanie ponownie zbudować.

Adeakinwe
źródło