System.AddIn в WCF

У меня есть вопрос об использовании инфраструктуры AddIn, предоставляемой .NET Framework (в настоящее время используется 3.5 SP1), реализованной в пространстве имен System.AddIn. Я создаю прототип с простой надстройкой. Эта надстройка создается в бизнес-логике службы WCF.

Реализация бизнес-логики (показан только необходимый код):

internal class BusinessLayer : IBusinessLayer
{
    public object Execute(object toConvert, Operation operation)
    {
        IDictionary<string, AddInToken> tokens = AddIns.Store.GetAddInsTokens(@"c:\SomePathToStore");

        foreach (KeyValuePair<string, AddInToken> token in tokens)
        {
            if (operation.Name == token.Key && operation.Version == token.Value.Version)
            {
                ConversionHostView view = token.Value.Activate<ConversionHostView>(AddInSecurityLevel.FullTrust);

                object converted =  view.Convert(toConvert);

                AddInController.GetAddInController(view).Shutdown();

                return converted;
            }
        }

        throw new InvalidOperationException("No operation found!");
    }
    ...
}

Реализация услуги (показан только необходимый код):

public class Service : IServiceContract
{
    IBusinessLayer bl;

    public Service()
    {
        bl = BL.BLFactory.GetBL();
    }

    public object Execute(object toConvert, ERES.ConversionService.Entity.Operation operation)
    {
        return bl.Execute(toConvert, operation);
    }
    ...
}

Я создал два модульных теста. Один вызов прямого метода бизнес-логики, другой метод WCF. Прямой вызов работает нормально, но если я активирую надстройку из WCF, я получаю следующее исключение:

«Невозможно преобразовать прозрачный прокси в тип ERES.ConversionService.Contract.IConversionContract»

Трассировки стека:

в ConversionHostViewToContractAdapter_ConstructorInvoker (Object) в System.AddIn.Hosting.AddInActivator.AdaptToHost [T] (конвейер AddInToken, IContract addInContract) в System.AddIn.Hosting.AddInActivator.ActivateInstall (контроллер домена). , Boolean weOwn) в System.AddIn.Hosting.AddInActivator.Activate [T] (токен AddInToken, PermissionSet permissionSet, String appDomainName) в System.AddIn.Hosting.AddInActivator.Activate [T] (уровень AddInTokencurityLe) на System.AddIn.Hosting.AddInActivator.Activate [T] (токен AddInToken, уровень AddInSecurityLevel) на System.AddIn.Hosting.AddInToken.Activate [T] (AddInSecurityLevel trustLevel) в ERES.ConversionLevel Object.BL , Операция операции) в C: \ Documents and Settings \ kc \ My Documents \ Visual Studio 2008 \ Projects \ ConversionServiceSolution \ ERES.ConversionService.BL \ BusinessLayer.cs: строка 44 в ERES .ConversionService.Service.Execute (объект для преобразования, операция операции) в C: \ Documents and Settings \ kc \ My Documents \ Visual Studio 2008 \ Projects \ ConversionServiceSolution \ ERES.ConversionService \ Service.svc.cs: строка 25 в SyncInvokeExecute (Object , Object [], Object []) в System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke (экземпляр объекта, входы Object [], Object [] и выходы) в System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin (MessageRpc & rpc)

Любая помощь?

С уважением Антон Кальчик

ОБНОВЛЕНИЕ: мне удалось обойти это с помощью этого кода:

ConversionHostView view = token.Value.Activate<ConversionHostView>(AppDomain.CurrentDomain);

Таким образом, в этом случае можно выполнить AddIn только в том же домене приложения, что и сам сервис. Но я не понимаю почему?


person Anton Kalcik    schedule 18.06.2009    source источник


Ответы (1)


Глядя на то, где возникает ошибка, это когда надстройка адаптируется для хоста.

Проблема здесь в том, что MEF пытается найти и передать интерфейс, который не может найти.

Сборки вашего контракта находятся в том же месте, что и сборки надстроек?

person stevenrcfox    schedule 04.01.2012
comment
Извините, но у меня больше нет кода, так как это был прототип 2 года назад. Спасибо. - person Anton Kalcik; 04.01.2012