Столкнулся со проблемой передачи СОМ-объектов (в частности Excel) через Remoting. Есть клиент и сервер, оба на C#, код полностью управляемый. Добавляю к проектам сервера и клиента ссылку на СОМ-компонент Microsoft Excel 10.0 Object Library. Создаю на клиенте экземпляр Excel.ApplicationClass и пытаюсь передать его (как интерфейс Excel.Application) на сервер. При этом клиент наглухо зависает. Например, код простейшего метода сервера:

public void FillXL(Excel.Application xl)
{
    xl.Workbooks.Add(Excel.XlWBATemplate.xlWBATWorksheet);
}

код вызова на клиенте:

    Excel.Application xl = new Excel.ApplicationClass();
    xl.Visible = true;
    Server.FillXL(xl);   //Server - это экземпляр Remoting сервера

Показывается новое пустое приложение экселя, затем при вызове метода FillXL клиент виснет намертво, ни на что не отвечая. Даже если клиент и сервер на одной машине. Пробовал передавать параметр как Excel.ApplicationClass и как object с последующим приведением типов — та же ботва. Если Server сделать локальным объектом, естественно, все работает. В чем тут заморочка?
Раньше (на VB6 и VC6) подобную штуку можно было реализовать через OLE или DCOM. Можно ли такое в .NET? Можно ли передавать COM-интерфейсы через Remoting вообще? Может, это какая-нибудь фича Interopa вообще? С Interop только начал работать, так что не пинайте очень сильно, если какую глупость сморозил Буду рад любой помощи.

А сам вызов в сервер приходит?

Здравствуйте, Tom, Вы писали:

Tom>А сам вызов в сервер приходит?

