Skip to content

10 Generate Early Bound Types

Jump to bottom
Remy van Duijkeren edited this page Aug 22, 2026 · 2 revisions

Generate Early Bound types

flowline generate produces early-bound C# types for your solution's entities, option sets, and Custom APIs, and puts them in Plugins/Models/ ready to use in your plugin code.

Under the hood it calls pac modelbuilder build, but with automatic entity and Custom API discovery so you don't have to maintain a manual filter list.

When to run

  • After clone or init, to get types before writing any plugin code
  • When entities or Custom APIs change in Dataverse and you want updated classes
  • On a new dev machine after cloning the repo

Usage

flowline generate                 # reads solution from .flowline
flowline generate ContosoSales    # optional — must match the configured solution's UniqueName (case-insensitive), errors on mismatch

What gets generated

Output lands in Plugins/Models/:

Models/
├── Entities/              # one .cs file per entity (account.cs, contact.cs, …)
├── Messages/              # one .cs file per Custom API
├── OptionSets/            # option set enumerations
└── EntityOptionSetEnum.cs # OptionSet helper
└── XrmContext.cs          # OrganizationServiceContext for LINQ queries

Flowline queries Dataverse to discover which entities and Custom APIs belong to your solution, then passes that list to pac modelbuilder build as the entity and message filter. You get only what your solution contains, without noise from unrelated tables.

Note: Models/ is overwritten on each run. If you have uncommitted changes there, Flowline warns before proceeding. Commit or discard them first.

Separate models project

Keeping models in the plugin project is the simplest setup and what Flowline defaults to. If you prefer a dedicated models project, common in larger solutions, pass --output once. It is saved to .flowline and used automatically on every later run:

flowline generate --output ../ContosoSales.Models/Models

Namespace

On the first run, Flowline derives the namespace from your .csproj assembly name and saves it to .flowline. Later runs reuse the saved value, so no flag is needed.

To override:

flowline generate --namespace Contoso.Plugins.Models

The new namespace is saved to .flowline and used for all future runs.

Including extra tables

Your plugins often reference standard tables (account, contact) that are not part of your solution. Add them with --extra-tables:

flowline generate --extra-tables account,contact,systemuser

The list is saved to .flowline and merged with your solution's own entities on every run. Passing --extra-tables again replaces the saved list.

Standalone (outside a Flowline project)

generate works without a .flowline project file. All inputs must be provided explicitly (see 02-Project-Configuration#project-mode-and-standalone-mode):

flowline generate ContosoSales --dev https://contoso.crm4.dynamics.com -o ./Models

The namespace defaults to ContosoSales.Models. Use --namespace to override. Settings are not saved in standalone mode.

Generators

Flowline supports multiple generators via --generator. The value is saved to .flowline.

Flag Backing tool Output style Platform
pac (default) pac modelbuilder build Microsoft-style (lowercase filenames, OptionSetValue) Cross-platform
xrmcontext XrmContext v4 dotnet tool Modern C# with typed enums, ServiceContext, PascalCase Cross-platform
xrmcontext3 Delegate.XrmContext v3 F# exe Same quality as xrmcontext but Windows-only Windows only
ebg Early Bound Generator V2 in-process PascalCase, typed enums, ServiceContext, one file per entity Cross-platform 
flowline generate --generator xrmcontext

ebg runs Daryl LaBar's Early Bound Generator inside Flowline. No separate install, and no DLLs to copy into your PAC installation.

flowline generate --generator ebg

Flowline sets the namespace, output folder, service context name and the entity and message filters from what your solution actually contains. To reach EBG's other settings, put a builderSettings.json at your project root. Flowline overwrites only the keys it derives and keeps the rest.

Authentication needs nothing extra: ebg reuses the connection Flowline already opened.

xrmcontext auth: Flowline picks up your PAC auth profile automatically. Personal account profiles open a browser once, then the token is cached for later runs. Service principal profiles require the client secret separately via --client-secret or the AZURE_CLIENT_SECRET env var; Flowline injects the credentials into XrmContext as environment variables.

flowline generate --generator xrmcontext --client-secret <your-secret>

Flowline runs XrmContext without a global install. You can install it globally with dotnet tool install -g XrmContext if you want to run it directly.

xrmcontext3 auth: same PAC auth profile behaviour as xrmcontext, a browser for personal accounts and --client-secret for service principals. Windows only, and no new investment goes into it, so use xrmcontext for new projects.

Required NuGet package: Generated code references System.ComponentModel.DataAnnotations. Add it to your plugin project or it won't compile:

dotnet add Plugins/ContosoSales.Plugins.csproj package System.ComponentModel.Annotations

Use --client-id to override the application ID from the PAC auth profile when needed:

flowline generate --generator xrmcontext --client-id <app-id> --client-secret <secret>

→ Full auth details and CI/CD setup: 03-Authentication

Further reading

Clone this wiki locally