Q:

Connecting to Salesforce in .Net Standard 2.0

The fundamental problem I have is we need to connect to Salesforce under .Net Standard 2.0. This means we cannot use the Web Reference as it uses the System.Web group of classes and they are not in .Net Standard 2.0.
I tried to use a Service Reference but when I click Go I get “The system cannot find the path specified.” (I assume the final step in those instruction is to click go, the article doesn’t say.) And this may not be an usable solution if it also makes use of the System.Web group of classes.
If I create a .Net Standard 2.0 library in VisualStudio, there is no way to create a web reference. And for a service reference the only option is to create an OpenAPI service reference.
We cannot use the Salesforce REST API because that uses an OAuth protocol for the login and our code needs to run on a server, and so no U.I., no browser, no way to login when the program runs. We need to authenticate & authorize using the username, password, & token.
Resources I have looked at (among others) that have not helped:

https://developer.salesforce.com/blogs/developer-relations/2014/09/accessing-force-com-soap-endpoints-net.html
https://developer.salesforce.com/page/Consuming_Force.com_SOAP_and_REST_Web_Services_from_.NET_Applications
https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_quickstart_steps_import_wsdl.htm
How can I do this?

A:

We cannot use the Salesforce REST API because that uses an OAuth protocol for the login and our code needs to run on a server, and so no U.I., no browser, no way to login when the program runs. We need to authenticate & authorize using the username, password, & token.

This is not accurate. You're not as limited as you think here. 
On the one hand, the REST API does not require OAuth. You can perform a SOAP login and then use the session Id you get back to communicate with the REST API. This is the strategy used in, for example, the simple_salesforce Python library. Once you get that session Id, you just use it in an Authorization: Bearer <session Id> header. That's documented here, in the section titled "Session ID Authorization"
On the other hand, you are not prohibited from using OAuth because you are running on a headless server. You can execute a flow that produces a refresh token, such as the Web Server flow, in a non-headless environment and persist the refresh token on your server, which can then exchange it for access tokens. Alternately, you can use the JWT flow with a Connected App and certificate as your credential for 100% headless operation end-to-end.

