Привет всем.
Пытаюсь делать первые шаги в .net+C#
Разрешите задать вопрос профи по следующей проблеме.
Задумана следующая задача.
1. Необходимо создать приложение-службу. С этим я разобрался
2. Служба должна поддерживать модульную (plug-ins) структуру задач. С этим вроде бы тоже уже практически все понянятно.
3. Каждая из задач имеет общий для всех задач интерфейс собственной конфигурации, реализуя окно (или, UserControl с процедурой собственной настройки), принимая XML-структурированную конфигурацию, и по окончании настройки, возвращая её модифицированную).
4. Нужно создать приложение, конфигурирующее данную службу, путём показа окон конфигурирования задач в данном приложении.
Подскажите пожалуйста, в каком направлении рыть/читать Пытался получать контролы через Remoting — все упорно работает в приложении сервера (ведь все контролы — наследники MarshalByRefObject). Вообще, возможна ли реализация такой модели?
Заранее спасибо за потраченное время
24.01.06 17:05: Перенесено модератором из '.NET' — TK
E>3. Каждая из задач имеет общий для всех задач интерфейс собственной конфигурации, реализуя окно (или, UserControl с процедурой собственной настройки)
E>4. Нужно создать приложение, конфигурирующее данную службу, путём показа окон конфигурирования задач в данном приложении.
Ну да, всё правильно. Только нужно UserControl'ы создавать и отображать в клиентском приложении, а не в службе.
А для конфигурирования службы создать отдельный объект с нужными методами/свойствами. Но без визуального UI.
Да, и неплохо бы продумать вопросы безопасности. Чтобы каждый любой не мог бы обратиться к функциям конфигурирования.
Ммм.. Видимо я не полностью описал задуманное
По замыслу приложение-конфигуратор не имеет доступа к plug-ins задач службы. Поэтому хотелось бы узнать о возможности создания визуальных средств конфигурирования задач в процессе клиента-конфигуратора, пользуясь только средствами Remoting.
Извиняюсь за кривизну объяснения, что-то типа:
IConfigure: Configure(xmlIn)/* Предоставляет визуальные ср-ва конфигурирования task1 */,
xmlOut GetCurCfg() /* Возвращает текущую конфигурацию */
IConfigure.Configure(..)<-Клиент<->.NET Remoting<->Служба(сервер)<->[task1.dll]IConfigure CreateCfgControl()
E>По замыслу приложение-конфигуратор не имеет доступа к plug-ins задач службы.
А как тогда оно будет их конфигурировать? Подход подозрительный.
Например, в модели Microsoft такого нет. Есть некие службы — SQL Server, Windows Event Log, IIS. Все эти службы администрируются из общего приложения — консоли управления MMC.
Но MMC управляет службами при помощи внешних ActiveX, установленных локально в MMC. Невозможно подключиться к неизвестному серверу и автоматически загрузить оттуда контролы ActiveX для конфигурирования средствами MMC.
Почему так? В первую очередь из-за небезопасности такого "удалённо-интерфейсного" подхода. Если тебе в приложения пришлют объект просто для исполнения, никто не знает что за баги или трояны в этом коде. Под видом конфигурирования может установиться троян.
.NET Remoting тоже не позволит приложению исполнять такие контролы без присутствия сборки локально в приложении. В отличие от Java, Remoting не позволяет загружать код, только данные или ссылки.
M>.NET Remoting тоже не позволит приложению исполнять такие контролы без присутствия сборки локально в приложении. В отличие от Java, Remoting не позволяет загружать код, только данные или ссылки.
Правильно ли я понял?
1. Придётся мудрить перекачку taskX.dll от сервера (службы) клиенту (конфигуратору)
2. Динамически загружать конфигурационные контролы
3. Все время вести контроль версий taskX.dll на клиенте
Я надеялся, что Remoting позволит решить эту задачу проще
E>1. Придётся мудрить перекачку taskX.dll от сервера (службы) клиенту (конфигуратору)
Вот здесь и грабли.
Можно, конечно, так сделать. Но мировые тенденции против этого. Ну, ты же наверняка слышал, SOA.
Если делать красиво, то конфигурационные DLL должны устанавливаться в клиентском приложении отдельно от сервисов. Не загружаться, а как-то при компилировании, или при устанвке копироваться.
Кстати, есть забавный вариант реализации UI. Конфигурировать при помощи PropertyGrid (в System.Windows.Forms).
Например, конфигурация сервиса инкапуслирована в классе MyServiceSettings. Получаешь конфигурацию через какой-нибудь GetServiceSettings, отображаешь пользователю. И по нажатию Apply отсылаешь изменённую обратно, через какой-нибудь SetServiceSettings(...).
Спасибо Буду думать
Но уже из чисто спортивного интереса Возможно ли в случаях, подобных моёму, в клиенте создать объект, доступ к типу которого (сборке) имеет только сервер? Допускает ли это модель .NET? Либо создать объект на сервере и передать его клиенту? Я так понимаю в этом случае клиенту придётся также передать (описать) и <тип> этого объекта (как-то передать метаданные ) Извиняюсь за *возможно * глупые вопросы.
E>Но уже из чисто спортивного интереса Возможно ли в случаях, подобных моёму, в клиенте создать объект, доступ к типу которого (сборке) имеет только сервер?
Клиент может создать/получить объекты только тех типов, которые он имеет в локальных сборках.
То есть, не получится передать с сервера какой-то неизвестный объект, а на клиенте посмотреть список его методов/свойств и удивиться: "Ух тышка, на сервере, оказывается, есть свойство ProxyAuthorizePassword!"
Так не выйдет, клиент должен иметь метаданные, а с сервера передаётся только ссылка с полным специфицированным именем типа.
Правильно ли я понял, данные в общем случае мы передать можем (сериализация), а код — нет?
В том смысле, что даже если клиент знает о типе передаваемого объекта, нет способа передать код (например при несоодветствии версий типа объекта)? Кстати, а что будет в случае, если клиент и сервер будут работать со сборками, в которых реализация типа изменена?
E>Правильно ли я понял, данные в общем случае мы передать можем (сериализация), а код — нет?
Очень правильно. В самую точку!
E> Кстати, а что будет в случае, если клиент и сервер будут работать со сборками, в которых реализация типа изменена?
Версия (и вообще, полное имя сборки) передаётся как часть имени типа.
Но, если у клиента и сервера сборки одной номинальной версии, но реально разные, клиент будет исполнять что-то своё, не сообразуясь с сервером.
Кстати, важно понимать, что код методов из объектов MarshalByRef, переданных ссылкой с сервера, будет исполняться на сервере. Поэтому вообще не важно, какая там реализация у клиента в сборке.
Это не касается [Serializable] не-MBR объектов, их методы исполняются на клиенте. Также на клиенте исполняются и методы MBR, созданных полностью локально. Ну и все статические методы исполняются на клиенте, хоть бы там триста серверов было вокруг.
Здравствуйте, mihailik, Вы писали:
M>Можно, конечно, так сделать. Но мировые тенденции против этого.
Это не мировые тенденции, не стоит выдавать желаемое маркетологами за действительное.
M>Если делать красиво, то конфигурационные DLL должны устанавливаться в клиентском приложении отдельно от сервисов.
ИМХО это как раз некрасиво. Красиво это, к примеру, ClickOnce.
M>Кстати, есть забавный вариант реализации UI. Конфигурировать при помощи PropertyGrid (в System.Windows.Forms).
Точно так же вылезет необходимость транспортировки редактируемого типа и кастомных редакторов и конвертеров.
M>>Можно, конечно, так сделать. Но мировые тенденции против этого. AVK>Это не мировые тенденции, не стоит выдавать желаемое маркетологами за действительное.
Ну, если Microsoft натурально закапывает в землю Remoting, на разработку которого ушли миллионы баксов — это уже тенденция.
M>>Если делать красиво, то конфигурационные DLL должны устанавливаться в клиентском приложении отдельно от сервисов. AVK>ИМХО это как раз некрасиво. Красиво это, к примеру, ClickOnce.
Я не уверен наверняка, но у ClickOnce по-моему нет готовой поддержки плагинов для приложения. То есть Application — это unit of deployment, а так чтобы его гранулировать — уже не получится без напильника.
А несколько ClickOnce-приложений на одной машине тоже друг друга не видят
Поэтому я сомневаюсь, что в данном случае ClickOnce будет красиво выглядеть.
M>>Кстати, есть забавный вариант реализации UI. Конфигурировать при помощи PropertyGrid (в System.Windows.Forms).
AVK>Точно так же вылезет необходимость транспортировки редактируемого типа и кастомных редакторов и конвертеров.
Совершенно согласен. Но в данном случае это одно из самых прозрачных и беспроблемных решений. И в контексте первой реализации, и при выпуске версий.
Здравствуйте, mihailik, Вы писали:
M>Ну, если Microsoft натурально закапывает в землю Remoting, на разработку которого ушли миллионы баксов — это уже тенденция.
В чем выражается закапывание?
M>Я не уверен наверняка, но у ClickOnce по-моему нет готовой поддержки плагинов для приложения.
Мы ведь не про плагины, а про транспортировку сборок с сервера на клиент, не так ли? А к плагинам ни SOA, ни Remoting отношения не имеют.
AVK>>Точно так же вылезет необходимость транспортировки редактируемого типа и кастомных редакторов и конвертеров.
M>Совершенно согласен. Но в данном случае это одно из самых прозрачных и беспроблемных решений.
Это решение ничем от варианта с транспортировкой UsertControl не отличается.
M>>Ну, если Microsoft натурально закапывает в землю Remoting, на разработку которого ушли миллионы баксов — это уже тенденция. AVK>В чем выражается закапывание?
В замораживании разработки — во-первых.
Во вторых, в том, что Microsoft открытым текстом говорит: Remoting рекомендуется только для нишевого применения.
В третьих, в том, что не выпускаются книги по технологии.
Да что тут говорить, для полного эффекта осталось только продать весь Remoting какому-нибудь средней руки производителю карандашей. Чтобы уж самые заядлые оптимисты поняли: бросай ружьё да всплывай поскорей.
M>>Я не уверен наверняка, но у ClickOnce по-моему нет готовой поддержки плагинов для приложения.
AVK>Мы ведь не про плагины, а про транспортировку сборок с сервера на клиент, не так ли?
Нет, не так ли:
M>Если делать красиво, то конфигурационные DLL должны устанавливаться в клиентском приложении отдельно от сервисов.
AVK>ИМХО это как раз некрасиво. Красиво это, к примеру, ClickOnce.
Мы про конфигурационные DLL, которые устанавливаются в универсальном клиентском приложении а-ля-MMC.
M>>Совершенно согласен. Но в данном случае это одно из самых прозрачных и беспроблемных решений.
AVK>Это решение ничем от варианта с транспортировкой UsertControl не отличается.
Разве что транспортировка кода небезопасна. Не говоря уже о куче технических проблем.
Здравствуйте, mihailik, Вы писали:
AVK>>В чем выражается закапывание?
M>В замораживании разработки — во-первых.
Вобще то Remoting входит в состав фреймворка. И в версии 2.0 был прилично доработан. С чего ты взял что его заморозили?
M>Во вторых, в том, что Microsoft открытым текстом говорит: Remoting рекомендуется только для нишевого применения.
Ну и? Веб-сервисы, чтоб ты знал, тоже для нишевого применения. Индига, судя по всему, тоже будет для нишевого
M>Да что тут говорить, для полного эффекта осталось только продать весь Remoting какому-нибудь средней руки производителю карандашей. Чтобы уж самые заядлые оптимисты поняли: бросай ружьё да всплывай поскорей.
Глупости какие. Remoting неотделимая часть фреймворка. В отличие от сервисов и WCF.
AVK>>Мы ведь не про плагины, а про транспортировку сборок с сервера на клиент, не так ли?
M>Нет, не так ли: M>
M>>Если делать красиво, то конфигурационные DLL должны устанавливаться в клиентском приложении отдельно от сервисов.
AVK>>ИМХО это как раз некрасиво. Красиво это, к примеру, ClickOnce.
M>Мы про конфигурационные DLL, которые устанавливаются в универсальном клиентском приложении а-ля-MMC.
Ну и? При чем тут плагины?
AVK>>Это решение ничем от варианта с транспортировкой UsertControl не отличается.
M>Разве что транспортировка кода небезопасна.
Для этого МС предоставляет прекрасные механизмы.
M> Не говоря уже о куче технических проблем.
AVK>Вобще то Remoting входит в состав фреймворка. И в версии 2.0 был прилично доработан. С чего ты взял что его заморозили?
Да, ADO.NET доработан. Да, ASP.NET, WinForms. Но в Remoting'е фактически доработок: сетевая безопасность и лояльная сериализация. Никак не тянет даже на просто приличные доработки.
M>>Во вторых, в том, что Microsoft открытым текстом говорит: Remoting рекомендуется только для нишевого применения.
AVK>Ну и? Веб-сервисы, чтоб ты знал, тоже для нишевого применения. Индига, судя по всему, тоже будет для нишевого
Но про индигу и веб-сервисы открытым текстом этого не говорит. Те, кому надо — понимают. Но трубить такое налево-направо политика разрешает только про Remoting.
M>>Да что тут говорить, для полного эффекта осталось только продать весь Remoting какому-нибудь средней руки производителю карандашей. Чтобы уж самые заядлые оптимисты поняли: бросай ружьё да всплывай поскорей.
AVK>Глупости какие. Remoting неотделимая часть фреймворка. В отличие от сервисов и WCF.
А я не спорю, неотделимая. Только вот System.Collections тоже уже как ни крути — неотделимая часть. А из майнстрима выписали.
M>>Мы про конфигурационные DLL, которые устанавливаются в универсальном клиентском приложении а-ля-MMC. AVK>Ну и? При чем тут плагины?
Это лучше ты объясни, при чём тут ClickOnce. Ты предлагаешь распространять конфигурационные DLL при помощи ClickOnce? Интересно, каким же образом...
Или просто ClickOnce вдруг вспомнилось, как пример красоты. Хорошо ещё не кремлёвские куранты.
AVK>>>Это решение ничем от варианта с транспортировкой UsertControl не отличается. M>>Разве что транспортировка кода небезопасна.
AVK>Для этого МС предоставляет прекрасные механизмы.
Да? Готовые механизмы?
И почему же, интересно, они до сих пор не прикручены штатно к Remoting, эти "прекрасные механизмы"?
Ясно почему. Потому, что таких прекрасных механизмов нет. Есть инструменты, при помощи которых можо за пару часов собрать самодельное "чудо". И работать оно будет на честном слове автора.
M>> Не говоря уже о куче технических проблем. AVK>Да нет там особых проблем.
Вот проимпортировать WSDL, получить с сервера класс и передать его в PropertyGrid — это нет особых проблем. Максимум — придётся изворачиваться для вложенных свойств и страдать от отсутствия локализации.
А писать под каждый сервис отдельный UserControl-конфигуратор, вырабатывать механизм передачи сборок с сервера на клиент, тестировать проблемы сетевых интерфейсов и плохо докачанных сборок, думать, как быть с зависимостями, в том числе, лежащими в GAC, делать SandBox и тестировать его, задавать для сборок атрибуты AllowPartiallyTrustedCallers и планировать их риски...
Нет, нет и нет. Это сложное и только сложное решение. Ничего простого.
Здравствуйте, mihailik, Вы писали:
M>Да, ADO.NET доработан. Да, ASP.NET, WinForms. Но в Remoting'е фактически доработок: сетевая безопасность и лояльная сериализация.
Это уже очень немало. А еще ты забыл новый IpcChannel. Ну и внутрях там много чего поправили и доделали. Скажем в регексах не больше изменено, но это же не значит что МС на них забил.
M> Никак не тянет даже на просто приличные доработки.
Ну да, фигня какая, всего то аутентификацию и шифрование реализовали Чтобы ты знал — эти технологии явно не для пользования внутри фреймворка.
AVK>>Ну и? Веб-сервисы, чтоб ты знал, тоже для нишевого применения. Индига, судя по всему, тоже будет для нишевого
M>Но про индигу и веб-сервисы открытым текстом этого не говорит.
Зато на практике получаешь по полной. Того нельзя, этого не моги. Да и танцев с бубном в случае WCF, несмотря на обещания, столько, что в итоге ремоутинг по сложности останется далеко позади. Ты посмотри на behavior к примеру — куда там синкам.
AVK>>Глупости какие. Remoting неотделимая часть фреймворка. В отличие от сервисов и WCF.
M>А я не спорю, неотделимая. Только вот System.Collections тоже уже как ни крути — неотделимая часть. А из майнстрима выписали.
Да не очень то его выписали. Горы кода самого фреймворка его используют.
M>>>Мы про конфигурационные DLL, которые устанавливаются в универсальном клиентском приложении а-ля-MMC. AVK>>Ну и? При чем тут плагины?
M>Это лучше ты объясни, при чём тут ClickOnce. Ты предлагаешь распространять конфигурационные DLL при помощи ClickOnce?
Да.
M> Интересно, каким же образом...
Стандартным. Формируешь deployment manifest, выкладываешь на сервер. При запуске клиента все само обновится автоматом, без какого либо участия со стороны пользователя, админа и программиста.
M>>> Не говоря уже о куче технических проблем. AVK>>Да нет там особых проблем.
M>Вот проимпортировать WSDL, получить с сервера класс и передать его в PropertyGrid — это нет особых проблем.
Пробовал? Если нет, попробуй. Не забудь про кастомные редакторы и конвертеры. Без них редакторские возможности PG никуда не годятся.
M>А писать под каждый сервис отдельный UserControl-конфигуратор,
Это не имеет отношения к технологиям взаимодействия, это отдельный вопрос.
M> вырабатывать механизм передачи сборок с сервера на клиент,
Ты прям как фильтруешь все написанное. ClickOnce спасет отца русской демократии.
M> тестировать проблемы сетевых интерфейсов
Это чего такое?
M> и плохо докачанных сборок,
Опять же ClickOnce все это обеспечивает.
M>Нет, нет и нет. Это сложное и только сложное решение. Ничего простого.
AVK> Скажем в регексах не больше изменено, но это же не значит что МС на них забил.
Да, парадоксальный аргумент. Хм, уделал...
M>> Никак не тянет даже на просто приличные доработки.
AVK>Ну да, фигня какая, всего то аутентификацию и шифрование реализовали Чтобы ты знал — эти технологии явно не для пользования внутри фреймворка.
Наверняка какой-нибудь крупный клиент через линию партнёрства заказал. А они, эти крупные клиенты, всегда такие ретрограды...
AVK>Зато на практике получаешь по полной. Того нельзя, этого не моги. Да и танцев с бубном в случае WCF, несмотря на обещания, столько, что в итоге ремоутинг по сложности останется далеко позади. Ты посмотри на behavior к примеру — куда там синкам.
Ну, я посмотрю, спасибо за наводку. Пока не до того, хотя хорошо вот хоть Go-Live, наконец, прилепили.
AVK>>>Глупости какие. Remoting неотделимая часть фреймворка. В отличие от сервисов и WCF.
M>>А я не спорю, неотделимая. Только вот System.Collections тоже уже как ни крути — неотделимая часть. А из майнстрима выписали.
AVK>Да не очень то его выписали. Горы кода самого фреймворка его используют.
Вот-вот. Так и Remoting останется где-то в недрах, а для прикладного кода разве что экстремалы будут его использовать.
M>>Это лучше ты объясни, при чём тут ClickOnce. Ты предлагаешь распространять конфигурационные DLL при помощи ClickOnce? M>> Интересно, каким же образом...
AVK>Стандартным. Формируешь deployment manifest, выкладываешь на сервер. При запуске клиента все само обновится автоматом, без какого либо участия со стороны пользователя, админа и программиста.
Хм. Многообещающе...
И как эта конфигурационная DLL будет запускаться в контексте общего конфигурационного приложения? Боюсь, тут никак
M>>Вот проимпортировать WSDL, получить с сервера класс и передать его в PropertyGrid — это нет особых проблем.
AVK>Пробовал? Если нет, попробуй. Не забудь про кастомные редакторы и конвертеры. Без них редакторские возможности PG никуда не годятся.
Годятся. На уровне сконфигурировать сервис покатят. Конечно, это не on-screen-menu для домашнего кинотеатра, но администраторы такие интерфейсные недоработки хавают за милую душу, и ещё спасибо передают через секретаршу.
M>>А писать под каждый сервис отдельный UserControl-конфигуратор, AVK>Это не имеет отношения к технологиям взаимодействия, это отдельный вопрос.
Отдельный? Ну нет, в рамках той же давно поставленной задачи.
M>> вырабатывать механизм передачи сборок с сервера на клиент, AVK>Ты прям как фильтруешь все написанное. ClickOnce спасет отца русской демократии.
Я не фильтрую. Просто ты своё решение нигде не описал. Там кусочек, там намёк. Догадайтесь, мол, братцы.
M>> и плохо докачанных сборок, AVK>Опять же ClickOnce все это обеспечивает.
Я вот только не понимаю, при чём тут ClickOnce? Механизм хороший, но как он соотносится с конфигурированием "составных" сервисов, о котором говорилось в задаче?
Если ты предлагаешь создать монолитный конфигуратор для всех тех сервисов, то я — за. Каким боком эта модель относится к Remoting — фиг его знает. Почему именно ClickOnce — наверное, потому, что просто хорошая технология?
Здравствуйте, mihailik, Вы писали:
AVK>>Да не очень то его выписали. Горы кода самого фреймворка его используют.
M>Вот-вот. Так и Remoting останется где-то в недрах, а для прикладного кода разве что экстремалы будут его использовать.
А ремоутинг и не предназначен для прикладного кода, это очень низкоуровневая технология.
AVK>>Стандартным. Формируешь deployment manifest, выкладываешь на сервер. При запуске клиента все само обновится автоматом, без какого либо участия со стороны пользователя, админа и программиста.
M>Хм. Многообещающе... M>И как эта конфигурационная DLL будет запускаться в контексте общего конфигурационного приложения?
Как обычно в случае динамического подключения dll. Assembly.Load и вперед.
M> Боюсь, тут никак
А в чем проблема?
AVK>>Пробовал? Если нет, попробуй. Не забудь про кастомные редакторы и конвертеры. Без них редакторские возможности PG никуда не годятся.
M>Годятся. На уровне сконфигурировать сервис покатят.
Не прокатят. Простейший список предопределенных значений в дополнению к возможности написать руками уже не прокатывает без собственного конвертера. Даже Browse[false] на служебные свойства и то не поставишь.
M> Конечно, это не on-screen-menu для домашнего кинотеатра, но администраторы такие интерфейсные недоработки хавают за милую душу, и ещё спасибо передают через секретаршу.
Пример можно?
AVK>>Это не имеет отношения к технологиям взаимодействия, это отдельный вопрос.
M>Отдельный? Ну нет, в рамках той же давно поставленной задачи.
В рамках той же задачи, но отдельный.
AVK>>Ты прям как фильтруешь все написанное. ClickOnce спасет отца русской демократии.
M>Я не фильтрую. Просто ты своё решение нигде не описал.
Олег, я надеялся что ты догадаешься хотя бы посмотреть, что вобще такое ClickOnce и для чего он нужен, прежде чем заявлять, что он для обсуждаемой задачи не подходит.
M> Там кусочек, там намёк. Догадайтесь, мол, братцы.
Гадать не нужно, нужно было открыть MSDN. Ну или хотя бы спросить.
AVK>>Опять же ClickOnce все это обеспечивает.
M>Я вот только не понимаю, при чём тут ClickOnce? Механизм хороший, но как он соотносится с конфигурированием "составных" сервисов, о котором говорилось в задаче?
Если делать красиво, то конфигурационные DLL должны устанавливаться в клиентском приложении отдельно от сервисов. Не загружаться, а как-то при компилировании, или при устанвке копироваться.
Так вот, я тебе и попытался показать, что ничего плохого в загрузке сборок нет, более того, есть прекрасные технологии у МС, которые позволяют это сделать просто и качественно.
M>Если ты предлагаешь создать монолитный конфигуратор для всех тех сервисов, то я — за.
Я хоть раз упомянул слово "монолитный"?
M> Каким боком эта модель относится к Remoting — фиг его знает.
А при чем здесь ремоутинг?
M> Почему именно ClickOnce — наверное, потому, что просто хорошая технология?
Наверное потому что эта технология специально создавалась для удаленной загрузки и обновления приложения и его частей.
Пытался получать контролы через Remoting — все упорно работает в приложении сервера (ведь все контролы — наследники MarshalByRefObject). Вообще, возможна ли реализация такой модели?
Спасибо огромное 
Чтобы ты знал — эти технологии явно не для пользования внутри фреймворка.