dotnet Exception Handling

.NET Exceptions – System.ServiceModel.EndpointNotFoundException

Making our way through our detailed .NET Exception Handling series, today we’ll dive into the System.ServiceModel.EndpointNotFoundException. The EndpointNotFoundException is thrown when something goes awry while trying to connect to a Windows Communication Foundation (WCF) service-oriented application.

In this article we’ll examine the EndpointNotFoundException in more detail by looking at where it sits in the larger .NET exception hierarchy. We’ll also look at some functional C# code samples that illustrate how a basic service can be setup, and how invalid connections to such a WCF service might lead to EndpointNotFoundExceptions, so let’s get crackin’!

The Technical Rundown

All .NET exceptions are derived classes of the System.Exception base class, or derived from another inherited class therein. The full exception hierarchy of this error is:

Full Code Sample

Below is the full code sample we’ll be using in this article. It can be copied and pasted if you’d like to play with the code yourself and see how everything works.

When Should You Use It?

As mentioned in the introduction, the EndpointNotFoundException is tightly correlated with the Windows Communication Foundation (WCF), which is a .NET framework for easily creating service-oriented applications. Essentially, a WCF application provides at least one service endpoint (URI), which can be connected to and utilized via the service’s API. Plus, such API method calls can even be made asynchronously.

For the code sample today we’ve created a default WCF service application named MyService. It starts with the IMyService interface, which defines the basic service and data contracts the service will provide:

From there, the MyService service implements the IMyService interface, providing the GetData(int value) method to “retrieve” some data. Alternatively, a data contract can also be used to retrieve data, but for our simple example we’ll stick with directly invoking GetData(int value):

Now, to access the MyServiceClient() class we need to specifically reference the MyService service in our Visual Studio project. This can be done by right-clicking the project name and selecting Add > Service Reference. On this screen, click Discover to automatically detect available services from other projects that are active/in the same solution. In our case, MyService.svc is listed, so we select that, then we change the Namespace to MyServiceReference and click OK.

Going through this process will automatically add a reference to the MyService service in our App.config file, as seen below:

We’ve defined a few test methods to verify our connection to the MyService service, one which is a synchronous call (GetDataTest(int value)), and the other that is asynchronous (GetDataAsyncTest(int value)):

Running the above test code attempts to connect to MyService and passes the int value of 0, before returning the results, which we’ve output to the console log:

Cool, everything seems to be working as expected. The async call returns a System.Thread.Tasks.Task object, which is why the result is much more complicated than the direct method call, but we can see that the Result property is the same for both method calls.

Now, that’s all well and good, but we can also manually add services to our App.config file. Let’s see what happens if we change the endpoint.address value in App.config to the name of an invalid service, such as InvalidService.svc:

Executing the same two test methods with this change to the endpoint.address property produces the following output:

Ah hah! Here we see our good friend the EndpointNotFoundException popup. As the error message indicates, the specific reason for a thrown EndpointNotFoundException could be any of a variety of reasons, but typically it’s is because the provided endpoint.address value in App.config is incorrect.

To get the most out of your own applications and to fully manage any and all .NET Exceptions, check out the Airbrake .NET Bug Handler, offering real-time alerts and instantaneous insight into what went wrong with your .NET code, along with built-in support for a variety of popular development integrations including: JIRA, GitHub, Bitbucket, and much more.