Visual studio повторяющийся атрибут
У меня есть проект, который генерирует следующую ошибку при компиляции:
ошибка CS0579: повторяющийся атрибут AssemblyVersion
Я проверил файл AssemblyInfo.cs и похоже, что там нет дубликатов.
Я нашел эту статью в MSDN, в которой рассматривается аналогичная проблема и следование предложению в этой статье также решает проблему.
Кто-нибудь может сказать мне, что здесь происходит? Это происходит только в случае наличия двух и более проектов с похожими именами классов? Или что-то еще?
23 ответа
Я также сталкивался с этой проблемой в прошлом, поэтому предполагаю, что ваш процесс сборки предоставляет информацию о сборке отдельно от обеспечения управления версиями. И это вызывает дублирование, поскольку в вашем проекте эта информация также содержится в файле AssemblyInfo.cs . Так что удалите файл, и я думаю, он должен работать.
В проекте уже должен быть файл AssemblyInfo.cs:
Чтобы решить: - Удалите любой AssemblyInfo.cs
В моем случае в проект случайно были добавлены временные файлы * .cs, созданные при компиляции.
Файлы были из каталога obj\Debug , поэтому их определенно не следовало добавлять в решение. Подстановочный знак *.cs немного сумасшедший и добавил их неправильно.
Удаление этих файлов устранило проблему.
В моем случае это была подпапка в проекте, которая сама была папкой проекта:
- c: \ projects \ webapi \ wepapi.csproj
- c: \ projects \ webapi \ tests \ wepapitests.csproj
Затем мне пришлось удалить подпапку «тесты» из проекта «webapi».
- удалите конфликтующие элементы из файла AssemblyInfo.cs,
- полностью удалить файл или
- отключить GenerateAssemblyInfo (как предлагается в другом ответе Сергея Семенова)
У меня была такая же ошибка, и в ней подчеркивалась версия сборки и версия файла сборки, поэтому, прочитав ответ Luqi, я просто добавил их в качестве комментариев, и ошибка была решена
Начиная с Visual Studio 2017 , еще одним решением для продолжения использования файла AssemblyInfo.cs является отключение автоматического создания информации о сборке, например:
Я борюсь с этой проблемой, но решить мою проблему было намного проще.
Я скопировал папку OBJ с именем «OBJ___», чтобы провести некоторые тесты компиляции.
Итак, я не знаю, почему, эта папка тоже компилировалась, создавая дублирование атрибутов сборки.
Я просто удалил папку «OBJ___» и смог успешно скомпилировать.
Эта проблема является конфликтом ссылок, который в основном характерен для VS 2017.
Я решил эту же ошибку, просто закомментировав строки 7-14, а также коды версий сборки внизу страницы на AssemblyInfo.cs.
Он удалил все повторяющиеся ссылки, и проект можно было построить снова.
Я считаю, что моя папка библиотеки была повреждена из-за непреднамеренного создания другой библиотеки классов. Я удалил библиотеку и все связанные файлы, но проблема не исчезла. Я нашел обходной путь, удалив ВСЕ папки bin и obj в каталоге. Раньше сборка проходила нормально, но была обнаружена подпапка с тем же файлом assemblyinfo.cs.
Я получил эту ошибку, когда поместил 2 проекта в один каталог. Если у меня есть каталог с решением, и я помещаю в него отдельный каталог Web и Data, он компилируется правильно.
Моя ошибка заключалась в том, что я также ссылался на другой файл в моем проекте, который также содержал значение атрибута AssemblyVersion. Я удалил этот атрибут из одного файла, и теперь он работает правильно.
Главное - убедиться, что это значение не объявляется более одного раза в любом файле вашего проекта.
Я столкнулся с этим недавно без каких-либо изменений в источнике, но после экспериментов с некоторыми новыми ссылками на проекты. Я попал в состояние, когда эта ошибка появлялась даже после отмены всех изменений в ветке.
Очистка ветки решила это для меня:
Если у вас возникла эта проблема в конвейере сборки в Azure DevOps, попробуйте указать действие сборки как «Содержимое» и «Копировать в выходной каталог», равное «Копировать, если новее» в свойствах файла AssembyInfo.cs.
У меня была эта проблема, когда мой основной проект находился в той же папке, что и решение, тогда у меня был отдельный проект в том же решении, расположенный во вложенной папке, и этот отдельный проект использовал основной проект в качестве ссылки. Это привело к тому, что основной проект обнаружил подпапки bin и obj, которые создавали повторяющиеся ссылки.
Я нашел этот ответ на msdn, в котором объясняется, как пометить файл как Content, а затем Copy to Output = If Newer. См. Статью ниже:
Еще одно решение при обновлении ядра до VS2017 - удалить их в файле properties \ assemblyinfo.cs.
Поскольку они сейчас хранятся в проекте.
Моя ошибка произошла из-за того, что каким-то образом внутри моей папки контроллеров была создана папка obj. Просто поищите в своем приложении строку внутри Assemblyinfo.cs. Где-то может быть дубликат.
Для меня это было то, что AssembyInfo.cs и SolutionInfo.cs имели разные значения. Так что проверьте и эти файлы. Я только что удалил версию с одного из них.
my.csproj содержит все, что связано с другими атрибутами сборки:
Хотя атрибуты исключают некоторые подробные коды, необходимые для записи COM-объектов, для их лучшего использования требуется фон в основах COM .
Если вы ищете стандартные атрибуты C++, см. раздел "Атрибуты".
Назначение атрибутов
В настоящее время атрибуты расширяют C++ в направлениях, не нарушая классическую структуру языка. Атрибуты позволяют поставщикам (отдельным библиотекам DLL) динамически расширять возможности языка. Основной целью атрибутов является упрощение разработки com-компонентов, а также повышение производительности разработчика компонентов. Атрибуты могут применяться практически к любой конструкции C++, например к классам, членам данных или функциям-членам. Ниже приведены основные преимущества, предоставляемые этой новой технологией:
Предоставляет знакомое и простое соглашение о вызовах.
Использует вставленный код, который, в отличие от макросов, распознается отладчиком.
Позволяет легко наследование от базовых классов без обременительных сведений о реализации.
Заменяет большой объем кода IDL, необходимый компоненту COM, несколькими краткими атрибутами.
Например, чтобы реализовать простой приемник событий для универсального класса ATL, можно применить атрибут event_receiver к определенному классу, например CMyReceiver . Затем event_receiver атрибут компилируется компилятором Microsoft C++, который вставляет правильный код в файл объекта.
Затем можно настроить CMyReceiver методы handler1 и handler2 обрабатывать события (с помощью встроенной функции __hook) из источника событий, который можно создать с помощью event_source.
Основные принципы работы атрибутов
Существует три способа вставки атрибутов в проект. Во-первых, их можно вставить вручную в исходный код. Во-вторых, их можно вставить с помощью сетки свойств объекта в проекте. Наконец, их можно вставить с помощью различных мастеров. Дополнительные сведения об использовании окна "Свойства" и различных мастерах см. в разделе Visual Studio Projects - C++.
Как и ранее, при сборке проекта компилятор анализирует каждый исходный файл C++, создав объектный файл. Однако при обнаружении атрибута компилятор анализируется и синтаксически проверяется. Затем компилятор динамически вызывает поставщик атрибутов для вставки кода или внесения других изменений во время компиляции. Реализация поставщика зависит от типа атрибута. Например, атрибуты, связанные с ATL, реализуются Atlprov.dll.
На следующем рисунке показана связь между компилятором и поставщиком атрибутов.
Использование атрибутов не изменяет содержимое исходного файла. Единственный раз, когда созданный код атрибута отображается во время сеансов отладки. Кроме того, для каждого исходного файла в проекте можно создать текстовый файл, отображающий результаты подстановки атрибутов. Дополнительные сведения об этой процедуре см. в разделе /Fx (слияние внедренного кода) и отладке внедренного кода.
Как и большинство конструкций C++, атрибуты имеют набор характеристик, определяющих их правильное использование. Это называется контекстом атрибута и рассматривается в таблице контекста атрибута для каждого раздела ссылки на атрибут. Например, атрибут coclass можно применить только к существующему классу или структуре, а не к атрибуту cpp_quote , который можно вставить в любое место в исходном файле C++.
Сборка атрибутированной программы
После добавления атрибутов Visual C++ в исходный код может потребоваться, чтобы компилятор Microsoft C++ мог создавать библиотеку типов и IDL-файл. Следующие параметры компоновщика помогают создавать TLB-файлы и IDL-файлы:
Некоторые проекты содержат несколько независимых IDL-файлов. Они используются для создания двух или более TLB-файлов и при необходимости привязывают их к блоку ресурсов. В настоящее время этот сценарий не поддерживается в Visual C++.
Кроме того, компоновщик Visual C++ выводит все сведения об атрибутах, связанных с IDL, в один MIDL-файл. Создать две библиотеки типов из одного проекта невозможно.
Контексты атрибутов
Атрибуты C++ можно описать с помощью четырех основных полей: целевой объект, к которым они могут применяться (применяется), если они являются повторяемыми или нет (повторяемыми), необходимым присутствием других атрибутов (обязательные атрибуты) и несовместимыми с другими атрибутами (недопустимые атрибуты). Эти поля перечислены в связанной таблице в справочном разделе каждого атрибута. Каждое из этих полей описано ниже.
Применяется к
В этом поле описываются различные элементы языка C++, которые являются юридическими целями для указанного атрибута. Например, если атрибут указывает "класс" в поле "Применимо к ", это означает, что атрибут может применяться только к юридическому классу C++. Если атрибут применяется к функции-члену класса, результатом будет синтаксическая ошибка.
Дополнительные сведения см. в разделе "Атрибуты по использованию".
Повторяемый
Это поле указывает, можно ли многократно применять атрибут к одному и тому же целевому объекту. Большинство атрибутов не повторяются.
Обязательные атрибуты
В этом поле перечислены другие атрибуты, которые должны присутствовать (то есть применены к одному и тому же целевому объекту) для правильной работы указанного атрибута. Для атрибута часто используются все записи для этого поля.
Недопустимые атрибуты
В этом поле перечислены другие атрибуты, несовместимые с указанным атрибутом. Для атрибута часто используются все записи для этого поля.
У меня есть проект, который генерирует следующую ошибку при компиляции:
ошибка CS0579: повторяющийся атрибут AssemblyVersion
Я проверил файл AssemblyInfo.cs и похоже, что там нет дубликатов.
Я нашел эту статью в MSDN, в которой рассматривается аналогичная проблема, и следование предложению в этой статье также устраняет проблему.
Кто-нибудь может сказать мне, что здесь происходит? Это происходит только в случае наличия двух и более проектов с похожими именами классов? Или что-то еще?
просто предположение, но вы пытались закрыть и снова открыли решение? возможно, это могло бы решить эту проблему?
Я использую Visual Studio 2017 Community Edition на Mac. У меня было консольное приложение, а затем я добавил ссылку на новый проект библиотеки классов. Эти ошибки начали появляться, когда я делал сборку. Все, что я сделал, это удалил ссылку на проект библиотеки классов, а затем добавил ее обратно, и ошибки исчезли.
Я также сталкивался с этой проблемой в прошлом, поэтому предполагаю, что ваш процесс сборки предоставляет информацию о сборке отдельно от обеспечения управления версиями. И это вызывает дублирование, поскольку в вашем проекте также есть эта информация в AssemblyInfo.cs файле. Так что удалите файл, и я думаю, он должен работать.
Итак, не следует ли в процессе сборки перезаписывать существующую AssemblyVersion вместо создания новой записи? Я знаю, что наш процесс сборки делает это, но мне любопытно, почему он не перезаписывает существующий. Это плохо реализовано или это ограничение?
Начиная с Visual Studio 2017, еще одним решением для продолжения использования AssemblyInfo.cs файла является отключение автоматического создания информации о сборке следующим образом:
К сожалению, каждый раз , когда я изменить .csproj файл с помощью его свойств страниц (приложений, строительство, Строительные События, и т.д.), PropertyGroup с GenerateAssemblyInfo исчезает :-(
У меня была такая же ошибка, и в ней подчеркивались версия сборки и версия файла сборки, поэтому, прочитав ответ Luqi, я просто добавил их в качестве комментариев, и ошибка была решена
- удалите конфликтующие элементы из файла AssemblyInfo.cs,
- полностью удалить файл или
- отключить GenerateAssemblyInfo (как предлагается в другом ответе Сергея Семенова )
Я считаю более интуитивно понятным и более "Visual Studio" указывать эти атрибуты в проекте ( .csproj ), потому что они являются метаданными, а не кодом, описывающим реальную логику. Надеюсь, в будущем в проекте можно будет все уточнить! (В настоящее время я не могу указать видимость COM, поэтому оставляю это AssemblyInfo.cs .)
В моем случае в проект случайно были добавлены временные файлы * .cs, созданные во время компиляции.
Файлы были из obj\Debug каталога, поэтому их определенно не следовало добавлять в решение. *.cs Подстановочные пошел немного сумасшедший и добавил их неправильно.
Удаление этих файлов устранило проблему.
В моем случае это вложенная папка в проекте, которая сама была папкой проекта:
- c: \ проекты \ webapi \ wepapi.csproj
- c: \ проекты \ webapi \ tests \ wepapitests.csproj
Затем мне пришлось удалить подпапку «тесты» из проекта «webapi».
Для меня это было то, что AssembyInfo.cs и SolutionInfo.cs имели разные значения. Так что проверьте и эти файлы. Я только что удалил версию с одного из них.
Моя ошибка возникла из-за того, что каким-то образом внутри моей папки контроллеров была создана папка obj. Просто поищите в своем приложении строку внутри Assemblyinfo.cs. Возможно где-то есть дубликат.
Еще одно решение при обновлении ядра до VS2017 - удалить их в файле properties \ assemblyinfo.cs.
Поскольку они сейчас хранятся в проекте.
AssemblyInfo.cs
my.csproj содержит все, что связано с другими атрибутами сборки:
Здесь в проекте уже должен быть файл AssemblyInfo.cs:
Чтобы решить: - Удалите любой AssemblyInfo.cs
Я нашел этот ответ на msdn, в котором объясняется, как пометить файл как Content, а затем Copy to Output = If Newer. См. Статью ниже:
У меня была эта проблема, когда мой основной проект находился в той же папке, что и решение, тогда у меня был отдельный проект в том же решении, расположенный во вложенной папке, и этот отдельный проект использовал основной проект в качестве ссылки. Это привело к тому, что основной проект обнаружил подпапки bin и obj, которые создавали повторяющиеся ссылки.
Это мне очень помогло! Один проект ссылался на другой как на зависимость времени сборки, но ошибка в csproj привела к тому, что папки obj изменились, что привело к возникновению этой ошибки.
Если у вас возникла эта проблема в конвейере сборки в Azure DevOps, попробуйте указать действие сборки как «Содержимое» и «Копировать в выходной каталог», равное «Копировать, если новее» в свойствах файла AssembyInfo.cs.
I have a project that generates following error on compilation:
error CS0579: Duplicate 'AssemblyVersion' attribute
I have checked the file AssemblyInfo.cs and it looks like there is no duplication there.
I found this article on MSDN which addresses a similar problem and following the suggestion in this article fixes the problem as well.
Can anyone tell me what's going on here? Does it happen only in case of having two or more projects with classes having similar names? Or is it something else?
just a guess but, did you try close and that opening the solution again? perhaps that might solve it?
I am using Visual Studio 2017 Community edition on the Mac. I had a console app and then I added a reference to a new class library project. These errors started showing up when I did a build. All I did was remove the reference to the class library project and then add it back and the errors went away.
30 Answers 30
Starting from Visual Studio 2017 another solution to keep using the AssemblyInfo.cs file is to turn off automatic assembly info generation like this:
Unfortunately, every time I change the .csproj file using its property pages (Application, Build, Build Events, etc.), the PropertyGroup with the GenerateAssemblyInfo disappears :-(
I have also run into this issue in the past, so I am going to assume that your build process provides assembly information separately to providing versioning. And that causes a duplication as your project also has that info in the AssemblyInfo.cs file. So remove the file and I think it should work.
So, Shouldn't build process overwrite the existing AssemblyVersion instead of creating a new entry? I know that our build process does that but I am curious that why it doesn't overwrite the existing one. Is it badly implemented or is it a limitation?
- remove the conflicting items from the AssemblyInfo.cs file,
- completely delete the file or
- disable GenerateAssemblyInfo (as suggested in another answer by Serge Semenov)
I find it more intuitive and more "Visual Studio" to specify these attributes in the project ( .csproj ), because they are metadata instead of code that describe actual logic. I hope in future everything can be specified in the project! (Currently I cannot specify COM visibility, so I leave it in AssemblyInfo.cs .)
In my case, there where a subfolder in a project that was a project folder it self:
- c:\projects\webapi\wepapi.csproj
- c:\projects\webapi\tests\wepapitests.csproj
- webapi (folder and project)
- tests (folder)
Then i had to remove the subfolder "tests" from the "webapi" project.
I had removed the subproject from the solution, but the subdirectory and files were still sitting there. Removing them finally fixed the problem.
I had the same error and it was underlining the Assembly Vesrion and Assembly File Version so reading Luqi answer I just added them as comments and the error was solved
To solve: - Delete any one AssemblyInfo.cs
In my case, some temporary *.cs files generated during compilation got accidentally added to the project.
The files were from the obj\Debug directory, so they definitely shouldn't have been added to the solution. A *.cs wildcard went a little crazy and added them incorrectly.
Deleting these files fixed the problem.
AssemblyInfo.cs
my.csproj contains all related to other assembly attributes:
For me it was that AssembyInfo.cs and SolutionInfo.cs had different values. So check these files as well. I just removed the version from one of them.
My error occurred because, somehow, there was an obj folder created inside my controllers folder. Just do a search in your application for a line inside your Assemblyinfo.cs. There may be a duplicate somewhere.
You can remove bin and obj file and clear the cache of the project. My issue was fixed from that.
Yet another solution when upgrading core to VS2017 is to remove them in the properties\assemblyinfo.cs file.
Since they now are stored in the project.
This usually happens for me if I compiled the project in Visual Studio 2017 & then I try to rebuild & run it with .NET Core with the command line command "dotnet run".
Simply deleting all the "bin" & "obj" folders - both inside "ClientApp" & directly in the project folder - allowed the .NET Core command "dotnet run" to rebuild & run successfully.
I ran into this recently with no changes to source, but after experimenting with some new project references. I got into a state where this error was appearing even after reverting all changes in the branch.
Cleaning the branch resolved it for me:
I found this answer on msdn, that explains marking the file as Content and then Copy to Output = If Newer. See article below:
I got this error when I did put 2 projects in the same directory. If I have a directory with an solution and I put a separate Web and Data directory in it compiles right.
I had this issue when my main project was in the same folder as the solution, then I had a separate project in the same solution located in a sub folder, and that separate project used the main project as a reference. This caused the main project to detect the sub folder bin & obj folders which created duplicate references.
This helped me out a lot! One project referenced another as a build-time dependency, but a bug in the csproj caused the obj folders to be different, generating this error.
If you're having this problem in a Build Pipeline on Azure DevOps, try putting the Build Action as "Content" and Copy to Output Directory equal to "Copy if newer" in the AssembyInfo.cs file properties.
When you create a project, Visual Studio sets it up to compile & generate a corresponding assembly. Each project generates 1 assembly, and so each has a corresponding assembly configuration to generate its assembly from.
The problem is when you create more than one project that each can generate their own assembly, and then include one of these projects in the other.
In this scenario, Visual Studio gets confused and doesn't know which config file to go off of to generate the single assembly for the project -- it finds the second assembly configuration in the included project and says "HEY, DUPLICATE! You've given me two sets of instructions for generating my assembly!"
But sometimes you still want the included project to be able to generate an assembly on it's own, but not when it is being included in another project.
To obtain this, one solution is to add conditional defines to the including project (found in project Properties). Then change the assembly config in the included project to look for this conditional define. If it is defined (by the including project), then the config can skip over it's content -- this will result in only 1 config found by VS -- the one from the including project -- problem solved!
В данном примере прошу обратить внимание, на два момента:
1. При использовании атрибутов «суффикс»: Attribute, можно не писать.
2. Фамилия и имя помечены атрибутом RequiredAttribute, а отчество нет.
Если мы с вами попробуем создать объект класса Person, то, как бы это обидно не звучало, мы его сможем создать с пустыми полями LastName и FirstName, т.к. этот атрибут ну совсем никак не влияет на поведение класса. Зачем тогда он? А мы им воспользуемся в форме добавления/редактирования человека, чтобы пользователь не мог закончить редактирование, пока эти поля не заполнены.
Общий вид приложения будет вот такой:
Для редактирования свойств человека воспользуемся UserControl (почему не формой чуть ниже):В cs файл этого UserControl-а даже не лезем. Обратили внимание, на то, что Binding к источнику применяется по внешнему событию? [5]
На текущий момент, у нас уже есть класс описывающий бизнес-объект и компонент, для редактирования свойств этого объекта. Осталось сделать универсальное окно, которое сможет показывать компоненты для редактирования бизнес-объектов и будет проверять заполненность обязательных полей, а также, если все заполнено правильно, будет применять Binding визуальных компонентов к полям бизнес-объектов.
Создаем форму:
Добавляем обработчик на кнопку отмена:
И самый интересный в данном примере обработчик кнопки принять:Вроде в комментариях все подробно описал, единственно метод: GetChildTextBoxes, приводить не буду, он пробегает по визуальному дереву и выбирает все TextBox-ы. Кому интересно, может его посмотреть, скачав исходники.
Все. Прикручиваем на главной форме обработчики к кнопкам добавить и редактировать:Ну и вот так это выглядит:
Исходники, если кто не увидел ссылки в тексте, можно скачать тут (Проект в VS 11, если что).
P.s. Любопытный читатель, может поинтересоваться: «А причем тут картинка в шапке?». Ну, я хотел бы думать, что это намек, на то, что атрибуты, как и этот знак, вроде бы есть, но вроде бы и нет.
Читайте также: