WCF / CoreWCF support

[g7ed6e]

Supporting WCF backend migrated to CoreWCF would be great to help modernize hosting of legacy apps.

Should the first step be getting ServiceDiscovery integration with client side ChannelFactory. Should this be implemented in a Aspire.ServiceModel component ?
Should an Aspire.Hosting.CoreWCF hosting package be created ?

relates to #3746

[davidfowl]

Should the first step be getting ServiceDiscovery integration with client side ChannelFactory. Should this be implemented in a Aspire.ServiceModel component ?

@mconnew Should advise. The service discovery package isn't tied to aspire, it will move to the extensions repository once it matures (lives for a version or so). Maybe this package belong on the CoreWCF repo.

Aspire.Hosting.CoreWCF

What would this do?

cc @mconnew

[g7ed6e]

Aspire.Hosting.CoreWCF

What would this do?

It may "stringify" the endpoint and the binding configuration to a connection string. Then the client side package would use that to create an instance of the correct binding.
ChannelFactory<TChannel> requires an Endpoint and a Binding. https://learn.microsoft.com/fr-fr/dotnet/api/system.servicemodel.channelfactory-1?view=net-8.0#constructors

Regarding client side package it would implement ServiceDiscovery integration and "unstringify" the connection string. It shoud accept an Action<ChannelFactory<T>> too to ease futher customization.

[davidfowl]

It may "stringify" the endpoint and the binding configuration to a connection string. Then the client side package would use that to create an instance of the correct binding.

What is the app host running that WCF is connecting to? Is this about talking to other WCF services?

[g7ed6e]

Client side WCF would connect to either a legacy .NET Fx WCF service which would not be part of the solution and thus can be considered as an external resource or a CoreWCF service that would be part of the solution.

So the Aspire.Hosting part would either :

• abstract an external WCF service
• host a CoreWCF service

[davidfowl]

I still feel like I'm missing something. Can you write out a code sample of what the apphost might look like?

[mconnew]

Here's my brain dump about the relevant areas that need to be addressed. The .NET WCF client doesn't support app.config based configuration for the binding for multiple reasons I won't go into right now. I want to have the binding config be loadable from an IConfiguration source using ConfigurationBinder. The next step is to do the same with EndpointAddress. An EndpointAddress is a lot more than just a wrapper to hold a Uri, it also can have an identity and default addressing headers too. Once these two components are hydratable from IConfiguration, then we can define a ServiceEndpoint (this is WCF's class, Aspire stole the name 😀) via config, which is effectively a three tuple of the address, binding, and the contract (this is sometimes referred to as the ABC of WCF). This is my existing intention before Aspire became a thing, and I think should still be implemented regardless of Aspire to be used in things like WPF apps etc, or if you aren't using Aspire.
I haven't had the time to dive into Aspire enough yet to see how much of an impedance mismatch this is with the Aspire design, but after a quick look at the API's I think there's a natural way to make it work. It looks like we could attach the Binding and Contract to the ServiceEndpoint (the Aspire class, @davidfowl this name clashing is going to be annoying long term) which has a Features property.
This is likely to change the shape of the API's I planned for the WCF client around configuration. The old ChannelFactory constructor for config was ChannelFactory<TChannel>(string configurationName) which was removed in WCF Client 6.0, and I had thought about introducing ChannelFactory<TChannel>(IConfiguration config) where you have already drilled down to the exact part of the config containing the channel details, or ChannelFactory<TChannel>(IConfiguration config, string configurationName) so you could specify a named config, which then could enable some nice named DI features. But that was using IConfiguration directly to read the (WCF) ServiceEndpoint information.
With Aspire in the mix, there's some things to now consider. Should an abstraction be created that ChannelFactory is passed which can get the configuration from either IConfiguration similar to how I just layed out, or get it from the Aspire endpoint discovery feature? Something like an IServiceEndpointReader which has an Aspire implementation as well as an IConfiguration implementation? Or we could have an IConfigurationSource implementation which translates the Aspire model into IConfiguration?
Another option is that ChannelFactory is derivable to add this sort of thing. We could add an AspireChannelFactory and a ConfigurationChannelFactory (would also need similar for DuplexChannelFactory).

On the service side, here's the solution I would like to see. You have a project with no mention of ASP.NET Core in it. It has a service class that either implements a service contract interface, or the service class itself is attributed with the ServiceContract attribute along with all the methods you want to expose. You then add a CoreWCF Aspire nuget package which provides a preconfigured opinionated WebApplication with CoreWCF all wired up and exposing the service in an opinionated way. We could potentially go a step further and have a csproj property where you specify your service implementation(s) and you wouldn't need to attribute anything, but that requires more feature work in CoreWCF to support attributeless services.

Some things to work out is what do we do on the client side for the contract interface? If the server has an interface, do we require the solution to have it declared in a shared library? Do we replicate it? What about data types, if there are domain specific DTO declared, do we spit out our own version of them for the client or expect shared code?