Invalid option set name => Add namingservice

[JannyM85]

Fix #349
When generate optionSets earlyboundtypes from CRM then you have problem with EarlyBoundTypes-Optonset name for example :

[System.Runtime.Serialization.DataContractAttribute()] [System.CodeDom.Compiler.GeneratedCodeAttribute("CrmSvcUtil", "9.0.0.9154")]
public enum account_preferredcontactmethodcode
{

[System.Runtime.Serialization.EnumMemberAttribute()]
UnknownLabel1 = 1,

[System.Runtime.Serialization.EnumMemberAttribute()]
UnknownLabel2 = 2,

[System.Runtime.Serialization.EnumMemberAttribute()]
UnknownLabel3 = 3,

[System.Runtime.Serialization.EnumMemberAttribute()]
UnknownLabel4 = 4,

[System.Runtime.Serialization.EnumMemberAttribute()]
UnknownLabel5 = 5,
}

[scottdurow]

Currently, the name of the optionset value is output using FilteringService.GenerateOptionSet - It uses the UserLocalizedLabel which should be populated with the language value for the user authenticated.
Trying to workout how the enum member is output as UnknownLabel
Could you help me reproduce your issue

[JannyM85]

Hi I tested the code and it works fine. But there is so many iformation in console output. I dont know why. But when i remove /namingservice:""spkl.CrmSvcUtilExtensions.NamingService,spkl.CrmSvcUtilExtensions"" from argument it is OK. I have no idea why there is the problem. Can you help me with it?

[JannyM85]

Currently, the name of the optionset value is output using FilteringService.GenerateOptionSet - It uses the UserLocalizedLabel which should be populated with the language value for the user authenticated.
Trying to workout how the enum member is output as UnknownLabel
Could you help me reproduce your issue

We have online environment and there is only czech language. I hope if you create new environment with this language and run early bound, you will be have the same problem.

[scottdurow]

Ok - I'll try and create a new envrionment with a new base language that's not 1033. Thanks

BTW - I deleted the screenshot above because it had your username/password in it!
The latest version of spkl uses OAuth On Behalf of Flow so you shouldn't need to store passwords.

[JannyM85]

Oo, thanks a lot. I do more then one thing in current time :(. I see where is the difference in my and you code. In your code you use optionMetadata.Label.UserLocalizedLabel and I use optionMetadata.Label.LocalizedLabels. I thing you can ignore my pullrequest and you can change your service. My idea was use the command line argumetn lngCode and the user can set which language will be use for generation. But I don't know it si possible in you solution.

[scottdurow]

Interesting - I've tried on an org that only has a single non-1033 language - and some optionsets don't have any translations so they don't even have a single optionset label. This currently causes the code to fail. Most of them come through ok though. Do you get UnknownLabel1 for all of your optionsets - or just this one?
Also - which version of spkl and core tools are you using?

[JannyM85]

Hi, ve have all optionsets with UnknowLabel. We use 1.0.370 version.

[scottdurow]

@JannyM85 would you be able to DM me some credentials I can use to reproduce this against an org? I can't repro using any of my environments that have non-1033 as base language.

[JannyM85]

I can try create new organization in my onprem enviroments.

[scottdurow]

Ok - it seems to be a bug with CrmSvcUtil where there isn't the 1033 language pack enabled - I've added logic to force a dummy 1033 label - even though it won't use it (it'll use the language of the user). Can you give it a go with: 6f0eed7