Почему выводится это, понять можно: дизассемблировав сборку, видно, что повторяющийся атрибут туда просто не попал. (я имею в виду атрибут сборки, на атрибуты класса можно вообще забить).
Также можно упростить код атрибута до
public MyAttribute(string origin)
{
// пусто
}
То есть, мы можем сказать, что метод GetCustomAttributes тут ни при чём, просто компилятор не поместил повторяющийся атрибут в сборку, причём "одинаковость" он определяет только по параметрам конструктора, остальное (свойства) в счёт не идет.
Кстати, можно дизассемблировать сборку, прописать туда "пропавший" атрибут по аналогии и ассемблировать снова. Тогда получим ожидаемый результат.
Так что вопрос сводится к "зачем они так сделали?". Тут могут быть варианты:
Ненамеренно. Баг — самое простое предположение. Но с пятой версии должны были исправить, наверно.
Намеренно. Решили изменить поведение (а как же возможность прописывать несколько значений?). Для чего — не знаю.
Здравствуйте, dmitry_npi, Вы писали:
_>То есть, мы можем сказать, что метод GetCustomAttributes тут ни при чём, просто компилятор не поместил повторяющийся атрибут в сборку, причём "одинаковость" он определяет только по параметрам конструктора, остальное (свойства) в счёт не идет.
Таки да, тема раскрыта полностью
_>Так что вопрос сводится к "зачем они так сделали?". Тут могут быть варианты:
Ну, поведение тянется ещё с c# 3 (древнее лень проверять) + в первом рослине огромное количество времени уделяли полному совпадению il-выхлопа для существующего кода на c#, вплоть до тестов с компиляцией всего опенсорс-кода на шарпе на codeproject / codeplex (по памяти, поэтому без пруфов). Т.е. почему не поменялось сразу — понятно.
Позднее, разумеется, пошли ломающие изменения, так что в принципе, может быть поправлено. В c# spec это нигде не оговорено (или я пропустил), в mono (онлайн-сервис для проверки) поведение логичное —
Здравствуйте, Sinix, Вы писали:
_>>Так что вопрос сводится к "зачем они так сделали?". Тут могут быть варианты: S>Ну, поведение тянется ещё с c# 3 (древнее лень проверять) + в первом рослине огромное количество времени уделяли полному совпадению il-выхлопа для существующего кода на c#, вплоть до тестов с компиляцией всего опенсорс-кода на шарпе на codeproject / codeplex (по памяти, поэтому без пруфов). Т.е. почему не поменялось сразу — понятно.
Поведение на всех версиях языка для vs2013 одинаковое.
S>Позднее, разумеется, пошли ломающие изменения, так что в принципе, может быть поправлено. В c# spec это нигде не оговорено (или я пропустил), в mono (онлайн-сервис для проверки) поведение логичное — S>
Здравствуйте, Sharov, Вы писали:
S>Мне кажется что 2-2 будет логичнее чем 3-3. Какой смысл навешивать дважды один и тот же атрибут?
AOP-декораторы, к примеру. Комбо из [LogStartEndTime][TakeLock][LogStartEndTime] — вполне себе реальное (хотя работает чисто по везению, т.к. строго говоря компилятор не обязан сохранять порядок следования атрибутов).
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Мне кажется что 2-2 будет логичнее чем 3-3. Какой смысл навешивать дважды один и тот же атрибут? S>AOP-декораторы, к примеру. Комбо из [LogStartEndTime][TakeLock][LogStartEndTime] — вполне себе реальное (хотя работает чисто по везению, т.к. строго говоря компилятор не обязан сохранять порядок следования атрибутов).
Про AOP не думал, возможно и так. Но вообще суть метаданных в их уникальности или однозначности.