Skip to content

EBG ‐ Version 2.2023.4.3 Upgrade To PAC ModelBuilder

Daryl LaBar edited this page Nov 28, 2023 · 1 revision

This is the largest single change ever made in the history of the Early Bound Generator (EBG). This page will call out the key differences, as well as things to consider when making this upgrade. For simplicity, on this page, EBG-v1 will refer to any Early Bound Generator version pervious to 2.2023.3.12, which was dependent on the CrmSvcUtil.exe, and EBG-v2 will refer to any Early Bound Generator version 2.2023.3.12 or newer, which is dependent on the PAC Model Builder. Also the XrmToolBox will be abbreviated XTB.

Differences

  1. Single Generation (The individual buttons are now gone)
    1. EBG-v1 required shelling out to the command line for each type of class to be generated (so 3 times if generating Actions, Entities, OptionSets). EBG-v2 only allows a single call, and therefore the individual buttons have gone away.
  2. Use of ProcessModelInvoker
    1. EBG-v2 makes use of the Microsoft.PowerPlatform.Dataverse.ModelBuilderLib.ProcessModelInvoker to invoke the generation of files. This accepts an IOrganizationService which means that if the XTB can connect to the organization, the code generation will work. EBG-v2 had to attempt to recreate the command line parameters and was not very good with some of the more unusual authentication strings ( like MFA), and would pop open a box for credentials if it failed to generate a valid connection string. This will no longer be an issue.
  3. Command Line
    1. EBGv1 was always designed to allow users to run via the XrmToolBox or via a command line. This was accomplished by attempting to generate the required command line that utilized the CrmSvcUtil.exe, and adding it to the generated file output. This command line was different depending on what items were being generated, and settings were written to the CrmSvcUtil.exe to be able to control how the code was generated.
    2. EBGv2 follows the same pattern, only using the PAC CLI. This involves a much simpler command line (PAC modelbuilder build --outdirectory {DirectoryPath} --settingsTemplateFile {builderSettings.json path}) and all the EBGv2 settings are written to the same builderSettings.json file. Users will need to first Auth to their org before running the command. Users will also need to include the DLaB.ModelBuilderExtensions.dll, DLaB.Dictionary.txt and alphabets folder in their latest PAC directory (C:\Users%UserName%\AppData\Local\Microsoft\PowerAppsCli\Microsoft.PowerApps.CLI.X.X.X\tools)
  4. Generation Differences
    1. Local Options Sets - The PAC ModelBuilder generates local option sets in the same files as the entity class, but the CrmSvcUtil created these option sets in separate files. The setting "4 - Option Sets - Cleanup CrmSvcUtil Local Option Sets" was created to look for these files and delete them from the disk. After the upgrade, this should be disabled. It is recommended to enable "1 - Global - Add New Files To Project" as well to cleanup the files from the project.
    2. Split of Files - The PAC ModelBuilder splits files by default, and provides no OOB method for generating the actions.cs, optionsets.cs and entities.cs files that we are used to.
    3. Extra Files - The PAC ModelBuilder will also generate the DataContext file and the EntityOptionSetEnum class as seperate files in the output directory.
    4. Messages - The PAC ModelBuilder combines Request and Response classes into a single file.
    5. Suppress INotify Pattern - The PAC ModelBuilder provides an option to remove this pattern. It should result in faster attribute access and smaller code files if the INotifyPattern isn't needed.
  5. Actions are now Messages
    1. Microsoft switched to using "Message" rather than "Action", so it would be applicable to both custom actions, and APIs. EBG-v2 has adopted this as well and has updated references from "Action" to "Message".
  6. CrmSvcUtil.exe.config replaced by builderSettings.json - EBG-v1 would populate the CrmSvcUtil.exe.config file in the XTB\Plugins\EarlyBoundGenerator folder and then shell out to the CrmSvcUtil in order to generate the entities. This worked but was kind of a hack since the CrmSvcUtil.exe assumed all parameters were inputted via the command line. Microsoft instead allows for the specification of a json file that is used to define the settings to be used. The EBG-v2 maps its settings to the MS properties in this file, as well as it's own custom properties in the "dLaB.ModelBuilder" property. It is recommended to check this file into source control if there is a desire to generate the entities via the PAC command line. Being JSON it may be easier to see changes in configuration of settings used to generate the classes than in the DLaB.EarlyBoundGenerator.Settings.xml file, and is another valid reason to check the file into source control, but again, there is no requirement to since it will be regenerated by the EBG-v2.

Items To Consider

  1. Running via Command Line
    1. Although the XrmToolBox works with both on-prem and on-line Dataverse, the PAC CLI only works with on-online. This means if you are on prem and need to generate the entities via command line (like in a build pipeline) you will either have to stay on the EBGv1 or you will have to use the EarlyBoundGenerator.API nuget package to create your own exe that creates an IOrganizationService and calls the ProcessModelInvoker.
  2. Add New Files to Project
    1. It is recommended that the setting "1 - Global - Add New Files to Project" is enabled to simplify the transition from EBGv1 to EBGv2
  3. Suppress INotify Pattern
    1. It is recommended that the setting "2 - Entities Generate INotify Pattern" is enabled if notification of attributes changing is not needed. It should result in faster attribute access and smaller code files if the INotifyPattern isn't needed.
  4. Removed Features
    1. Microsoft.Xrm.Client - Microsoft.Xrm.Client has not been maintained since 2017 and is not included with the PAC Model Builder. As such, this will not be supported.
    2. Unmapped Properties - At one point there was a need to not create enums for particular option sets. This is no longer needed and has been removed.