3

I am rewriting a web app that uses the SalesForce API for .NET 2.0. When I run the app it works using the 2.0 API, so the username and password I'm using must be good (the SoapClient.login method has two parameters).

For the new app, I am using the API for .NET 3.0. In the SalesForce documentation (and all other examples I've seen) the SoapClient.login method in the 3.0 API has three parameters: LoginScopeHeader, username, password. Working in Visual Studio, my code will not compile with the three-parameter login method. Intellisense is indicating I need a fourth parameter: LoginScopeHeader, CallOptions, username, password. So I tried loginClient.login(null, null, username, password). I keep getting the following error:

INVALID_LOGIN: Invalid username, password, security token; or user locked out.

As I mentioned, I believe the username and password to be good, because the app works using the 2.0 API with the same credentials. For the same reason, I must not be locked out. So, I am down to the security token. I've seen example where you have to append the security token to the password to log in, but I do not have to do that using the 2.0 API.

So, I have two questions:

  1. Why is Visual Studio telling me SoapClient.login takes four parameters when every .NET 3.0 example I've seen shows three?
  2. Does the .NET 3.0 API require the security token, even if the 2.0 API does not (in my case)?
1

If you are going to the trouble of rebuilding you Salesforce integration, you should be targeting .NET 4.0 at a minimum. Ideally .NET 4.6 or 4.5.

Why? Salesforce is disabling TLS 1.0 support.

.NET 3.5 and below doesn't have native support for TLS 1.1 or 1.2.

It sounds like you are using a Service Reference to bring the WSDL into .NET. Have a read of Accessing Force.com SOAP Endpoints with .NET and Consuming Force.com SOAP and REST Web Services from .NET Applications.

A Web Reference is also an option here and presents an alternative way of handling the request headers.

With regards to the endpoint, make sure you are using test.salesforce.com or login.salesforce.com as the domain.

  • Thanks for the info. I am targeting .NET 4.5.2 in my app. The .NET 2.0 and 3.0 language is in reference to how SalesForce describes the compatibility of two APIs, here. I figured I might as well use the newer of the two, so yes, I'm bringing in the WSDL via a Service Reference. Your last line hit the nail on the head...my endpoint wasn't pointing to the correct URL. – neizan May 12 '16 at 12:15
  • Also, I am using a the web service API, because that is what was used for this app before. I assume I could accomplish the same using the REST API, but I have no experience with it. Any thoughts on that? Is it easier, IYO, to work with one or the other? Performance considerations? Thanks again. – neizan May 12 '16 at 12:17
  • @neizan Generally speaking the REST and SOAP apis have the same core features. In a few places some functionality will only be available in one or the other. I've historically used the SOAP API and then used the REST API only as needed. I'd say use whichever you are most comfortable working against. With the SOAP API, make sure you are using compression support on the request and the response. Also, with a service reference, be aware of the potential slow first call. – Daniel Ballinger May 12 '16 at 19:36
0

I figured out my issue, and it didn't have anything to do with the four-parameter login method or the security token. My SoapClient.Endpoint was not configured correctly. It is now working using null, null, username, password as arguments. In case someone else has an issue and thinks it might be something with the four-param signature, you might look at the SoapClient configuration.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.