Question

我跟着：this article并在WCF服务中实现了它。它允许我们通过实现自定义IServiceBehavior，然后使用该服务行为修饰服务来创建没有无参数构造函数的Service实例，因此不需要例如：

[ServiceBehavior]
public class MyService : IMyService

我会

[InstanceProviderBehavior]
public class MyService : IMyService

然后我按照以下方式实现ApplyDispatchBehavior：

foreach (ChannelDispatcher cd in serviceHostBase.ChannelDispatchers) {
            foreach (EndpointDispatcher ed in cd.Endpoints) {
                if (!ed.IsSystemEndpoint) {
                    Console.WriteLine("Using InstanceProviderBehaviorAttribute");
                    ed.DispatchRuntime.InstanceProvider = new ServiceInstanceProvider(Configuration.Instance.Container);
                }
            }
        }

并提供我刚刚提供的服务实例：

public object GetInstance(InstanceContext instanceContext, Message message)
    {
        AlertQueryService result = Container.Resolve<AlertQueryService>();

        return result;
    }

我在Windows中运行它并按预期工作。但是在使用mono的linux中，它会抛出异常

异常默认构造函数未找到MyService类型

表示mono可能忽略了InstanceProviderBehaviorAttribute。

我注意到的另一件事是：

Console.WriteLine("Using InstanceProviderBehaviorAttribute");

在打开服务主机时在Windows中执行。在Linux中打开服务主机时，它不会在控制台中写入它。我们打开服务主机时也没有抛出linux中的异常，但是在IsInitiating中调用MyService操作时：

[OperationContract(IsInitiating = true)]
void Initialize();

这表示使用mono时，只有在我们调用IsInitiating操作时才解析服务实例。

任何想法为什么这个在Windows中运行而不是在linux中使用mono？为什么初始化行为不同？

由于

Answer 1

尝试在EndpointBehavior中添加InstanceContextProvider以及InstanceProvider。如果没有无参数构造函数，那么Mono implementation of ChannelDispatcher.ListenerLoopManager.Setup似乎不喜欢没有InstanceContextProvider的想法。

InstanceContextProvider本质上可以是一个无操作的实现。只要有一个实例，它就会在ListenerLoopManagerSetup中传递该检查，并愉快地继续使用您的InstanceProvider。

Re：为什么不同的实现...... Mono是一个重新实现而不是交叉编译甚至是端口。考虑Important Rules section of their Contribution Guidelines。直到最近，开发人员才能为项目做出贡献，如果他们看了MS源代码那么多。

WCF可扩展性 - 单声道的IInstanceProvider

1 个答案: