Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>В качестве теста можно сделать затычку с определенными в ней атрибутом и методами-расширениями...
ИД>Вроде как ничего страшного не делается, т.к. тест с настоящей System.Core.dll не пересекается.

Ага. Но надо иметь и тест с System.Core.dll.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>...На самом деле, так надо было с самого начала делать, но тогда не сумел.

+1 Я тебе об этом и говорил, но ты тогда меня не понял видимо.

СТ>Добавил также тест. Только тут опять не всё гладко. Не получилось заставить tests.exe заставить компилятор зареференсить System.Core, которая лежит в GAC. Поэтому, в качестве временного решения, пришлось её подложить туда, в папочку. Если кто знает, как это сделать, буду очень признателен.

Сослаться на сборку из гака очень легко если используется студийный проект. В нам достаточно указать имя сборки без расширения.

Но для твоего случая как раз это делать не надо! Дело в том, что тест должен работать и на втором фрэймворке (где нет этой длл). Так что просто закомить ее как часть теста. Можно положить ее в подкаталог и сослаться с помощью относительного пути.

Здравствуйте, VladD2, Вы писали:


VD>Сослаться на сборку из гака очень легко если используется студийный проект. В нам достаточно указать имя сборки без расширения.

Так в том-то и дело, что используется не студийный проект. Я вчера целый час потратил на то, чтобы разобраться, как к тестам подключать сборки.

VD>Но для твоего случая как раз это делать не надо! Дело в том, что тест должен работать и на втором фрэймворке (где нет этой длл). Так что просто закомить ее как часть теста. Можно положить ее в подкаталог и сослаться с помощью относительного пути.
Ну так я так и сделал. Ты это можешь увидеть, посмотрев логи.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Здравствуйте, VladD2, Вы писали:

VD>>Но для твоего случая как раз это делать не надо! Дело в том, что тест должен работать и на втором фрэймворке (где нет этой длл). Так что просто закомить ее как часть теста. Можно положить ее в подкаталог и сослаться с помощью относительного пути.
СТ>Ну так я так и сделал. Ты это можешь увидеть, посмотрев логи.

Ага, а я потом снесу , как только одно из двух:
— станет ясно как врубить ссылку на Gac или еще через какое-нибудь место притянуть System.Core.dll
— сделаю тест по-другому, например заставив компилятор ругаться на множественное наличие этого атрибута (уже почти, осталось подводные камни потестить).

Хранить чужой бинарник ради одного теста конечно же не дело (да и непонятно как это с правовой точки зрения выглядит).

Здравствуйте, Иванков Дмитрий, Вы писали:


ИД>Ага, а я потом снесу , как только одно из двух:
ИД>- станет ясно как врубить ссылку на Gac или еще через какое-нибудь место притянуть System.Core.dll
ИД>- сделаю тест по-другому, например заставив компилятор ругаться на множественное наличие этого атрибута (уже почти, осталось подводные камни потестить).

Так там же не надо ничего делать специально. Оно само ругается. Это тот ворнинг, про который Влад говорил.

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Так там же не надо ничего делать специально. Оно само ругается. Это тот ворнинг, про который Влад говорил.

При компиляции из консоли вроде ж не ругалось, иначе было бы не "Error 1 there is no member named `Where' in list.Cons[int-] with type ?", а "warning: он самый + error", еще посмотрю.
Может это студия ругалась, т.к. я этот warning так и не видел, хотя я мог просто упустить его из вида

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Здравствуйте, Сергей Туленцев, Вы писали:

СТ>>Так там же не надо ничего делать специально. Оно само ругается. Это тот ворнинг, про который Влад говорил.

ИД>При компиляции из консоли вроде ж не ругалось, иначе было бы не "Error 1 there is no member named `Where' in list.Cons[int-] with type ?", а "warning: он самый + error", еще посмотрю.
ИД>Может это студия ругалась, т.к. я этот warning так и не видел, хотя я мог просто упустить его из вида

Он был в старой версии, при компиляции проекта интеграции.

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Ага, а я потом снесу , как только одно из двух:
ИД>- станет ясно как врубить ссылку на Gac или еще через какое-нибудь место притянуть System.Core.dll

Не надо сносить! Еще раз повторяю: Компилятор обязан компилироваться со вторым фрэймворком, где этой ДЛЛ нет. По сему ее надо просто хранить в проекте. За одно она будет полезна при тестировании других фич линка которые еще только предстоит реализовать.

ИД>- сделаю тест по-другому, например заставив компилятор ругаться на множественное наличие этого атрибута (уже почти, осталось подводные камни потестить).

Компилятор и так ругается. Но какое это имеет отношение, например, к данному прецеденту деградации функциональности?

