dotnet / wcf

This repo contains the client-oriented WCF libraries that enable applications built on .NET Core to communicate with WCF services.
MIT License
1.72k stars 558 forks source link

FaultException<TDetail> is missing ctor FaultException(TDetail detail, string reason) #5553

Closed daniatic closed 6 months ago

daniatic commented 6 months ago

Describe the bug

FaultException is missing ctor FaultException(TDetail detail, string reason) in version 8.0.0 but shows up in the Microsoft Documentation and also in the src code of this project.

I checked by decompiling the source with dotPeek and the constructor does not show up, whereas when decompiling the 6.2.0 version the constructor is available.

I directly downloaded the packages from the nuget website to ensure that package resolution isnt the problem.

Furthermore, there are some matching symbol sources which show the constructor is available when it's not...

To Reproduce

Reference System.ServiceModel.Primitives as nuget and call the constructor FaultException(TDetail detail, string reason). Compiler won't compile.

Expected behavior Update the documentation and symbol files or include the constructor again.

Screenshots

image image

Additional context

mconnew commented 6 months ago

You are comparing the reference assembly for net8.0 with the implementation assembly for net6.0 which is why you are seeing a difference. There's no reason why we can't add that api, but there's a simple workaround you can do by using a different constructor.

var faultException1 = new FaultException<MyDetail>(new MyDetail(), "This is my reason");
// This is equivalent
var faultException2 = new FaultException<MyDetaul>(new MyDetail(), new FaultReason("This is my reason"));

@imcarolwang, can you add the missing constructor to the ref assembly along with some unit tests for them. Also look at other api's in FaultException\<TDetail> and related classes to see if there's anything else from the .NET Framework api surface that we should also expose.

daniatic commented 6 months ago

Thank you very much for your fast reply.

That's exactly the workaround I implemented - good to know, that it's equivalent. I think updating the ref assembly to include those constructors and maybe other implementations is a great idea, to ease the migration from .net framework.

mconnew commented 6 months ago

I'm closing this issue as a workaround has been identified, and the next release will include these api's.