в VS Integration потребовалось захардкодить обновление дерева типов (т.е. перечитывание всег проекта) при изменении одного из .ResX-файлов.
Немного пояснений...
Макрос Resource генерирует класс-обртеку для ресурсного файла. Более деатальная информация о макросе достуна по ссылке.
Так вот, макрос Resource является мкро-атрибутом отрабатывает в момент формирования дерева типов.
Формировние дерева типов осуществляется только при изменении кода вне метода (т.е. описания типов и их членов). Таким образом, если макрос зависит, скажем от содержимого ресурсного файла (как в случае с Resource), то он не запускается при изменении файла от которого он зависит.
В случае с макросом Resource я сделал прямолинейного решение. Для всех .ResX-файлов добавленных в проект подключается объект наблюдатель (watcher) который при изменении файла выдает запрос на перестроение дерева типов.
Проблема в том, что это хардкодинг. Он не будет работать для других видов файлов.
Внимание, вопрос!
Как лучше поступить, чтобы обеспечить более универсальное решение.
Первое что приходит на ум — это подключать наблюдателей ко всем файлом не относящимся к коду (т.е. н .n-файлами). Но не уверен, что это разумное решение, так как оно может привести к нежелательному перестроениею дерева типов (а это в больших проектам может занимать несколько секунд).
Второе решение — разместить где-то список расширений файлов которые требуют обновления дерева типов при собственном изменении. Но, скажем, файлы с расширением XML могут содержать совршенно разные данные. Какие-то могут требовать изменения дерева типов, а какие-то нет.
Так же можно попробовать сделать некоторое свойство для файла (отображаемое в IDE) и предложить пользователю самостоятельно переключать его. Если такое свойство будет включено, то производить перестроение дерева при записи этого файла. Но насколько это будет удобно? Ведь следить за свойствами файлов вручную не самое приятное занятие. К тому же об этом можно просто не знать.
Кто что думает по этому поводу? Как лучше поступить? Может есть еще какие-то идеи?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Кто что думает по этому поводу? Как лучше поступить? Может есть еще какие-то идеи?
На мой взгляд очевидно лучшее выбирая из трёх идей — комбинация 2 и 3 — сделать некоторое свойство для файла и разместить где-то список расширений файлов которые идут с этим свойством по умолчанию.
Хотя перерисовка почему-то представляется мне в мрачных тонах
ResX файл — он же временно создаётся для конструктора и каждый раз при изменении дизайнера оно будет перерисовываться ?
الحقيقة:الشئ الوحيد الذي(لا)يصدقه الناس!ا الزواج : جمع.وطرح.ثم(ضرب)!ولكنه قبل ذلك(قسمة) المحامي:لسان.وحنجرة.وروب!يدافع عن مال موكله (أعزائي)!وهو لا يعرف أحد منّا!الطالب (الأول)على فصله!لولا وجود الأخرين
Здравствуйте, VladD2, Вы писали:
VD>Кто что думает по этому поводу? Как лучше поступить? Может есть еще какие-то идеи?
А если макрос генерит классы по содержимому БД, реестру, по описанию с удаленного веб сервиса? Имхо определять необходимость перестроения (или способ определения такой необходимости) должен сам макрос. Как — надо думать. Может декларативно, с помощью указания файлового расширения в атрибутах макроса, или с помощью функции, указанной в атрибутах же.
Здравствуйте, Schrodinger, Вы писали:
S>Хотя перерисовка почему-то представляется мне в мрачных тонах S>ResX файл — он же временно создаётся для конструктора и каждый раз при изменении дизайнера оно будет перерисовываться ?
ResX — это файл описывающий управляемые ресурсы.
Создается он один раз и дальше только изменяется.
Речь идет отом, что при их записи на диск нужно переситывать проект (чтобы отработал макрос генерурующий по этому фвйлу класс).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, seregaa, Вы писали:
S>А если макрос генерит классы по содержимому БД, реестру, по описанию с удаленного веб сервиса? Имхо определять необходимость перестроения (или способ определения такой необходимости) должен сам макрос.
Мысль здравая.
S>Как — надо думать.
Мне думмется что в общем случае решением может быть только ручной вызов запрова на опересоздание дерева типов.
А для файлов имеет смысл продумать специализированное решение.
Можно, конечно и сдесь сделать API с помощью которого сам макос подключтся на вобытие оповещающее об изменении файла.
S>Может декларативно, с помощью указания файлового расширения в атрибутах макроса, или с помощью функции, указанной в атрибутах же.
Мне кажется, что или нужно делать плную автоматику, перечитывая проект при любом изменении файла, или уже делать API позволяющий указывать конкретный файл при изменении которого нужно перечитывать проект. Декларативность тут прведет к сужению возможностей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Самое правильное сделать в компиляторе сервис для открытия файлов и вов ремя работы интеграции в этом сервисе перехватывать доступ к внешним файлам.
Таким образом получим универсальное решение для всех файлов.
ЗЫ Еще одно подтверждение вреда синглетонов. В данном случае проблемы создал File.Open.
... << RSDN@Home 1.2.0 alpha 4 rev. 1305>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
