Обновить
Комментарии 15
Вопросики эти будут очень полезны тем, кто проводит собеседования. Если кандидат пришел «сильно умный» — ему можно задать пару таких вопросов :-)

>>Если вопросы вызовут интерес — правильные ответы опубликую после некоторого обсуждения
Вопросы таки вызвали интерес… ждёмс ответов и второй партии вопросов ;)
Помоему сами M$ говорили, что для того чтоб писать под нет, не обязательно досконально знать как работает CLR и как это выглядит в IL. Если появляются какие-то друдности, решаешь эту проблему, остольное не колышит.

Но нужно писать и знать некоторые соглашениея, поэтому вот это:

>>6) Если мы поставили клиенту код где в типе были определены поля, клиент написал на основе нашего кода свой код, затем мы поставили клиенту новую версию нашего кода где поля заменены на свойства, то что может сломаться в коде у клиента?

Вообще не должно было произойти. ИМХО.
А так да сходу на такое я лично не отвечу, честно.
Они хотели, чтоб это было не обязательно знать… Когда дело доходит до сложных систем неожиданно получается, что знать всё таки надо было…
Я считаю, что полностю как работает CLR не обязательно. Другое дело, что нужно знать самые основы к примеру что XAML компилируется в BAML, и что этоту самую разметку XAML можно написать как через код так и XML формате. Ещё его можно редоктировать на лету в ходе работы программы, но тогда производительность чуть хуже. И другие вещи.
А соглашения я имел ввиду, что к примеру все переменные должны быть private и инициализироватся должны через свойства или публичные методы. Если знать самые основы и придерживатся соглашений M$ да и вообще ООП. Проблем потом не будет.
А читать и зубрить книжку «Как работае CLR (.net2.0, 3.0, 3.5)» бред. Если появляются проблемы решаешь их и всё.

Ждём ответов, мне лично интересно.
может быть уже слишком поздно что-то делать, когда появились проблемы… Как работает CLR действительно зубрить не надо, а основы — это такое размытое понятие :)
Вот, например, может быть такое что код работает и вроде всё хорошо, но стоит немного переделать его и он начинает работать в 40 раз быстрее… Я говорю, например, о понимании различий в работе CLR со значимыми и не значимыми типами…
Ну это-то простой вопрос: могут быть ошибки компиляции на вызовах вида TryGetValue(«key», out obj.WasFieldNowProp);
Вот про static жёсткий вопрос. Имеется ввиду ведь то, что добавляется sealed?
1) Наверное, для элементарных типов вроде int не будет вызываться
2) Ну вроде это просто говорит компилятору, что класс не может содержать нестатические члены и не может наследоваться.
3) Точно знаю, что такой модификатор есть, но какой — не помню.
4) С помощью атрибутов (есть специальные атрибуты, какие — не знаю)
5) При создании структуры сразу выделяется память под все поля, по умолчанию она инициализирована нулями. А конструктор без параметров может их инициализировать иначе. Возникает неоднозначность, как же будет инициализирована структура (например, если создать её с помощью default) Поэтому, чтобы избежать ошибок конструкторы без парам. и убрали. Хотя вроде есть ещё причины.
6) Хз. Но ведь это получается, что поля заменили методами, так что по идее всё должно сломаться.
7) Нельзя объявить обработчик события, возвращающий не void, поэтому, думаю, следуют, хотя что такое FCL — понятия не имею.
1) вы же сами написали в пункте 5) что автоматически вызывается конструктор, который инициализирует все поля… Так что консруктор вызывается…
2) Это точно, но идея в том что static заменяется в IL коде явно на два других ключевых слова.
3) напишу в ответах
4) Точно, тоже напишу подробнее в ответах

6) Ну не всё, но многое… Выше часть написали
7) FCL == Framework Class Library — библиотека классов дот нет фреймворк
1) думаю элементарные типы неким образом оптимизируются. поэтому конструктор для них не вызывается
А как думаете, ответы на вопросы оформить отдельным постом, или отредактировать этот?
этот, а то что их потом искать
Хотелось бы сразу перейти к ответам :)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.