ИД>Хранить чужой бинарник ради одного теста конечно же не дело (да и непонятно как это с правовой точки зрения выглядит).

Надо. Ничего страшного в нем нет. Собственно, по большому счету этот бинарник и отличает 2-ой фрэймворк от 3.5-го.

В общем, не трогай его.

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>При компиляции из консоли вроде ж не ругалось,...

Естественно, так как теперь атрибут присутствует в одном экземпляре. Раньше же он был как в Nemerle.dll сборке, так и в System.Core.dll, что приводило к выдаче ворнига при попытке скомпилироваться с этой сборкой.

Здравствуйте, VladD2, Вы писали:

VD>Не надо сносить! Еще раз повторяю: Компилятор обязан компилироваться со вторым фрэймворком, где этой ДЛЛ нет.
Да, в частности под mono тоже
VD>По сему ее надо просто хранить в проекте. За одно она будет полезна при тестировании других фич линка которые еще только предстоит реализовать.
К общим юниттестам компилятора это отношения не имеет:
1) почти всегда можно нарисовать короткий тест без нее
2) никакого желания при каждом обломе теста лезть в дебри этой либы и в ее спецификации нет.

VD>Компилятор и так ругается. Но какое это имеет отношение, например, к данному прецеденту деградации функциональности?
Теперь ругается. А раньше — не всегда, на тесте: fw2+system.core+another_attr(в себе) молчал про проигнорированный атрибут.
И теперь при левом атрибуте в самом компиляторе/в зависимостях отвалится нужный тест/будет соответствующее сообщение.

VD>Надо. Ничего страшного в нем нет. Собственно, по большому счету этот бинарник и отличает 2-ой фрэймворк от 3.5-го.
И зачем нам это отличие у себя хранить?
Опять же в правовую сторону: на каких основаниях, под какой лицензией?

VD>В общем, не трогай его.
Уже снес и написал эквивалентный тест, и пока не вижу смысла возвращать.
Если край надо уметь писать набор тестов с зависимостью от него, то надо делать именно это: сделать отдельную пачку тестов и научиться ставить зависимость от System.Core.dll из системы (хоть костылем вроде "%ProgramFiles%\Reference Assemblies\Microsoft\..." если уж совсем никак не получится). Отдельной она может даже не быть, т.к. при неподгружаемой библиотеке тест пропускается.

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>...и научиться ставить зависимость от System.Core.dll из системы...

А тут все просто, надо указывать не "System.Core", а ее полное имя, что в общем-то логично.
Примерно такое "System.Core, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".

P.S. это я же

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Может это студия ругалась, т.к. я этот warning так и не видел, хотя я мог просто упустить его из вида

Студия использует компилятор. Сама она ругаться не обучена.

Здравствуйте, Иванков Дмитрий, Вы писали:

VD>>Не надо сносить! Еще раз повторяю: Компилятор обязан компилироваться со вторым фрэймворком, где этой ДЛЛ нет.
ИД>Да, в частности под mono тоже

Это обычная ДЛЛ, так что и с Моно она обязана работать.

VD>>По сему ее надо просто хранить в проекте. За одно она будет полезна при тестировании других фич линка которые еще только предстоит реализовать.
ИД>К общим юниттестам компилятора это отношения не имеет:
ИД>1) почти всегда можно нарисовать короткий тест без нее
ИД>2) никакого желания при каждом обломе теста лезть в дебри этой либы и в ее спецификации нет.

Туда лезть и не надо. Ошибки ведь у нас. И вообще, это какие-то отмазки. Тебе никто не запрещает кроме тестов с этой ДЛЛ сделать и более поверхностные тесты.

В общем, верни тест с этой ДЛЛ обратно, плиз.

VD>>Компилятор и так ругается. Но какое это имеет отношение, например, к данному прецеденту деградации функциональности?
ИД>Теперь ругается. А раньше — не всегда, на тесте: fw2+system.core+another_attr(в себе) молчал про проигнорированный атрибут.

Он ругался когда атрибуты были в разных сборках. Боюсь что теперь в таких условиях ругань будет удваиваться.

ИД>И теперь при левом атрибуте в самом компиляторе/в зависимостях отвалится нужный тест/будет соответствующее сообщение.

И где гарантиях, что при наличии атрибутов в двух сборках не будет двойного сообщения?

VD>>Надо. Ничего страшного в нем нет. Собственно, по большому счету этот бинарник и отличает 2-ой фрэймворк от 3.5-го.
ИД>И зачем нам это отличие у себя хранить?

Чтобы тем кто тесты ганяет на втором фрэймворе или Моно не вываливались сообщения об ошибках на ровном месте. И, если снова кто-то что-то поломает, чтобы мы об этом узнали сразу.