Вызов приходит. Вызовы любых других методов проходят на ура. FillXL в описанной реализации виснет при вызове; если передавать параметр как object, то виснет при попытке конвертации к Excel.Application. Похоже, дело именно в обращении к COM-интерфейсу. Или в его передаче, или конвертации, или еще в чем((

Hello, "Koloto"
> Столкнулся со проблемой передачи СОМ-объектов (в частности Excel) через Remoting. Есть клиент и сервер, оба на C#, код полностью управляемый. Добавляю к проектам сервера и клиента ссылку на СОМ-компонент Microsoft Excel 10.0 Object Library. Создаю на клиенте экземпляр Excel.ApplicationClass и пытаюсь передать его (как интерфейс Excel.Application) на сервер. При этом клиент наглухо зависает.

Что-то где-то лочится. Запусти оба процесса под отладчиком (Галку Enable Unmanaged Debugging тоже стоит отметить) и когда все зависнет — нажми Break и посмотри стек каждого потока — можно будет определить что, где и на чем конкретно виснет.

Здравствуйте, TK, Вы писали:

TK>Что-то где-то лочится. Запусти оба процесса под отладчиком (Галку Enable Unmanaged Debugging тоже стоит отметить) и когда все зависнет — нажми Break и посмотри стек каждого потока — можно будет определить что, где и на чем конкретно виснет.


Вот вершушка стека вызовов на клиенте в момент зависания:

00000000()
system.dll!System.Net.Sockets.Socket.Receive(buffer, offset, size, socketFlags) + 0x8e bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.SocketStream.Read(buffer = {Length=4096}, offset = 0, size = 4096) + 0x30 bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.SocketHandler.ReadFromSocket(buffer = {Length=4096}, offset = 0, count = 4096) + 0x28 bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.SocketHandler.BufferMoreData() + 0x1f bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.SocketHandler.Read(buffer = {Length=4}, offset = 0, count = 4) + 0x9c bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.SocketHandler.ReadAndMatchFourBytes(buffer = {Length=4}) + 0x25 bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.Tcp.TcpSocketHandler.ReadAndMatchPreamble() + 0x18 bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.Tcp.TcpSocketHandler.ReadVersionAndOperation(operation = 0) + 0x1d bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.Tcp.TcpClientSocketHandler.ReadHeaders() + 0x32 bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(msg = {System.Runtime.Remoting.Messaging.Message}, requestHeaders = {System.Runtime.Remoting.Channels.BaseTransportHeaders}, requestStream = {System.Runtime.Remoting.Channels.ChunkedMemoryStream}, responseHeaders = <undefined value>, responseStream = <undefined value>) + 0x35 bytes
system.runtime.remoting.dll!System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(msg = {System.Runtime.Remoting.Messaging.Message}) + 0x83 bytes
mscorlib.dll!System.Runtime.Remoting.Proxies.RemotingProxy.CallProcessMessage(ms, reqMsg, proxySinks, currentThread, currentContext, bSkippingContextChain) + 0x62 bytes
mscorlib.dll!System.Runtime.Remoting.Proxies.RemotingProxy.InternalInvoke(reqMcmMsg, useDispatchMessage, callType) + 0x28d bytes
mscorlib.dll!System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(reqMsg) + 0x113 bytes
mscorlib.dll!System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(msgData, type) + 0x288 bytes
> XLClient.exe!TP.RemotingXL.XLForm.buttonServerFill_Click(sender = {System.Windows.Forms.Button}, e = {System.EventArgs}) + 0x56 bytes
...

Вот верхушка стека сервера в функции FillXL до момента конвертации object к Excel.Application:

xlserver.dll!TP.RemotingXL.XLServer.FillXL(xlObj = {System.Runtime.Remoting.Proxies.__TransparentProxy}) + 0x15 bytes C#
mscorwks.dll!791d94bc()
mscorwks.dll!793419bb()
mscorwks.dll!791d7b2f()
mscorwks.dll!79341689()
mscorwks.dll!79341697()
mscorwks.dll!79341bf2()
mscorwks.dll!791d60e1()
mscorlib.dll!79ba39f8()
> mscorlib.dll!System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(msg, methodPtr, fExecuteInContext) + 0x30b bytes
mscorlib.dll!System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(msg) + 0x9 bytes
mscorlib.dll!System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink.SyncProcessMessage(reqMsg) + 0x12c bytes
mscorlib.dll!System.Runtime.Remoting.Lifetime.LeaseSink.SyncProcessMessage(msg) + 0x25 bytes
mscorlib.dll!System.Runtime.Remoting.Messaging.ServerContextTerminatorSink.SyncProcessMessage(reqMsg) + 0x1b3 bytes
mscorlib.dll!System.Runtime.Remoting.Channels.CrossContextChannel.SyncProcessMessage(reqMsg) + 0x209 bytes
mscorlib.dll!System.Runtime.Remoting.Channels.ChannelServices.DispatchMessage(sinkStack, msg, replyMsg) + 0x22c bytes
mscorlib.dll!System.Runtime.Remoting.Channels.DispatchChannelSink.ProcessMessage(sinkStack, requestMsg, requestHeaders, requestStream, responseMsg, responseHeaders, responseStream) + 0x31 bytes
...

После подвисания на в стеке серверного процесса только стек запуска ф-ции Main().

Я не очень в этом секу, но судя по стеку на сервере проблема с синхронизацией процессов. Я прав или нет? Если да, то как это лечить?

Здравствуйте, Koloto, Вы писали:

K>Здравствуйте, TK, Вы писали:

TK>>Что-то где-то лочится. Запусти оба процесса под отладчиком (Галку Enable Unmanaged Debugging тоже стоит отметить) и когда все зависнет — нажми Break и посмотри стек каждого потока — можно будет определить что, где и на чем конкретно виснет.


K>Вот вершушка стека вызовов на клиенте в момент зависания:
K>После подвисания на в стеке серверного процесса только стек запуска ф-ции Main().


Поробуйте убрать оттуда [STAThread]

Здравствуйте, EM, Вы писали:

EM>Поробуйте убрать оттуда [STAThread]

Заработало! Если у клиента убрать атрибут [STAThread] перед Main(), то все работает. Однако, в серверном процессе этот атрибут как ни странно может быть оставлен.
Большое спасибо всем, в особенности ЕМ.

Hello, "Koloto"
>
> Заработало! Если у клиента убрать атрибут [STAThread] перед Main(), то все работает. Однако, в серверном процессе этот атрибут как ни странно может быть оставлен.

На эту тему писали, что на сервере, если оставить атрибут STAThread, то может поточь память

Здравствуйте, TK, Вы писали:

TK>Hello, "Koloto"
>>
>> Заработало! Если у клиента убрать атрибут [STAThread] перед Main(), то все работает. Однако, в серверном процессе этот атрибут как ни странно может быть оставлен.

TK>На эту тему писали, что на сервере, если оставить атрибут STAThread, то может поточь память

Сенкс, буду знать.

Здравствуйте, Koloto, Вы писали:

K>Здравствуйте, EM, Вы писали:

EM>>Поробуйте убрать оттуда [STAThread]

K>Заработало! Если у клиента убрать атрибут [STAThread] перед Main(), то все работает. Однако, в серверном процессе этот атрибут как ни странно может быть оставлен.
K>Большое спасибо всем, в особенности ЕМ.

Теперь самое главное — понять почему оно заработало
Мне например непонятно. И ещё проверить бы это на FW 2.0

Здравствуйте, Tom, Вы писали:
Tom>Теперь самое главное — понять почему оно заработало
Tom>Мне например непонятно. И ещё проверить бы это на FW 2.0
Дык для COM ST апартмента нужен был работающий цикл сообщений,
а при ремотинг вызове .NET его не крутит вот и получается вис.

EM>>Поробуйте убрать оттуда [STAThread]

K>Заработало! Если у клиента убрать атрибут [STAThread] перед Main(), то все работает. Однако, в серверном процессе этот атрибут как ни странно может быть оставлен.
K>Большое спасибо всем, в особенности ЕМ.

Заработало, но на счет "все" я погорячился Использование ActiveX-компонент, а также Drag&Drop требуют STA модели. Это что ж мне теперь для каждой формы с ActiveX создавать отдельный STA-поток? Или наоборот оставить [STAThread] перед Main() и для передачи COM-объектов серверу создавать MTA-потоки? Уж больно криво получается(( И с синхронизацией еще придется мучиться...

M>Дык для COM ST апартмента нужен был работающий цикл сообщений,
M>а при ремотинг вызове .NET его не крутит вот и получается вис.

Дак а причём тут STA поток и ремотинг?
Вызов ремотинга и COM вообще не должны никаким боком быть связаны....

Здравствуйте, Tom, Вы писали:

M>>Дык для COM ST апартмента нужен был работающий цикл сообщений,
M>>а при ремотинг вызове .NET его не крутит вот и получается вис.

Tom>Дак а причём тут STA поток и ремотинг?
Tom>Вызов ремотинга и COM вообще не должны никаким боком быть связаны....
А сервер как работает с сылкой COM объекта которую ему заслали?

Tom>>Дак а причём тут STA поток и ремотинг?
Tom>>Вызов ремотинга и COM вообще не должны никаким боком быть связаны....
M>А сервер как работает с сылкой COM объекта которую ему заслали?
Обьект A создаёт COM обьект. Причём создаёт из STA апатрамента
Обьект A создаёт обьект B — находящийся в другом аппдомене и вызывает метод обьекта B, передав COM обьект. COM обьекты передаются в ремотинге не с использованием стандартного механизма COM — маршалинга, а просто как MBR .NET обьекты. Таким образом обьект B имеет ссылку на MBR, которую и вызывает. В теории вызов должен попасть в аппдомаин и апартамент STA обьекта A и оттуда должен быть вызван COM обьект. У автора вопроса же явно ремотинг делает какой то вызов в апартамент обьекта A а так как исходящие вызовы remoting — это не вызовы COM и они не крутят цикл выборки сообщений, то происходит нарушение реентерабельности аппартамента. Вопрос остаётся один. ЗАчем remoting делает вызов COM в апартамент обьекта A. В теории этого не должно быть вообще

Здравствуйте, Tom, Вы писали:

Tom>У автора вопроса же явно ремотинг делает какой то вызов в апартамент обьекта A а так как исходящие вызовы remoting — это не вызовы COM и они не крутят цикл выборки сообщений, то происходит нарушение реентерабельности аппартамента. Вопрос остаётся один. ЗАчем remoting делает вызов COM в апартамент обьекта A. В теории этого не должно быть вообще
Дык и я том же говорил
Сервер вызывает объект А как родной .НЕТ MBR и о COM вообще по идее знать не должен... вот все вызовы и приходят в изначальный COM STA.

Здравствуйте, migel, Вы писали:

M>Здравствуйте, Tom, Вы писали:

Tom>>У автора вопроса же явно ремотинг делает какой то вызов в апартамент обьекта A а так как исходящие вызовы remoting — это не вызовы COM и они не крутят цикл выборки сообщений, то происходит нарушение реентерабельности аппартамента. Вопрос остаётся один. ЗАчем remoting делает вызов COM в апартамент обьекта A. В теории этого не должно быть вообще
M>Дык и я том же говорил
M>Сервер вызывает объект А как родной .НЕТ MBR и о COM вообще по идее знать не должен... вот все вызовы и приходят в изначальный COM STA.
Ещё раз повторябю, что вызовы не должны приходить нивкакой STA. Вызовы по ремотингу идут между апп доменами. Так что, то, что происходит у автора вопроса — это баг ремотинга, который приводит к нарушению реентерабельности