Проблемы с регистрацией динамического типа в .Net Remoting Service - PullRequest
Новая
       4

Проблемы с регистрацией динамического типа в .Net Remoting Service

0 голосов
/ 22 декабря 2010

Я использую Emit для создания некоторых динамических типов в моем проекте, особенно для замены «Декораторов» вокруг моих сервисных интерфейсов. Я также делаю это для класса, зарегистрированного в .Net Remoting как WellKnownServiceType. Однако, .Net Remoting, похоже, не очень хорошо работает с динамически генерируемыми типами. Сначала я получил: 

System.IO.FileNotFoundException: Could not load file or assembly 'Dynamic, Version=0.0.0.0, Culture=neutral, PublicKeyToken=XXXX' or one of its dependencies. The system cannot find the file specified.

Конечно, файл не существует, сборка динамическая, и я установил для Emit только «Выполнить» сборку, но не SaveAndRun.

Итак, перед регистрацией типа я вызываю Assembly.Load (type.Assembly.GetName ()). Теперь я получаю: 

System.Runtime.Remoting.RemotingException: Requested Service not found
Server stack trace: 
   at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(IServerChannelSinkStack sinkStack, IMessage requestMsg, ITransportHeaders requestHeaders, Stream requestStream, IMessage& responseMsg, ITransportHeaders& responseHeaders, Stream& responseStream)

Ошибка появляется только на стороне клиента как исключение из сервера. Я не вижу ошибок в журналах сервера.

Кто-нибудь знает, является ли это «общеизвестной» проблемой, что динамические типы нельзя использовать для размещения служб удаленного взаимодействия .net? Любые подсказки или указатели, чтобы обойти это?

** ОБНОВЛЕНИЕ **** Я перестал использовать Emit. Emit заставил меня добавить атрибут «InternalsVisibleTo» в мои основные сборки, что серьезно повлияло на запутывание. Скорее я переключился на генерацию кода с использованием пространства имен CodeDom. Работает красиво. Я вижу фактический исходный код, который выполняет эту работу, что очень полезно при отладке.

1 Ответ

1 голос
/ 22 февраля 2011

Я недавно столкнулся с точно такой же проблемой. Как вы, вероятно, заметили из трассировки стека, проблема возникает из Assembly.Load 

Server stack trace: 
   ...
   at System.Reflection.Assembly.Load(...)
   at System.Runtime.Remoting.RemotingConfigHandler.RemotingConfigInfo.LoadType(String typeName, String assemblyName)
   at System.Runtime.Remoting.RemotingConfigHandler.RemotingConfigInfo.GetServerTypeForUri(String URI)
   at System.Runtime.Remoting.RemotingConfigHandler.GetServerTypeForUri(String URI)
   at System.Runtime.Remoting.RemotingServices.GetServerTypeForUri(String URI)
   at System.Runtime.Remoting.Channels.BinaryServerFormatterSink.ProcessMessage(...)

Вы можете предоставить обработчик событий AssemblyResolve, который позволит вам контролировать загрузку вашей пользовательской сборки. визави: 

AppDomain.CurrentDomain.AssemblyResolve += delegate(object sender, ResolveEventArgs args)
{
    if (args.Name.Equals(type.Assembly.FullName))
        return type.Assembly;
    return null;
};
...