ИД>Опять же в правовую сторону: на каких основаниях, под какой лицензией?

На основании того, что приложение (тест) использует эту сборку. И вообще, это уже балшит. Вот когда МС через суд докажет, что так делать нельзя, то поговорим.

VD>>В общем, не трогай его.
ИД>Уже снес и написал эквивалентный тест, и пока не вижу смысла возвращать.

Вижу и мне это очень не нравится. Ни фига он не эквивалентный! Он синтетический, а значит не дающий гарантии.

ИД>Если край надо уметь писать набор тестов с зависимостью от него, то надо делать именно это: сделать отдельную пачку тестов и научиться ставить зависимость от System.Core.dll из системы (хоть костылем вроде "%ProgramFiles%\Reference Assemblies\Microsoft\..." если уж совсем никак не получится). Отдельной она может даже не быть, т.к. при неподгружаемой библиотеке тест пропускается.

Не над из системы. Все должно быть автономно! И тесты отдельные на фиг не уперлись. Там каждый отдельный файл это отдельный тест. В общем, верни назад длл-ку.

Кстати, ты почту читаешь... ту что указана в профайле? Если нет, то напиши мне на мыло, чтобы у меня был твое работающее мыло.

Здравствуйте, VladD2, Вы писали:

VD>Он ругался когда атрибуты были в разных сборках.
Нет, не всегда, легко проверить: тест negative/external-extensions.n компилятор ревизии 7891 не проходит.
Однако наконец-то нашел это предупреждение, когда именно возникает и почему не возникло строчкой выше — todo.

VD>И где гарантиях, что при наличии атрибутов в двух сборках не будет двойного сообщения?
Будет, "warn: attr from 1 ignored", "hint: attr first defined in 0", "warn: attr from 2 ignored", "warn: attr from 3 ignored".
Т.е. полная и не избыточная информация, little todo — выше.

VD>Чтобы тем кто тесты ганяет на втором фрэймворе или Моно не вываливались сообщения об ошибках на ровном месте.
Они не будут вываливаться, как не вываливается positive/gtk.n.

VD>И, если снова кто-то что-то поломает, чтобы мы об этом узнали сразу.
Сразу не выйдет, т.к. весь интероп nemerle и system.core не покрыт тестами
А как узнаем — все равно надо локализовать проблему, найти причину и сделать микротест, явно демонстрирующий и проверяющий проблему, и, возможно, посмотреть давно ли эта проблема существует.

VD>Вижу и мне это очень не нравится. Ни фига он не эквивалентный! Он синтетический, а значит не дающий гарантии.
Более того, нет тестов с гарантиями.
Однако ж гораздо правильнее проверять не "ncc дружит с данной конкретной либой", а "ncc поддерживает такие-то общие фишки, благодаря которым можно дружить с этой либой". System.Core в репозитории — костыль, не более того.

VD>Не над из системы.
FullName на то и FullName чтобы однозначно идентифицировать эту загогулину, если хочется ее тестить, то и ссылаться на нее стоит именно так. (да, в сообщении выше я на system.core из беты судя по всему ссылку дал, а правильное имя легко подсмотреть в гаке)

VD>... В общем, верни назад длл-ку.
В общем, я против наличия этой (и любой другой) dll в репозитории и это мое, так сказать, заднее слово.

Тесты с ссылкой по FullName — пожалуйста, обнаруженные глюки в трекер — сколько угодно, можно даже сразу на меня вешать

Здравствуйте, VladD2, Вы писали:

VD>Кстати, ты почту читаешь... ту что указана в профайле? Если нет, то напиши мне на мыло, чтобы у меня был твое работающее мыло.
Очевидно, что да, я ж с нее пишу в рассылку
Другое дело что только по мере возможности, но тут ничего не поделать.

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Здравствуйте, VladD2, Вы писали:

VD>>Кстати, ты почту читаешь... ту что указана в профайле? Если нет, то напиши мне на мыло, чтобы у меня был твое работающее мыло.
ИД>Очевидно, что да, я ж с нее пишу в рассылку

О, не так очевидно, там один редирект происходит, сорри.., в общем всю почту читаю

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Здравствуйте, VladD2, Вы писали:

VD>>Не над из системы.
ИД>FullName на то и FullName чтобы однозначно идентифицировать эту загогулину, если хочется ее тестить, то и ссылаться на нее стоит именно так. (да, в сообщении выше я на system.core из беты судя по всему ссылку дал, а правильное имя легко подсмотреть в гаке)
см. positive/linq.n
Если кто-то без System.Core.dll у себя поломает коммитом подобный тест, не поломав остальных — вызывайте