API Fails for some instances

I have a windows form application that uses a REST API for tax lookup. The published application works on my windows 10 PC, and a windows 2012 server. IT fails on other windows 10 pcs, windows 11 pcs, and VMWare Horizon clients (VDI). When the application halts, it does so here with a failed API request (the request is in GET https format based on the production environment at Avalara)

Dim client = New AvaTaxClient("bollookup", "1.0", Enviroment.MachineName, AvaTaxEnvironment.Production).WithSecurity("accountid", "licensekey")

I can only get an api log when it succeeds. I have tried running as admin, using the same default browser, setting TLS 1.2, different publishing settings. Does the fact that it works from a 2012 server rule out publishing issues such as .NET dependencies or .dll dependencies (I tried setting the Application Files to 'include' for publishing)? Would this be a browser security issue on individual instances? How can I isolate why it is failing or succeeding?

It doesn't absolutely rule it out, but it does greatly diminish the likelihood.

First off, is this .NET Core (5, 6, 7) or Framework? When you deployed to the server, what are you doing? Normally, the Bin folder will have the dll dependencies for the project, so if those have been moved over during the deploy, that should be fine. There can be some quirks in some cases, though, such as if you are using Framework and are missing just the right thing, but that shouldn't apply on Win10/11, as I believe they come with the latest framework automatically installed.

What does failure look like? I would expect some kind of exception at the very least, and that might be telling.

Pretty sure it is .NET Framework. this is not cross platform, just a windows form application developed with Visual Studio. When I publish, the server and the unc path location are the same in the wizard, \\server\folder\folder\folder. the files were all going to the Debug directory, or if i change the Debug to Release in the solution configuration box, it will create a Release folder. The BIN folder is empty when I deploy so I guess my question would be, in a BIN folder, what are the dependencies supposed to look like? The error itself is vanilla. It just says there was an error with the request as best as I can tell. I tried to capture the error, but I get more info when it succeeds than when it fails....and it does not fail on my developing PC, so I have used code such as (String.Format("Error:{0}", ex.Message)) to try to get a more detailed error, but it is not very detailed.

Attachment 187950

There's a bug in the forum software such that you can't add a picture in the quick reply. You have to Go Advanced and add it that way. Otherwise, nobody can see it.

ok. for what it's worth, I added it in. I have a call with a developer today, so hopefully a resolution. will update accordingly. tx

halts as in it freezes with no exception? Not a lot to go on here.

Yeah, I agree with vbdotnut. This can be one of the most vexxing issues when it comes to calling APIs. In theory, a well formed API COULD reply with a meaningful error message if it were on the server side, and some do. Not all. There's also a tendency to return a reasonable response code, while leaving the cause totally vague, which is less than helpful. This one seems a bit like a black box, as it appears to be wrapped away out of sight in a library. They may be either quietly consuming an error, or turning it from something useful into something generic.

So, do you get to debug on the machines where it doesn't work? For example, can you set a breakpoint before the line you pointed out, then step through that line? If so, there might be something usefully accomplished by doing so, but I'm hesitant to go further, because it sounds like you have said that specific deployments failed, in which case you may have no good means to debug. If that's the case, how painful would it be to create a special version with some extra logging, and deploy that to one of the problem machines?

What I'd be curious about is whether or not it just stops on that line and doesn't continue, whether it actually proceeds to the next line (and if so, is 'client' any good?) and fails a bit later, and whether or not some unhandled exception might be getting thrown and caught at some MUCH higher level?

If you can please provide the entire method handling the API call, also I am guessing that 'AvaTaxClient' is a class the API provider has supplied? If you could show that definition as well we could be well on our way to resolving your issue.

It did just "stop" on that line. The issue was as I suspected a few weeks ago, the tls protocol. after "forcing" tls security in the code, this app became successful across the board for my pcs and vmware clients. I had been trying to enforce tls communication using settings on browsers and registry keys on a particular PC to no avail, which is frustrating, but I suspect given the "vexxing" comment surrounding API calls that Shaggy made, and my limited experience using them, frustration is to be expected. The following line of code fixed my problem. thanks for everyone's input.

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12

Im glad you resolved it. Be glad youre not dealing with NetSuite SOAP API with TBA