|
xelos
Гость
|
 |
« : 13-01-2005 15:19 » |
|
в общем есть прога с использованием FrameWork 1.1. Эта прога будет общаться с внешним девайсом по MODBUS (физический протокол - RS232). Поскольку в FrameWork 1.1 нету поддержки последовательного порта - пришлось написать класс-обертку над апишными функциями (вынесено в отдельную) - что означает, что теряем независимость от ОС. Судя по анонсам, в FrameWork 2.0 будет реализована поддержка последовательного порта. Следовательно, в будущем хотелось бы, чтобы программа работала с родными функциями, а не через апи. Как организовать, чтобы в будущем переход с класса-обертки на родные функции был бы как можно безболезненней. На ум приходит техника COM - основная программа обращается через интерфейсы к реализации (т.е. в будущем можно подменить библиотеку реализации). Почитав статьи про COM в .NET возникают вопросы по поводу сосуществования двух технологий... Или может я вообще голову не тем, чем надо забиваю? Если в будущем я перепишу класс последовательного порта с родными функциями - можно ли сейчас предусмотреть возможность его подключения?
|
|
|
|
|
Записан
|
|
|
|
|
npak
|
 |
« Ответ #1 : 13-01-2005 15:33 » |
|
Xelos
У тебя сейчас есть класс, который работает с СОМ портом через WinAPI, так? И ты хочешь, что бы при переходе на Framework 2.0 тот код, которых пользуется существующим классом, не пострадал?
Для этого после выхода Framework 2 тебе надо будет переписать класс, предоставляющий доступ к СОМ порту. Оставить интерфейс, но в методах вызовы WinAPI заменить на вызовы методов .NET классов из нового Framework'а
Все изменения будут локализованы в одном месте, и код пользователей (теоретически) ничего не заметит.
|
|
|
|
« Последнее редактирование: 20-12-2007 20:33 от Алексей1153++ »
|
Записан
|
|
|
|
|
xelos
Гость
|
|
« Ответ #2 : 13-01-2005 16:29 » |
|
все так.
т.е. просто предлагаешь потом переписать класс для коммуникации с девайсом, скомпилировать его в длл и на машине пользователя просто заменить длл?
не будет ли проблем, если просто заменить длл? еще свежа в памяти история создания СОМ (не порт который, а объектная модель) - который и был призван разрешить проблемы различных версий реализаций объектов.
Я вот думаю, если FrameWork 2.0 будет работать по-другому с объектами (по другому память выделять или еще что...), не повторится ли история с dll-hell? может стоить оформить класс что-нибудь типа ActiveX компонента (через библиотеку контролов) и следующую версию тоже как ActiveX компонент - благо это все поддерживается .НЕТ?
|
|
|
|
|
Записан
|
|
|
|
|
npak
|
|
« Ответ #3 : 14-01-2005 08:41 » |
|
Да, я предлагаю после выхода Framework подменить библиотеку с классами для доступа к порту.
Микрософт клянётся и божится, что классы, сделанные под Framework 1 будут грузиться и работать без изменений -- обещают полную совместимость.
Если в новой версии будет сохранён интерфейс класса и функциональность методов, то клиентский код должен работать.
|
|
|
|
|
Записан
|
|
|
|
|
xelos
Гость
|
|
« Ответ #4 : 14-01-2005 09:30 » |
|
ок, спасибо, так и сделаю...
|
|
|
|
|
Записан
|
|
|
|
|
xelos
Гость
|
|
« Ответ #5 : 24-01-2005 08:10 » |
|
Еще раз пересмотрел как распространяются приложения .НЕТ и как контролируется безопасность сборок. Возникает вопрос. Микрософт пишет, что в манифесте сборки сохраняется версия сборки, ссылки на внешние сборки, и ключи идентификации (даже для внешних сборок). Получается, что для замены существующей сборки более поздней версией надо делать позднее связывание приложения и сборки, иначе CLR не запустит из моего приложения новую версию сборки, т.к. идентификационные ключи не совпадают... Иначе надо переопределять политку проверки сборок (не понятно как делается). Или я не так понял MSDN? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconassemblyversioning.asp |
|
|
|
|
Записан
|
|
|
|
|
npak
|
|
« Ответ #6 : 24-01-2005 12:05 » |
|
|
|
|
|
|
Записан
|
|
|
|
|
xelos
Гость
|
|
« Ответ #7 : 24-01-2005 14:20 » |
|
пасип, похоже то что надо... Позднее связывание сборки с приложением...
|
|
|
|
|
Записан
|
|
|
|
|
xelos
Гость
|
|
« Ответ #8 : 24-01-2005 14:33 »  |
|
у меня в классе приложения объявлен член класса, который и осуществляет коммуникацию RS232. В случае с поздним связыванием, такое не пройдет, поскоку приложение не знает о классе... Значит порядок - объявляем переменную типа Object, объявляем переменную типа Assembly, потом через System.Reflection, потом вытаскивать классы из сборки через GetType и тип Object кастить на типы.
хм, не слишком я мудрю?
|
|
|
|
|
Записан
|
|
|
|
|
xelos
Гость
|
|
« Ответ #9 : 25-01-2005 10:02 » |
|
в общем проблему с версиями можно решить через конфигурационный файл приложения... некрасивое, однако, решение...
|
|
|
|
|
Записан
|
|
|
|
|
