Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IErrorHandler missing from nuget version 8.0.0 #5561

Open
Pixel452 opened this issue May 31, 2024 · 4 comments
Open

IErrorHandler missing from nuget version 8.0.0 #5561

Pixel452 opened this issue May 31, 2024 · 4 comments
Labels

Comments

@Pixel452
Copy link

Create new .NET 8 class library project
Add System.ServiceModel.Primitives from nuget
IErrorHandler is missing from System.ServiceModel.Dispatcher namespace
Looking at the source code and the documentation, it should be there, but it's not, am I missing something?

@antonfirsov
Copy link
Member

@mconnew @StephenBonikowsky @HongGit any clues?

@mconnew mconnew transferred this issue from dotnet/dotnet-api-docs Jun 3, 2024
@mconnew
Copy link
Member

mconnew commented Jun 3, 2024

Transferred issue to the dotnet/wcf repo.
What you're missing is that we have a reference assembly which doesn't contain all the api's as some aren't suitable (e.g. service only usage) for the client. We have some extra code in the implementation assembly due to in the early days prioritizing speed of porting over features over stripping out code which wasn't appropriate to port. Some api implementations technically got ported, but as we didn't add tests to make sure they were functioning, and they were ported as a side effect of porting some other feature, we didn't expose them in the reference assembly.
This api does seem like a reasonable api to expose. We should also expose ClientRuntime.EnableFaults at the same time.
@imcarolwang, could you expose IErrorHandler, ChannelDispatcher.ErrorHandlers, and ClientRuntime.EnableFaults and add tests for them. This is almost certainly going to need a scenario test. You can likely use an existing service endpoint as the scenario is a callback contract method throws an exception. You might need to look at .NET Framework WCF tests to see all the facets that need testing with these api's. Let me know if you need some pointers beyond that.

@Pixel452, what's the scenario that you are using an IErrorHandler for? It's going to take a little while before new api's are available in a public build, and there might be an alternative way to achieve the same thing using existing public api's.

@Pixel452
Copy link
Author

Pixel452 commented Jun 3, 2024

I'm porting a .NET Framework WPF app to .NET and there is an implementation of AsyncCommand that uses IErrorHandler, given that at the moment I'm still evaluating and testing if all the needed libraries and code are portable to .NET, I removed this feature, if everything else works, I'll go back to this. So, I can wait.

Thanks

@imcarolwang
Copy link
Contributor

@imcarolwang, could you expose IErrorHandler, ChannelDispatcher.ErrorHandlers, and ClientRuntime.EnableFaults and add tests for them. This is almost certainly going to need a scenario test. You can likely use an existing service endpoint as the scenario is a callback contract method throws an exception. You might need to look at .NET Framework WCF tests to see all the facets that need testing with these api's. Let me know if you need some pointers beyond that.

Hi @mconnew , I noticed there's IErrorHandler test case in the Framework test suite, where a CustomServiceBehavior implements IErrorHandler and is added to ServiceHost.Description.Behaviors for further functionality testing. However, in the scenario of callback service without a ServiceHost instance, I'm uncertain about applying the custom behavior to perform similar validation. It's possible I might be looking at the wrong test. If you could provide further guidance on this, I'd greatly appreciate it. Thank you!

@HongGit HongGit added the triaged label Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants