.NET Standard Support Removed from Lamar 7 - Can I Add It Back?

[twinter-amosfivesix]

Wondering if there was a specific reason for removing .NET Standard 2.0 support from Lamar 7.

The commit that removed .NET Standard from everything was just removing it from the .csproj <TargetFrameworks> elements (basically).

I tried out adding .NET Standard 2.0 back into the Lamar source code where it was removed. Everything compiled and all the tests passed.

I'm looking for a version of Lamar that works with .NET Framework 4.7.2 (so .NET Standard 2.0) and Microsoft.Extensions.DependencyInjection 6.0. Weird combo I know. I can explain more if you'd like.

Would you accept a PR adding back in .NET Standard 2.0 and MS.E.DI 6.0 support? I can add in whatever kind of testing you like. Thanks!

[jeremydmiller]

@twinter-patriot I just didn't want to have to support the full .Net framework to be honest. And yes, I'll take a PR. You'll need the core Lamar.Testing library to also target .Net 4.7.2 whatever, and be running in the GH actions.

[twinter-amosfivesix]

Awesome! I will get on that tomorrow. I may need help with the GH actions; I'm not sure how to run them in a forked repo; seems there's something special there.

[twinter-amosfivesix]

@jeremydmiller Lamar.csproj is master has netstandard2.0 in <TargetFrameworks> right now. Do I still need to do any work for this?

[maulik-modi]

@twinter-patriot , would you mind sharing few lines about combining these two? Although, I have never used Microsoft.Extensions.DependencyInjection with .NET Framework, I am looking to upgrade large codebase that uses Spring to Lamar as I found that Microsoft's built-in DI does not support Property Injection or Resolving service by name.

Lamar that works with .NET Framework 4.7.2 (so .NET Standard 2.0) and Microsoft.Extensions.DependencyInjection 6.0. Weird combo I know. I can explain more if you'd like.

[twinter-amosfivesix]

would you mind sharing few lines about combining these two?

Here's the deal. We have a .NET Framework 4.7.2 monolith and some .NET 5 microservices. I'm part of the team that maintains the microservice templates. Part of each microservice is a C# client that the monolith (or other microservices) can use to easily talk to the microservice. The clients use HttpClient and HttpClientFactory. HttpClientFactory requires that you use MEDI. So our clients all have an IServiceCollection extension method like AddMyClient() that uses the HttpClientFactory stuff to register an HttpClient that's setup as needed. These clients are published in NuGet packages that target .NET Standard 2.0. That allows the monolith to use the clients in the NuGet packages. The monolith uses Lamar 6 right now as it's IoC container. We have some IoC setup code in the monolith where we new up a ServiceCollection and then call the AddMyClient() methods. We then copy all of the registered services out of the ServiceCollection into a Lamar ServiceRegistry. (I got that pattern from somewhere.) So the client IoC stuff all works good in the monolith. But since the client NuGets use HttpClientFactory and HttpClientFactory uses MEDI, that means when we add the client NuGet packages the monolith projects, MEDI also gets added to the monolith. So far so good.

Our microservices also use Lamar and MEDI internally. No problems there.

So let's say some developer of a microservice wants to upgrade from .NET 5 to .NET 6. That means they're going to upgrade MEDI to version 6. To be consistent they'll likely also upgrade the MEDI used by the microservice client to version 6. The client is in the same project as the microservice code and the "easy upgrade" button most IDEs give you for NuGets upgrade them in all projects in the solution. So now the microservice client uses MEDI 6. That NuGet gets published. At some point the monolith gets upgraded to that latest version of the client NuGet, which used MEDI 6. 💥 Boom! That's when things break.

The .NET Framework 4.7.2 monolith uses Lamar 6. The dependencies for Lamar targeting .NET Standard 2.0 include MEDI but are version limited to 2.0.0 through 5.9.0. Which means the monolith cannot upgrade to MEDI 6. Which means the monolith cannot upgrade to the latest version of the microservice client. Which means the microservice cannot upgrade to .NET 6.

Well yeah OK, the microservice can upgrade to .NET 6. Developers would just have to be sure to not upgrade the MEDI that's used in the microservice client. Things should work OK then. But with lots of development teams and more and more microservices, how often do you think developers are going to miss that crucial detail? I'm betting more than I want. Thus this issue. 😄

[jeremydmiller]

This is done.