Logging DI sample does not work in a template without Minimal APIs

[mccreah]

Which sample is the bug for

DI logging in a template that was made without Minimal API use

Please see an example here https://github.com/mccreah/samples

Describe the bug

No matter what I do and how I register various business services I will always get the following exception on service calls:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Body>
        <s:Fault>
            <faultcode xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</faultcode>
            <faultstring xml:lang="sl-SI">The service implementation object was not initialized or is not available.</faultstring>
            <detail>
                <ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
                    <HelpLink i:nil="true"/>
                    <InnerException i:nil="true"/>
                    <Message>The service implementation object was not initialized or is not available.</Message>
                    <StackTrace>   at CoreWCF.Dispatcher.SyncMethodInvoker.InvokeAsync(Object instance, Object[] inputs)&#xD;
   at CoreWCF.Dispatcher.DispatchOperationRuntime.&lt;&gt;c__DisplayClass68_0.&lt;&lt;InvokeAsync&gt;b__0&gt;d.MoveNext()&#xD;
--- End of stack trace from previous location ---&#xD;
   at CoreWCF.Dispatcher.DispatchOperationRuntime.InvokeAsync(MessageRpc rpc)&#xD;
   at CoreWCF.Dispatcher.DispatchOperationRuntime.InvokeAsync(MessageRpc rpc)&#xD;
   at CoreWCF.Dispatcher.ImmutableDispatchRuntime.ProcessMessageAsync(MessageRpc rpc)&#xD;
   at CoreWCF.Dispatcher.MessageRpc.ProcessAsync(Boolean isOperationContextSet)</StackTrace>
                    <Type>System.InvalidOperationException</Type>
                </ExceptionDetail>
            </detail>
        </s:Fault>
    </s:Body>
</s:Envelope>

Exception details only:

<ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
                    <HelpLink i:nil="true"/>
                    <InnerException i:nil="true"/>
                    <Message>The service implementation object was not initialized or is not available.</Message>
                    <StackTrace>   at CoreWCF.Dispatcher.SyncMethodInvoker.InvokeAsync(Object instance, Object[] inputs)&#xD;
   at CoreWCF.Dispatcher.DispatchOperationRuntime.&lt;&gt;c__DisplayClass68_0.&lt;&lt;InvokeAsync&gt;b__0&gt;d.MoveNext()&#xD;
--- End of stack trace from previous location ---&#xD;
   at CoreWCF.Dispatcher.DispatchOperationRuntime.InvokeAsync(MessageRpc rpc)&#xD;
   at CoreWCF.Dispatcher.DispatchOperationRuntime.InvokeAsync(MessageRpc rpc)&#xD;
   at CoreWCF.Dispatcher.ImmutableDispatchRuntime.ProcessMessageAsync(MessageRpc rpc)&#xD;
   at CoreWCF.Dispatcher.MessageRpc.ProcessAsync(Boolean isOperationContextSet)</StackTrace>
                    <Type>System.InvalidOperationException</Type>
                </ExceptionDetail>

To Reproduce Steps to reproduce the behavior:

1. Clone my samples repo and run the other app LoggingSampleNoMinimalApis.
2. Make a SOAP request to the service.
3. Exception always occurs, service contructor is never hit when debugging.

Expected behavior No exception, service constructor should be called. The way it works in the Minimal API example.

Repo environment (please complete the following information):

• Windows 10
• x64
  • .NET 6
  • VS 2022

Additional context

If this issue should've been opened in the main CoreWCF repo, feel free to move it there.

[mccreah]

The issue was that the WS service was not registered with DI as either Singleton or Scoped. Without that registration the service works when it only has the default constructor.

But if you add a new constructor with dependencies and register those dependencies with DI you also have to register the service itself with the DI. Somewhat counterintuitive and not the same as it is with MVC controllers. Especially since one registration already happens with the UseServiceModel call.

// register the custom utility service
builder.Services.AddSingleton<IUtilityService, UtilityService>();

// if Service1 depends on IUtilityService you also need this! register the `Service` class with Dependency Injection, based on it being a single instance
builder.Services.AddSingleton<Service1>();