We Keep Coding

Should I use IHttpClientFactory in a .NET 6 MVC Application?

After years writing .NET Framework 4.x web apps I'm finally trying to get to grips with writing new apps in .NET 6. Obviously one of the new features I'm keen to make use of is the native dependency injection.
I'm trying to work out how to create a typed HttpClient instance specific to an external web service which I will be calling throughout my application by injecting it as a dependency into my MVC application's controllers. Just about every article and tutorial I've read describes how to use AddHttpClient() in Program.cs and IHttpClientFactory in controller constructors to achieve this.
However, Microsoft's HttpClient guidelines state
In .NET Core and .NET 5+: Use a static or singleton HttpClient instance... This solves both the port exhaustion and DNS changes problems without adding the overhead of IHttpClientFactory
and
If your app requires cookies, consider disabling automatic cookie handling or avoiding IHttpClientFactory. Pooling the HttpMessageHandler instances results in sharing of CookieContainer objects. Unanticipated CookieContainer object sharing often results in incorrect code.
My MVC web app is using cookies, so it sounds like I want to avoid IHttpClientFactory. Is that right? If so, I'd expect to see it mentioned more in the various articles I've read. And, if it is right, what would be the correct way to create typed HTTP Client without using IHttpClientFactory?

Dependency injection with very different requirements

I have a C# ASP.NET MVC app that will need to connect to a third party WCF service but will probably move to a REST API in the future. I can nicely split out the app into various UI elements, View Models, interfaces, and implementations such as IRegister, ILogon, etc. and then potentially have WCF and REST versions of each.
The problem is for DI, I'd want to pass in a connection as part of the constructor of each. The nature of the WCF connection is a large Interface/contract object that then links to all available methods of the third party system. The REST connection needs to pass in an already established authorization token, and then make a series of API calls.
How would I implement the actual connection, would I just use a data type of "object".

I take it that you are trying to inject some sort of connection settings into some kind of repository. Depending on the methods called in the repository you are either calling an "old" WCF API or a "new" REST API. Since the WCF client is probably generated by making a Service Reference. The client itself can be injected.
For the REST API you would need some sort of factory that will retrieve first the security token and then return a self implemented REST client which has the token passed through its constructor. Of course depending on the lifetime of the token you might have to take different approaches to make sure your token remains valid.
The REST client would expose the required methods to make the calls passing the security token along with each request. The HttpClient class allows for default headers to be sent with every subsequent request. Making it very easy.

Create seperate class for Service and implement the interface as well
Example class : - SignInService.cs
Interface : - ISignInService
Then inject your service class via interface in startup.cs
Example -
public void ConfigureServices(IServiceCollection services)
{
services.AddTransient<ISignInService, SignInService>();
}

Web API client organization

I have a c# web API project that exposes a lot of methods through HTTP and I need to consume it in a c# web mvc application. I use the HttpClient class for this but my question is, how should I organize the access to this web API? for example, the web api project has n controllers, so I could create n IClient interfaces, one per API controller, in the mvc site, or just one big IClient that contains a method for every single API method exposed in the web api project? Is there a preferred approach for this? (that doesn't involve auto generated client code)

Work with DI in Asp .NET Core Web API

During the controller design I had the following question:
For example I have Controller that inject via constructor few services that work for more endpoints in that controller, further I want to add new functionality and add new endpoint to that controller as the result I need to add new Service injection to that controller, so system will instantiate of this services any time when user will use endpoints from that controller, even if user does not use them.
What a best approach in this situation, should I inject IServiceScopeFactory insted of service via constructor (for those services that used rare in controller), and create service instances directly in endpoint method ?
Thank for any advice !
UPD: For injection I use native Asp.Net Core mechanism

Best way to have two versions of a dependency per application part using Unity?

I am using Unity and MVC5 .NET 4.6
I have a data service.
It depends on a repository.
Which in turn depends on a connection.
The connection requires a username/token to make a connection OR a user/application guid to make a connection to a data source.
Both MVC controllers and Web API use the data service, but the data service should not care about how it is being used.
When I used an MVC controller the username and a token is is in the
claim.
When a connected application uses the API it must pass in the
user GUID and application GUI.
When I inject the data service to the controller Unity news up all the dependencies, data service with a repository injected and the repository the connection injected.
The question is what is the best pattern for getting the variables for the user to the connection from the current controller?

You can configure two different containers, one for MVC and one for Web API. Or, if you have a service that needs to be shared between MVC and Web API (e.g. a singleton service), you can create two Child Containers (call container.CreateChildContainer()) of the container you already have and only register the connection in the Child Containers. You can then make a distinction between which connection is used for MVC and for Web API.