Anyone with experience creating webservice clients with Visual Studio 2019?

Yes. I do this almost daily. What error are you getting?

Also, if the only change is simply the protocol change from HTTP to HTTPS in the URL, then you probably just need to set the Security.Mode in your BasicHttpBinding to BasicHtpSecurityMode.Transport.

So let's say you've created your BasicHttpBinding object and called it _httpbinding and you've done whatever you need to do to it. The line of code to add (or change, if you already set it) would be:

_httpbinding.Security.Mode = BasicHttpSecurityMode.Transport;

"An HTTP Content-Type header is required for SOAP messaging and none was found."}   System.ServiceModel.ProtocolException

My app.config has this for the security mode.

         <basicHttpBinding>
            <binding name="ExternalApiServiceSoapBinding">

               <security mode="Transport">
                  <transport clientCredentialType="Basic" />
                  <message clientCredentialType="UserName" algorithmSuite="Default"/>                  
               </security>
                             
            </binding>
         </basicHttpBinding>

Should I also add the program statement?  Where do I find the "_httpbinding" object?

Hmmm - that's a strange error for just a protocol switch. The generated code should automatically add the content type for you.

Have you captured and reviewed the request being sent out, using Fiddler? 

I have not.  The network folks say that Fiddler requires extensive setup on the server and they were reluctant to do it until I had exhausted my debugging efforts at my end.  Can Fiddler be run on the workstation running the client?  I have the SOAPUI utility and it successfully does the call.  It either does not get the error or it ignores it.

I also thought that the generated code should also add the content type.  Does it do so in response to something in the app.config file?

Typically, I write a lot of plugins, so I don't utilize the app.config file to store the client configuration, but rather I just instantiate the client via code and set all the properties that way.

The specific syntax and class names will vary a bit between endpoints, but typically the idea is:

1. You add a service reference from the WSDL, which auto-generates all the client classes for you.

2. One of those classes is the client class, like ApiServiceReference.ApiClient (or something).

3. You create a new EndpointAddress object with the URL, and a new binding and configure them:
var _endpoint = new EndpointAddress("https://path/to/the/api/endpoint");
var _httpbinding = new BasicHttpBinding();
_httpbinding.Security.Mode = BasicHttpSecurityMode.Transport;

You can further configure the binding with any additional authentication or things like timeouts or custom behaviors. 

4. You create a new instance of the client class and pass in the binding and endpoint:
var myClient = new ApiServiceReference.ApiClient(_httpbinding, _endpoint);

5. You make API calls with myClient.

> The network folks say that Fiddler requires extensive setup on the server 

Umm... that doesn't sound right. You don't set up Fiddler on the server - you run it from the client side.

Fiddler is a man-in-the-middle proxy server. You install it and enable HTTPS decryption on it (which requires you to have admin privileges on your machine so it can install its root certificate). Once it starts capturing, you go run your code and it'll send its HTTP / HTTPS calls through Fiddler, which captures them in a nice little list for you so you can look at the raw request and response data.

I am the only one here that does anything with webservice calls so I typically have to explain everything that I want when I need something from the network folks.  I'll look into Fiddler myself and set what it takes to get it installed on my workstation.

I'll experiment with applying the settings in the code.  It does not look complicated.  I have written other webservice clients in the past but this is my first experience with letting Visual Studio generate the code for me.  I have found very little in the way of examples so I appreciate this advice very much.

With your hints, I found how and where to specify the Security.Mode as Transport and the ClientCredentialType as Basic.  Now am back to the missing Content Type header error.  I'll see if I can figure out where to add a content type header.

Well again, that -should- be being added automatically. You shouldn't need to specify it unless there's something that's interfering with that process somehow. So that's why I was suggesting you should check out the raw outbound request with Fiddler - JUST in case it's an issue with the response, not the request. For example, maybe there's some other issue with the request and so the server is responding with an error but not returning an expected content-type header or something.

Thank you very much for the crash course on Fiddler!  It reminds me of the RS-232 monitor I used to use back when dinosaurs roamed the earth.  Fiddler is up and running, I cleared the sessions, made certain that "capturing" was on then ran my webservice client.  Fiddler did not capture anything.  I am working remotely using a VPN, would that interfere with Fiddler being able to see the traffic?  I could try installing it and my client app on a virtual workstation that is not communicating over the VPN.

that -should- be being added automatically 

That was exactly my thought but I figured I would check with wiser people than I.  I also wondered if the error were in the response and that this third-party host was not handling the security settings well.  The webservice client worked for several months before the network folks decided to tweak the security.  I'll try this on the virtual workstation to eliminate the VPN as a source of problems.

I found the WinConfig and am exempting the Apps.

Fiddler is capturing the request and response on my virtual workstation.  The VPN must have been interfering.  If I am interpreting what I see in the inspector, the request DOES have content type header.  The response does not appear to.  Wonder if I can tell the client to ignore that problem?  I was able to tell it to ignore a bad certificate.

Someone, FootPrints (the host app) or Microsoft, dragged a red herring across my path.  Now that I can see the requests and the responses, I see that the cause of the problem appears to be an authentication problem.  I corrected the user ID and the password and the call was successful.  Thank you very much for your help!  I'll see if I can keep going with this.

Great!