Using connection string with AD auth fails when running providing username/password

[slahn]

I run the generator with windows authentication, but providing the username/password, not using integrated authentication. The VM use to generate the code is also not part of the windows domain.

Anyway - I get the dreaded 'Organization cannot be null' error. If I force the setting UseConnectionString to be false (through the debugger), everything works.

But for some reason, this config value is overwritten for Active Directory authentication: https://github.com/daryllabar/DLaB.Xrm.XrmToolBoxTools/blob/d57421b155a6fc04b11d5c2e21de72df3c39dbdf/DLaB.EarlyBoundGenerator/EarlyBoundGeneratorPlugin.cs#L295

Is forcing the connection string nessescary if using integrated authentication? In that case, you should maybe check if the username/password are blank?

[daryllabar]

So only use the connection string if a UserName/Password is not provided?

[slahn]

I havn't tested any other situation than mine. We use D365 on premises. When using connection string, I get:

CrmSvcUtil Error: 2 : Exiting program with exit code 2 due to exception : System.ArgumentNullException: Organization cannot be null or empty.
Parameter name: Organization Name
   at Microsoft.Xrm.Tooling.Connector.CrmServiceClient.ConnectToCrmWebService(String crmConnectionString)
   at Microsoft.Crm.Services.Utility.SdkMetadataProviderService.CreateOrganizationServiceEndpoint()
   at Microsoft.Crm.Services.Utility.SdkMetadataProviderService.LoadMetadata()
   at DLaB.CrmSvcUtilExtensions.BaseMetadataProviderService.LoadMetadataInternal()
   at DLaB.CrmSvcUtilExtensions.Entity.MetadataProviderService.LoadMetadataInternal()
   at DLaB.CrmSvcUtilExtensions.BaseMetadataProviderService.LoadMetadata()
   at Microsoft.Crm.Services.Utility.CrmSvcUtil.Run()
   at Microsoft.Crm.Services.Utility.CrmSvcUtil.Main(String[] args)
CrmSvcUtil Error: 2 : ===== DETAIL ======

The error is the same when running on a computer in the domain, and using windows authentication in the toolbox connection.

When using the separate url/username/password, everything works fine.

I don't know if there is a reason to 'force' the connection string for AD auth in any situation, maybe just remove the || Settings.AuthType == AuthenticationProviderType.ActiveDirectory entirely?

[slahn]

Would like to ping this issue. I have to use a custom build of the early bound generator, just to respect the 'UseConnectionString' setting.

I don't see any reason to override that setting flag when the mode is Active Directory. Is there one?

[daryllabar]

I'll look into removing this. I just don't have an AD version of CRM to test with... that's my biggest issue.

[slahn]

I've taken a closer look. On-premise 365works just fine without connection string, so I still don't see a reason to force it. But it works with the connection string as well, as long as you escape the password property. My password contained special characters.

Escape the password like this, and everything works in every situation for me:

//To handle special characters, enclose in single quotes. If password contains single quotes, they must be doubled.
//https://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring.aspx
var password = $"'{earlyBoundGeneratorConfig.Password.Replace("'", "''")}'";