A few years ago I published a number of articles around using the National Weather Service NDFD web service to get current weather conditions and forecasts. Unfortunately a few months ago quite a few folks started mentioning the example applications had stopped working. I finally got time to look at the problem and have updated both the original articles and download examples. Just to tidy things up – and so folks won’t have to wait next time, I thought I would describe how I got everything working again. I’ll walk through the simplest example (the one from the “Consuming NDFD Web Services from a C# Client” post, but the debugging process and changes apply to all the examples that access the NDFD web service.
1. First I ran the original NdfdTest-Application example from the post. Yes, things weren’t looking so good.
2. So I downloaded and built the original project – and there were errors:
Clearly the service reference for the NDFD web service was not getting created.
3. Visual Studio can update service references if you ask so I right-clicked on the NdfdServiceReference and selected “Update Service Reference” from the shortcut menu and built the project again:
Ah ha! [Change 1] They changed the signature of the method used to get forecasts! To see what’s happened, double click on the NdfdServiceReference from the Solution Explorer in Visual Studio then expand the NdfdTest.NdfdServiceReference node in the Object Browser and click on the ndfdXMLPortType interface. It turns out they changed the signatures for all the methods, adding the ability to specify whether you want results in English (unitType.e) or Metric (unitType.m) units. So I modified the NDFDgetByDay function, adding a unitType.e parameter and ran the application – and we are still getting an Invalid Zip Code error. But now you can see in the output window we are getting a protocol exception:
4. This is good information, but not enough. So in Visual Studio I enabled breaking on any thrown Common Language Runtime Exception. I ran the application again, entered a zip code and bang!
What the heck is going on? We asked for for text/xml and we are getting text/html.
[Change 2] Somebody moved our web service – now it’s a web page instead!
5. I admit at this point, as soon as I updated the service reference, I should have gone to the app.config file and looked at what was generated for me. Well, never too late… Low and behold, there is a new address for the NDFD web service:
6. So finally, replace the address on our original ndfdXMLPort endpoint with the address from the newly generated ndfdXMLPort1 endpoint. Everything is working again.