На машине существуют COM объекты,  которые реализуют некоторые интерфейсы.
С другой машины необходимо удаленно вызывать методы интерфейса.

Задача 1: уйти от COM объектов создав некую абстракцию.
Задача 2: сделать это максимально платформонезависимо.

В голову пришел простой способ реализации на основе JSON.
Передача данных по сети Tcp-клиентом (может быть механизм более высокого уровня).

Сначала попытался реализовать каждый метод.

Например:


Соответственно, получив JSON запрос я просто проверяю метод и вызываю нужный.
В рельтате получается офигенный if/else if т.к. методов много.

Также возникает проблема с передвчей аргументов. Каждый метод должен знать какие аргументы каких типов 
должны быть переданы.

Хотелось бы это унифицировать. Например, по типу класса найти нужный объект и вызвать метод по строковому имени.
Только типы класса и методы передаются как строки.

Можно ли это реализовать ?

Может не нужно изобретать велосипед и воспользоваться WCF?

я же говорил - платформонезависимо.

P.S. тут искал и нашел всякие Type и GetMethod. Может как это прикрутить можно ?

Хочешь сказать, что машина, на которой "существуют" COM-объекты не под виндой работает?  Если кроссплатформенность требуется для удаленной машины, то с WCF никаких проблем не возникнет, поскольку данными машины будут обмениваться с помощью XML или JSON, да и WSDL описание сервиса тоже будет сгенерировано.

Можно, правда дать подробные инструкции трудно, поскольку не совсем понятно, как ты работаешь с COM. Обычно сборка взаимодействия генерится сама при добавлении ссылки на библиотеку или с помощью утилиты tlbimp. Но если ты все сам делаешь, то конкретно для твоего случая порядок действий примерно таков:
В пространстве System.Reflection находится почти все, что понадобится. Assembly - этот класс содержит ряд статических методов, с помощью которых можно получить ссылку на сборку. Далее вызываешь у нее метод CreateInstance для получения экземпляра, для этого правда придется передать ему полное имя класса, но если они все в одном пространстве имен - это не проблема. Получив экземпляр для получения Type вызови у него GetType, далее GetMethod( ему надо передать имя и опять-таки строкой, как тебе и надо), ну а уже у метода Invoke

Можно использовать WCF Data Services и экспозить OData, клиенты для которой есть для многих платформ.

до этом машины пофигу. Вопрос к машине управления (хоть наладонник, хоть PC,...)


Я создаю экземпляры COM. Получается, что мне нужно после создания держать карту
Map<String, Object>, чтоб можно было найти по имени типа нужный COM ?


это понятно


вот тут тоже проблема. Число и тип аргументов различны. Как выэывать методы через Invoke ?
Ведь сигнатуру метода знает только вызывающий код (на управляющей машине). А код на стороне COM хотелось бы вызывать универсально.

Может ли Invoke принимать массив аргументов типа object и сам понимать сколько ему аргументов нужно и какого типа ?

Давай начнем с того, как ты их создаешь и как вообще работаешь с ком. Обычно для этого генерируется сборка взаимодействия, в которой все типы являются CLR-типами и никакой проблемы рефлексии в этом плане быть не должно. Если ты делаешь это иначе, то опиши как и почему. Поначалу ты вообще написал, что создал собственные оболочки для ком-типов(насколько я понял).

Инвоук не может, но методинфо(объект, у которого ты вызываешь инвоук) содержит сведения о параметрах.

я создаю их через Microsoft.VisualBasic.Interaction.CreateObject
получаю интерфейс, и работаю с ним вызывая методы.



то есть ему можно передать массив аргументов ?

Ну вот в этом причина того, что ты не можешь получить сведений о типе. Добавь ссылку на соответствующую библиотеку и все значительно упростится.

Ну, а что по-твоему представляет из себя второй параметр метода?
http://msdn.microsoft.com/ru-ru/library/a8...8VS.100%29.aspx

а что мне это даст ?

Как минимум сведения о типах. И вот это

тебе уже не понадобится.

diadiavova, я слабоват в C#. Можно подробнее пояснить или примерчик для наглядности

Добавляешь в проект ссылку на библиотеку, в которой определены нужные ком-классы и все интерфейсы будут доступны как обычные нет типы. Дальше сможешь с помощью рефлексии получить тип по имени в том числе. Добавь ссылку и сам все увидишь.

имеется ввиду создать экземпляр по имени ?

Аааааааа. Не знаю с какими ком-типами ты работаешь. Для примера возьмем библиотеку Scripting Runtime. (находится по адресу C:\Windows\System32\scrrun.dll). Допустим мне пришло имя FileSystemObject и надо создать экземпляр этого типа. Для начала нам понадобится ссылка на сборку, в которой определены типы. Если ты пишешь под 4-ый фреймворк, то по умолчанию типы внедряются в твою сборку, а это нам не надо. Для того, чтобы сборка взаимодействия создавалась отдельно, в обозревателе решений открой ветку "Ссылки", найди там свою ком-библиотеку(в моем случае она называется Scripting), выдели ее и перейди в окно свойств(или через контекстное меню), там увидишь свойства сборки, тебе надо свойству "Внедрить типы взаимодействия" присвоить False.

В коде сначала надо получить ссылку на сборку взаимодействия, в которой определены нужные типы. Проще всего это сделать, используя какой-нибудь тип, определенный в этой сборке. Я использовал все тот же FileSystemObject, хотя можно было и любой другой, они все имеют ссылку на свою сборкуТеперь имея сборку можно получить объектКак видишь, от сборки нам понадобился только путь к файлу, а к полному имени типа добавился суффикс "Class". Дальше с этим объектом можно работать.

Добавлено через 35 секунд
Не забудь импортировать