Но эта реализация использует XLinq который доступен только в третьем фрэймворке. Если добавить этот макрос в список станадартных, то мы не сможем скомпилировать ее (а значи и компилятор) со вторым фрэймворком.
Переписывать код без использования XLinq не хочется (много бесполезной работы).
Как лучше поступить?
Мне видятся следующие выходы из ситуации:
1. Отказываемся от совместимости с фрэймворком ниже 3.5.
2. Создаем отдельные библиотеки (макросо и обычную) и помещаем туда все зависящее от фрэймворков более новых нежели 2.0.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ka3a4oK, Вы писали:
KK>Мне нужен второй фреймвок, например.
Здорово. так как поступить то? Мы же не можем вообще не испольовать новых возможностей фрэймворка?
Собственно данный макрос только сам использует XLinq. В генерируеемом им коде никакие особенности 3-го фрэймворка не встречаются.
Вопрос к тем кому "нужен 2-ой фрэймворк". Вы не можете использовать 3.5 в свой работе или вам просто нужно чтобы конечное приложение работало на 2-ом фрэймворке?
Иными словами можно ли разрешить использование фич не входящих во второй фрэймворк в рамках компилятора, при условии, что компилируемые им приложения все таки будут работать под управлением 2-го фрэймворка?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Вопрос по совместимости со вторым фрэймворком
Здравствуйте, VladD2, Вы писали:
VD>Иными словами можно ли разрешить использование фич не входящих во второй фрэймворк в рамках компилятора, при условии, что компилируемые им приложения все таки будут работать под управлением 2-го фрэймворка?
Я думаю что можно. Все равно студия 2008 требует 3.5 дотнет, как, впрочем, и шарпдевелоп.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[4]: Вопрос по совместимости со вторым фрэймворком
Здравствуйте, hardcase, Вы писали:
H>Я думаю что можно. Все равно студия 2008 требует 3.5 дотнет, как, впрочем, и шарпдевелоп.
Да, но сейчас компилятор можно собрать и запустить под 2.0. А после этого под 2.0 можно будте запускать только модули полученные в процессе компиляции, но не сам компилятор.
В общем, интересно аргументированное мнение тех кто против такого подхода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Вопрос по совместимости со вторым фрэймворком
Здравствуйте, VladD2, Вы писали:
VD>Вопрос к тем кому "нужен 2-ой фрэймворк". Вы не можете использовать 3.5 в свой работе или вам просто нужно чтобы конечное приложение работало на 2-ом фрэймворке?
В работе — хоть 4. Если не придётся переводить пользователей на 3.5, то лично я не против.
Ce n'est que pour vous dire ce que je vous dis.
Re[3]: Вопрос по совместимости со вторым фрэймворком
VD>Вопрос к тем кому "нужен 2-ой фрэймворк". Вы не можете использовать 3.5 в свой работе или вам просто нужно чтобы конечное приложение работало на 2-ом фрэймворке?
В компайл тайме — хоть десятый.
VD>Иными словами можно ли разрешить использование фич не входящих во второй фрэймворк в рамках компилятора, при условии, что компилируемые им приложения все таки будут работать под управлением 2-го фрэймворка?
Главное не забывать о поддержке Линукса. Последние mono поддерживают практически весь стандартный .NET 3.5, поэтому использовать классы из System.Core, System.Xml.Linq можно. А W?F наверное не стоит.
Но генерируемые сборки должны быть совместимы с 2.0, так как много машин живут себе именно со вторым фреймворком.
С другой стороны, я абсолютно не понимаю, что будет делать макрос поддержки файлов *.settings в базовой библиотеке Nemerle.
