TALXIS.DevKit.Build.Dataverse.Solution 1.11.1

TALXIS.DevKit.Build.Dataverse.Solution

MSBuild integration for building complete Dataverse solutions. Orchestrates the entire solution build pipeline: discovers and builds referenced Plugin, WorkflowActivity, ScriptLibrary, CodeApp, and PCF projects; patches solution XML with version, publisher, and managed state; supports manual invocation of schema validation targets for solution metadata against XSD/JSON schemas; runs the shared tasks package's SolutionPackagerLib-based packager to produce a .zip file; and supports dotnet pack to generate a NuGet package containing the solution zip.

Installation

<PackageReference Include="TALXIS.DevKit.Build.Dataverse.Solution" Version="0.0.0.1" PrivateAssets="All" />

Or use the SDK approach:

<Project Sdk="TALXIS.DevKit.Build.Sdk/0.0.0.1">
  <PropertyGroup>
    <ProjectType>Solution</ProjectType>
  </PropertyGroup>
</Project>

How It Works

The package sets ProjectType to Solution and imports Microsoft.PowerApps.MSBuild.Solution targets. The build pipeline executes in the following order:

1. Component discovery

ProbePluginLibraries, ProbeScriptLibraries, ProbeCodeApps, and ProbeWorkflowActivityLibraries call GetProjectType on all ProjectReference items to classify them by component type. ScriptLibrary and CodeApp references are removed from @(ProjectReference) after discovery so the standard .NET ResolveProjectReferences pipeline does not build them a second time -- they are built explicitly in the next step.

2. Component builds

BuildPluginLibraries, BuildScriptLibraries, BuildCodeApps, and BuildWorkflowActivityLibraries compile each referenced component project before CopyCdsSolutionContent.

3. Component metadata generation

• Plugin assemblies -- EnsurePluginAssemblyDataXml generates .data.xml files under PluginAssemblies/.
• Plugin steps -- EnsureSdkMessageProcessingStepXml (right after EnsurePluginAssemblyDataXml) writes SdkMessageProcessingSteps/{id}.xml and Type 92 root components into the solution source from [PluginStep] / [PluginStepImage] attributes on plugin classes, so the steps are committed like the assembly .data.xml. It reads the attributes from the built assembly's metadata by name and takes the plugin type ids from the committed PluginAssemblies/*.data.xml, which is why GeneratePluginAssembly must stay enabled. Files are only rewritten when their content changes.
  • Step identity. A step id is derived from assembly, plugin type, message, primary entity and stage, and an image id from its step, image type and alias. Changing any of those is a different step; renaming a type or moving it to another namespace too. Other settings (Name, Rank, Mode, FilteringAttributes, ...) update the same step in place.
  • Removal. A generated step is deleted together with its attribute. A file counts as generated only when its id equals the id recomputed from its own content, so hand-written steps (random ids) are never touched.
  • Adopting an existing step. Set Id on the attribute (and on its images) to the existing step's id. The step file is then rewritten from the attribute and named {id}.xml; anything the attribute can't express is dropped. Without Id, a hand-written step for the same plugin type, message, entity and stage produces a warning, because both would run.
  • Validation. The build fails on invalid registrations (pre-image on Create, post-image outside PostOperation, asynchronous step outside PostOperation, ambiguous image binding, unknown message without MessageId, duplicate ids).
• Workflow activities -- EnsureWorkflowActivityAssemblyDataXml generates .data.xml for workflow activity assemblies.
• Script libraries -- CopyScriptLibrariesToWebResources resolves web resource names with the publisher prefix, generates .data.xml, and registers root components in Solution.xml.
• Code apps -- PrepareCodeAppsSources generates .meta.xml via GenerateCodeAppMetaXml, adds root components (Type 300) to Solution.xml, and ensures the CanvasApps node exists in Customizations.xml.

4. Solution XML patching

PatchSolutionXml writes Version (use ApplyVersionNumber instead, see below), Managed, PublisherName, and PublisherPrefix into Solution.xml (all optional).

5. Solution packaging override and versioning

ProcessCdsProjectReferencesOutputs replaces the Microsoft default to filter ScriptLibrary, CodeApp, and WorkflowActivity references from solution packaging processing. Then GenerateVersionNumber and ApplyVersionNumber patch the version across all solution metadata.

6. Schema validation (manual)

ValidateSolutionComponentSchema validates all solution XML files against 22 bundled XSD schemas and JSON flows against a JSON schema. Validation runs in batch mode -- all errors are collected before failing the build, with MSBuild-canonical error format for IDE click-through.

7. Solution packaging

PowerAppsPackage invokes the tasks package's SolutionPackagerLib-based packager to produce the output .zip.

8. NuGet packing

dotnet pack produces a .nupkg with the solution .zip under content/solution/.

MSBuild Properties

General

Solution metadata

Paths

GeneratePackageOnPublish (default true) can be set to false in the csproj to skip the NuGet pack after dotnet publish.

SolutionPackager localization is enabled automatically when the solution contains .resx files under Resources (for example Resources/en-US/resources.en-US.resx), so translations are merged into the zip instead of being dropped. Set SkipSolutionLocalization to true to opt out. Setting SolutionPackageEnableLocalization to true still forces it on. Keep the .resx files up to date: a stale default-locale file is merged as is, and an invalid one fails the pack. The .NET SDK also treats .resx files under the project folder as embedded resources by default; if the build fails with a GetAssemblyAttributes error, set EnableDefaultEmbeddedResourceItems to false in the csproj.

Web resources and PCF

Validation

Schema validation via ValidateSolutionComponentSchema is not wired automatically -- invoke it manually (e.g. dotnet build -t:ValidateSolutionComponentSchema). No skip property is needed.

Related Packages

• Depends on: TALXIS.DevKit.Build.Dataverse.Tasks, Microsoft.PowerApps.MSBuild.Solution
• Discovers and builds: Plugin, WorkflowActivity, ScriptLibrary, CodeApp, and Pcf projects via ProjectReference