FHIR Chat · Timeout with FHIR.NET

I'm just starting with FHIR.NET and am running into an issue with FHIR servers that I've confirmed to work through Postman. Every time I do a read, I get a timeout exception, even with the most stripped down code like this:
try
{
var client = new FhirClient("http://vonk.fire.ly", true);
var pat_A = client.Read<Patient>("Patient/1");
}
catch(Exception e)
{
Console.WriteLine(e.Message);
}
However, when I do a GET with Postman, I get a successful response in 120 ms with GET http://vonk.fire.ly/Patient/1. I get the same thing with the wildfhir server (among others), so it's not a vonk issue. Given I'm such a newby, it's likely I'm missing something fundamental, but can't figure out what it is.

René Spronk (Jan 23 2020 at 17:44):

I'm not a dotnet expert - but have you looked at https://github.com/FirelyTeam/fhirstarters/tree/master/dotnet ? There's also a separate dotnet stream on this chat forum.

Michele Mottini (Jan 23 2020 at 18:15):

Try client.Read<Patient>("1"); ?

Ken Miller (Jan 23 2020 at 21:21):

Nope, the resource is definitely required in the FHIR REST url.

One thing I neglected to mention is that I'm developing against the Xamarin.Forms framework. Perhaps this is an incompatibility with Xamarin.Forms. Does anyone know if FHIR.NET has been tested against Xamarin.Forms? Xamarin hasn't been mentioned here since 2017, so I expect it's not a widely used platform among implementers. It's disappointing, but for now I'll switch to coding my own REST client.

Brian Postlethwaite (Jan 30 2020 at 07:33):

You could build that code yourself and see where it is stuck.
We'd be happy to help fix it if you can ide tify the issue.
Is it running on Mac or android?

Brian Postlethwaite (Jan 30 2020 at 07:33):

I had to tweak to run in a uwp store app, which would also apply to the Mac platform, but that was an exception, not time out.

Ken Miller (Jan 31 2020 at 01:35):

Thanks, Brian. I'm under time pressure for this project, which is basically a quick and dirty one-off, and my hope for FHIR.NET is that is would have "just worked". Unfortunately, anything that causes me to explore the original source code for issues is a showstopper as far as using FHIR.NET at this point. Hopefully, I'll have flexibility to do this sometime later in February.

Also, I tried the same thing in a Blazor project using .NET Core 3.1 with the same result. Do you know if FHIR.NET is supposed to be compatible with .NET Core 3.1?

Brian Postlethwaite (Jan 31 2020 at 01:51):

I've used it with netcore 3.0, but haven't tried 3.1

Brian Postlethwaite (Jan 31 2020 at 01:51):

@Faraz Ahmed didnyou use it with xamarin?

Ken Miller (Jan 31 2020 at 01:56):

Check that, the problem in Blazor/netcore 3.1 wasn't a timeout, it was a thrown exception, with message "The value of the date string in the header is invalid.", so it seems like an entirely different issue. I checked with Postman, and the dates in the headers of the response seem OK.

Brian Postlethwaite (Jan 31 2020 at 01:59):

That's been reported before, I don't recall what the resolution was.
There was also one of the servers doing it strange too.
I hope at least you're using our serializers if not the rest client.

Ken Miller (Jan 31 2020 at 02:02):

Yes, this is using the FHIR.NET serializers with the same skeleton code I had in my initial post. This is against the Wildfhir v4 server. The Last-Modified header has a value of Sun, 8 Sep 2019 21:11:04GMT-00:00, so I don't know why the serializer would be choking on that. Thanks again for your help.