02 Project Configuration

Project configuration

A Flowline project is configured by two files at its root. The .flowline file holds your environment URLs and your solution settings, so you type them once and every command after that reads them back. The solution file (.slnx or .sln) tells Flowline where your projects live.

Flowline writes the file for you. clone and init create it during setup, and provision, sync, and generate add to it as you go. It's plain JSON, so you can also open it in any editor and change it by hand.

Where it lives

.flowline sits in the project root, next to the solution file:

.flowline
ContosoSales.slnx
Solution/
Plugins/
WebResources/

Commands work from any folder inside the project. Flowline walks up from wherever you are until it finds .flowline, and treats that folder as the project root.

Tip

Commit .flowline to Git. Environment URLs and solution settings are the same for everyone on the team, and a fresh clone of the repo is ready to use straight away.

What it looks like

{
  "SchemaVersion": 1,
  "ProdUrl": "https://contoso.crm4.dynamics.com/",
  "UatUrl": null,
  "TestUrl": null,
  "DevUrl": "https://contoso-dev.crm4.dynamics.com/",
  "Solution": {
    "UniqueName": "ContosoSales",
    "IncludeManaged": false,
    "PluginPackageMode": "Auto",
    "Generate": {
      "Namespace": "Contoso.Models",
      "ExtraTables": [
        "account",
        "contact"
      ],
      "Generator": "Pac"
    }
  }
}

SchemaVersion records which config format the file uses. Leave it as Flowline wrote it.

Generate appears after your first flowline generate run, which records the generator it used along with anything you passed a flag for.

Environment URLs

One URL per role. Flowline saves a URL the first time you give it one, then reuses it, so most commands need no environment flag at all.

Key	Environment	Usually set by
ProdUrl	Production	flowline clone --prod <url>
UatUrl	UAT	flowline provision uat
TestUrl	Test	flowline provision test
DevUrl	Development	flowline provision dev, or flowline init --dev <url>

A role you have not set yet stays null. Add one at any time by passing its flag to clone:

flowline clone ContosoSales --uat https://contoso-uat.crm4.dynamics.com

Or let provision create the environment and fill in the URL for you:

flowline provision uat

Pass a flag whose URL is already saved and Flowline asks before replacing it. Add --force config to answer yes up front, which is what a script or a CI job needs.

See 04-Command-Reference#clone and 04-Command-Reference#provision for the full flag lists, and 03-Authentication for signing in to each environment.

Solution settings

Key	What it does	Set by
UniqueName	The solution's unique name in Dataverse	clone or init
IncludeManaged	Export and unpack the managed solution alongside the unmanaged one	clone --managed, sync --managed
PluginPackageMode	How plugins are pushed: Auto, Nupkg, or Dll	Edit by hand

PluginPackageMode defaults to Auto, which picks the NuGet plugin package when your build produces one and the classic .dll otherwise. Set it to Nupkg to always push a package, or to Dll to always push the assembly, which is the option for on-premises environments.

Turn managed export back off by passing --managed false to sync.

Generate settings

These live under Solution.Generate and cover early-bound C# types. Each one is saved the first time you pass its flag, so later runs are a plain flowline generate.

Key	What it does	Set by
Namespace	Namespace for the generated types	generate --namespace <ns>
ExtraTables	Extra tables to include that aren't in the solution	generate --extra-tables account,contact
Generator	Which generator runs: Pac, XrmContext, XrmContext3, or Ebg	generate --generator <name>
ServiceContextName	Name of the generated service context class	generate --service-context-name <name>
OutputPath	Where generated files land, relative to the project root	generate --output <path>

Full guide: 10-Generate-Early-Bound-Types.

The solution file

Next to .flowline sits your solution file, ContosoSales.slnx. Flowline reads it to find the projects it works with:

Project	How Flowline uses it
Solution/ContosoSales.cdsproj	The Dataverse solution project. Its folder holds the unpacked solution source that sync writes and deploy packs.
Plugins/ContosoSales.Plugins.csproj	Built by push, then scanned for [Step] and [CustomApi] classes to register.
WebResources/ContosoSales.WebResources.csproj	Built by push, then its dist/ folder syncs to Dataverse.

Each entry in the solution file gives Flowline the project's name and its path relative to the project root, so the solution file is the answer to "where does everything live". Move a project into src/, rename its folder, or split plugins across several projects: update the solution file in your IDE and every Flowline command follows along. Nothing else needs changing.

A project root holds exactly one .cdsproj, which is the one solution Flowline clones, syncs, and deploys. A second Dataverse solution gets its own Flowline project. Plugin projects and the WebResources project are found among the remaining entries.

Add a .cdsproj to the solution file with flowline sln add, since dotnet sln add refuses that project type:

flowline sln add Solution/ContosoSales.cdsproj

clone and init create a .slnx when the repo has no solution file yet. An existing .sln is used as it is, never converted.

Important

Leave the .cdsproj without project references. Adding a <ProjectReference> from it to your Plugins or WebResources project is a pattern you may have seen elsewhere, but it breaks dotnet build on the .cdsproj. A reference to a Flowline plugin project fails with Unable to find assembly registration configuration, and a reference to the WebResources project fails with MSB4057: The target "GetProjectOutputPath" does not exist. Flowline never needs the reference: push registers plugins and web resources against Dataverse directly, and deploy packs from the solution source that sync wrote. The solution file already declares which projects belong together.

Project mode and standalone mode

The .flowline file is what tells Flowline it's in a project.

Project mode is the normal way to work. Flowline finds .flowline, reads your environment URLs and solution name from it, and locates the Solution, Plugins, and WebResources projects through the solution file. Commands stay short:

flowline push
flowline sync
flowline deploy prod

A .flowline file covers every folder underneath it, so running from a subfolder still puts you in project mode.

Standalone mode runs push, deploy, drift, and generate from a folder outside any Flowline project, with every input passed as a flag:

flowline push ContosoSales --dev https://contoso-dev.crm4.dynamics.com --pluginFile ./bin/Release/Contoso.Plugins.dll
flowline generate ContosoSales --dev https://contoso-dev.crm4.dynamics.com -o ./src/Models

This suits a CI job that only downloaded a build artifact, and it's the way to try Flowline against a repo you haven't set up yet. The migration guides use it to run Flowline alongside your current tool.

See 04-Command-Reference#standalone-push and 04-Command-Reference#standalone-deploy-and-drift for what each command needs.