Can't start Wcf DataPortal with Csla 5.5

[amselem]

Hi
When launching the WCF dataportal with Csla 5.5 in a .NetFW 4.8 project it gives me this error:

It's weird because Csla 5.5 (Net46) takes a dependency on v.3.1.9 of this package so why is it trying to load v3.1.0?:
<package id="Microsoft.Extensions.DependencyInjection.Abstractions" version="3.1.9" targetFramework="net461" />

I found this link where it describes that Microsoft.Extensions.DependencyInjection.Abstractions is missing TargetFramework net461: https://github.com/dotnet/extensions/issues/434

I used Fusion logger and I think that what's happening here is that Microsoft.Extensions.DependencyInjection 3.1.9 package is trying to load Microsoft.Extensions.DependencyInjection.Abstractions 3.1.9 but can't load it (because of the previous bug) and it fallsback to 3.1.0 because 3.1.0 is the latest version that targets 4.6.1 (I guess)

I see that Csla 5.5 (net 5.0) already takes a dependency on both v5.0.0 Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.DependencyInjection.Abstractions. Well, it happens that these v.5.0.0 packages also target net 4.6.1 !

So the fix is simply to update both Microsoft.Extensions.DependencyInjection and Microsoft.Extensions.DependencyInjection.Abstractions packages to v5.0.0 in the csla net46 project

I tested it and Wcf Dataportal is running again with these changes

Does it make sense? Can these packages be upgraded for csla 5.5.1?

[rockfordlhotka]

I've created #2409 to consider this fix/change.

I have resisted updating all the .NET 4.6.1 references because doing so will force all 4.6.1 users to update all their references as well, whether they are ready or not - so it is a potential breaking change for folks. Microsoft doesn't guarantee that the newer 5.0 versions are backward compatible with the 3.1.9 versions.

And yet I see what you are saying about the WCF blocker.

btw, in CSLA 6 I'm removing WCF entirely from the core CSLA build. If someone wants WCF still in the future, I'll welcome a separate WCF channel implementation like the existing RabbitMQ and gRPC channels in the codebase.

[amselem]

I see that Csla 5.5 already references the Microsoft.* packages v5.0 when targeting .net 5.0 , but references 3.1.9 when targeting .netfw 4.6.
So right now I could (theoretically) have inconsistent behavior if I share a Business Object library with a project targeting 4.6 and another targeting 5.0 because of differences in the implementation of the Microsoft library, is this right?
Or the business library isn't supposed to be used between different versions of .net framework (same csla version)?

I'd also think that this problem will also surface with other DataPortal implementations, not only WCF. It looks like a problem of the Microsoft.Extensions.DependencyInjection.Abstractions 3.1.9 libraray when targeting NetFw 4.6 target.

I see that Csla 5.5 , already

[rockfordlhotka]

CSLA 6 will be targeting only current packages, as CSLA 6 accepts breaking changes that might occur from such a change. And CSLA 6 drops support for WCF too.

In my mind, switching these dependencies is not a bug fix, so instead of 5.5.1, this would be a 5.6.0 change. And even then, there's some risk of breaking people's existing codebases. Still, it does seem necessary to get WCF working again.