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

VD>Ситуация была такая.

VD>Есть проект в котором делается реализация интерфейса. Сам интерфейс описан в другом проекте (но это видимо не важно).

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

Воспроизвел. Компилятор немерле инициализирует список методов класса неленивым образом. Когда ты создаешь объект, то компилятор ищет конструктор типа, для чего поднимает все методы класса, сохраняя в своих внутренних структурах типы входных и выходных параметров. Поэтому даже если в коде и нет прямого обращения к проблемному методу, компилятор все таки до него добирается. И тут не поможет даже ленивая загрузка методов, потому что полный список методов может потребоваться для интеллисенса.

В аналогичной ситуации компилятор шарпа позволяет компилировать проект, если он не содержит явных вызовов проблемных методов. Проблемный метод и его сигнатура также успешно отображаются в списке интелисенса.

Поэтому решение о запрете загрузки типов из неизвестных сборок было неправильным. Типы нужно загружать, только делать это корректнее, чем это делается сейчас. Над этим сейчас и работаю. Откатить изменения?

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

S>Попробую воспроизвести на обоих компиляторах. А вот с меседжбоксом странно — у меня он еще ни разу не выскочил.

Он появляется именно когда есть это сообщение и работаешь под IDE. Но это как раз ясно почему. Ты используешь FatalError, а это приводит к генерации исключения. На такой ранней стадии интеграция видимо не ожидает его и это приводит к появлению окна.

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

S>Воспроизвел. Компилятор немерле инициализирует список методов класса неленивым образом. Когда ты создаешь объект, то компилятор ищет конструктор типа, для чего поднимает все методы класса, сохраняя в своих внутренних структурах типы входных и выходных параметров. Поэтому даже если в коде и нет прямого обращения к проблемному методу, компилятор все таки до него добирается. И тут не поможет даже ленивая загрузка методов, потому что полный список методов может потребоваться для интеллисенса.

Да, похоже на то... К со жалению.

S>В аналогичной ситуации компилятор шарпа позволяет компилировать проект, если он не содержит явных вызовов проблемных методов. Проблемный метод и его сигнатура также успешно отображаются в списке интелисенса.

S>Поэтому решение о запрете загрузки типов из неизвестных сборок было неправильным. Типы нужно загружать, только делать это корректнее, чем это делается сейчас. Над этим сейчас и работаю. Откатить изменения?

Откатывать не надо. Жить можно. Просто, конечно, в таком виде нельзя делать инсталлятор (а надо бы). Так что если можно не затягивай с исправлением. В проекте Н2 я уже обошел проблему сделав все "проблемные" методы интерналом.

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

S>В аналогичной ситуации компилятор шарпа позволяет компилировать проект, если он не содержит явных вызовов проблемных методов. Проблемный метод и его сигнатура также успешно отображаются в списке интелисенса.

S>Поэтому решение о запрете загрузки типов из неизвестных сборок было неправильным. Типы нужно загружать, только делать это корректнее, чем это делается сейчас. Над этим сейчас и работаю. Откатить изменения?

А может в таких случаях создавать некие заглушки? Ну, чтобы загрузка не поперла рекурсивно. Если к этой заглушке будет реальное обращение, пусть генерирует ошибку.

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

VD>А может в таких случаях создавать некие заглушки? Ну, чтобы загрузка не поперла рекурсивно. Если к этой заглушке будет реальное обращение, пусть генерирует ошибку.

Я пока не понял, как внури этой заглушки понять с какой целью идет обращение к свойствам — компилируется ли реальное обращение или отображается список интелисенса.

Пофиксил баг исправив поиск типов и динамическую их погрузку из неподключенной сборки. Залил исправления в отдельный бранч — http://code.google.com/p/nemerle/source/detail?r=9533

Пока фиксил динамическую загрузку, нашел место, в котором можно безболезненно прогрузить всю неподключенную сборку. Поскольку для полностью загруженной сборки поиск типов работает в исходном виде, то изменения при таком способе исправления минимальны. Этот способ залил в другой бренч — http://code.google.com/p/nemerle/source/detail?r=9534

Первый вариант побыстрее, т.к. типы загружаются только по мере необходимости. Второй — безопаснее, т.к. требует минимальных изменений. Наверное на стадии релиз-кандидата стоит остановиться на втором варианте?

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

S>Пока фиксил динамическую загрузку, нашел место, в котором можно безболезненно прогрузить всю неподключенную сборку. Поскольку для полностью загруженной сборки поиск типов работает в исходном виде, то изменения при таком способе исправления минимальны. Этот способ залил в другой бренч — http://code.google.com/p/nemerle/source/detail?r=9534

S>Первый вариант побыстрее, т.к. типы загружаются только по мере необходимости. Второй — безопаснее, т.к. требует минимальных изменений. Наверное на стадии релиз-кандидата стоит остановиться на втором варианте?

Да. Чем проще изменения, тем больше надежды на стабильность работы. Правильно "фиксить" будем уже во второй версии. Главное поминить о проблеме.

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

S>Первый вариант побыстрее, т.к. типы загружаются только по мере необходимости. Второй — безопаснее, т.к. требует минимальных изменений. Наверное на стадии релиз-кандидата стоит остановиться на втором варианте?

По уму тут надо действовать хитрее. Грузить все на что есть ссылки (как во втором варианте). При этом нужно формировать отдельный список неявно загруженных сборок. Далее на этапах непосредственно предшествующих генерации кода нужно проверять не относится ли испоьзуемый тип к этому списку. И если относится, то ругаться.

Но это не так просто.