Updated To use EarlyBoundGenerator.Api.

[daryllabar]

PR for Integrate EarlyBound Generator #378

Removed Previous CrmSvcUtil Utilities.
Mapped all settings of earlyboundtypes except generateStateEnums and GenerateGlobalOptionSets. There are no settings currently for this in the EarlyBoundGenerator, and I can't think of a good reason why you would not want to include these.

Updated EarlyBoundTypeConfig to inherit from DLaB.EarlyBoundGeneator.Settings.POCO.ExtensionConfig. This means all settings in the EarlyBoundGenerator will be allowed (except it they are overriden with the current settings of the EarlyBoundTypeConfig. Also added names for the action, and optionSet.

Updated Tests.

Updated VS. Not sure that matters...

[daryllabar]

There are two breaking change.

1. No longer able to control not generating State/status optionsets and global option sets separately.
2. The casing for the OptionSetEnums are based on the schema, not the logical names. Much more readable, but, a breaking change for where ever it is referenced...

[scottdurow]

Thanks fo this @daryllabar - rather than introduce breaking changes - there needs to be a switch to either use your filtering service - or the existing spkl one to preserve existing projects.

[daryllabar]

Ok, if we are going to have a switch, then would it make sense to have a completely different JSON section for it so there is no mapping required?

And if so, I didn't see anywhere where the JSON config is parsed. If I added an entirely new node to the JSON, would I need to add any code to handle that? Also this would mean JSON properties that are using .net naming conventions, which may make some people's eyes bleed.

And finally, I'm assuming you'd want the default to be the old way?

[daryllabar]

Also question, why do you care about breaking change Num 1? What is the reason you'd not want to generate globals and or state/status enums? If I see a good reason for it, then I may just add it to the EBG.

[scottdurow]

1. We care about breaking changes because it could break people's builds! 😋
2. Can you change the pull request to target the spkl_dev branch
3. Yes - default to the existing filtering service
4. Just add any additional config flags to the existing Earlybound config - along with a switch (e.g. something like useEarlyBoundGeneratorApi)
5. config is loaded using Newtonsoft.Json.JsonConvert.DeserializeObject

   SparkleXrm/spkl/SparkleXrm.Tasks/Config/ConfigFile.cs

   Line 175 in 35b23c2

   var config = Newtonsoft.Json.JsonConvert.DeserializeObject<ConfigFile>(File.ReadAllText(configPath));