Skip to content

09 Generate Early Bound Types

Jump to bottom
RemyDuijkeren edited this page Jul 17, 2026 · 5 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, 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. Only what your solution contains is generated — no 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 subsequent 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. Subsequent runs reuse the saved value — no flag 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:

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# — typed enums, ServiceContext, PascalCase Cross-platform
xrmcontext3 Delegate.XrmContext v3 F# exe Same quality as xrmcontext but Windows-only Windows only 
flowline generate --generator xrmcontext

xrmcontext auth: Flowline picks up your PAC profile automatically. Personal account profiles open a browser once — the token is cached for subsequent 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 profile behaviour as xrmcontext — browser for personal accounts, --client-secret for service principals. Windows only. No new investment — 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/Plugins.csproj package System.ComponentModel.Annotations

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

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

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

Further reading

Clone this wiki locally