Update Microsoft.Windows.Compatibility pack to latest WCF version

[safern]

WCF is shipping a new package version: 4.8.0 and also including a new package in this release: System.ServiceModel.Federation. We should update the package version and include this new package.

We should do this as part of the first 5.0 servicing release.

cc: @ericstj @HongGit

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[ericstj]

Does System.ServiceModel.Federation represent .NETFramework API or is it net-new? If the latter it doesn't feel like it belongs in compat pack. We shouldn't be looking at the compat-pack as the vehicle for WCF, instead folks should directly reference WCF if they need it. The compat pack is meant to bring back API that folks needed from Windows/.NETFramework

[safern]

I asked @HongGit the same question and the response I got was that it was part of .NET Framework as well, so I think it makes sense to include it as part of WCF.

[ericstj]

I spot checked a couple types and found the following:
https://github.com/dotnet/wcf/blob/master/src/System.ServiceModel.Federation/ref/System.ServiceModel.Federation.Ref.csproj - targets netstandard2.0 only indicating the types are added to all frameworks, including .NETFramework.

The WSFederationHttpBinding class exists in .NETFramework, but in the System.ServiceModel namespace
https://docs.microsoft.com/en-us/dotnet/api/system.servicemodel.wsfederationhttpbinding?view=netframework-4.8

Whereas the one in this package exists in System.ServiceModel.Federation namespace, and has slightly different case WsFederationHttpBinding (note lower case 's')
https://github.com/dotnet/wcf/blob/f12e680dbbe3f052c68198f4eb737016cc31029d/src/System.ServiceModel.Federation/ref/System.ServiceModel.Federation.cs#L37

So there may be some overlap in concepts, but the assembly wasn't designed to work with .NETFramework in the same way as the rest of the compat pack. If that was the intent, then those namespaces and type names need to be fixed and a desktop façade needs to be added to the package.

[safern]

Good find... then I agree we should not include that package into the compat pack. @HongGit FYI.

[HongGit]

@ericstj I think what you pointed out is already fixed in the official release.

@safern could we get this in 5.0.2?

[ericstj]

@ericstj I think what you pointed out is already fixed in the official release.

@HongGit doesn't look like it to me. The official release is 4.8.0? That still only has a single assembly in the package:
lib\netstandard2.0\System.ServiceModel.Federation.dll
Now if you install this package into a net48 project and try to use it you get type conflicts:

C:\scratch\fed\Class1.cs(9,23): error CS0104: 'WSFederationHttpBinding' is an ambiguous reference between 'System.ServiceModel.Federation.WSFederationHttpBinding' and 'System.ServiceModel.WSFederationHttpBinding'

Here's a repro project, should I open a bug in dotnet/wcf?
fed.zip

The compat package is for exposing types which exist in both .NETFramework and .NETCore that aren't part of the default shared framework. It's not for adding new types that can cause confusion or new porting issues. If you redesign API as part of porting that should not be going into the compat package.

[HongGit]

Chatted with @mconnew briefly that this is intentional as the implementation in System.ServiceModel.Federation namespace are new, and different from .NET framework. I was under the wrong impression that we need to get System.Servicemodel.Federation into the windows compat pack. No need to add that package in the compat pack.

Sorry about the confusion.