A plug-in needs a third-party JSON library and an internal helper assembly at runtime, neither of which is present in the Dataverse sandbox. The team previously used ILMerge to combine them, but wants the supported approach. What should the developer do?
Select an answer to reveal the explanation.
Short Explanation
A plug-in package is a moving box: your plug-in and everything it needs travel together, and Dataverse unpacks the whole box in the sandbox. ILMerge used to be the duct-tape fix, but Microsoft doesn't support it. Pack the box properly instead.
Full Explanation
The dependent assemblies capability lets a developer place a plug-in assembly and the assemblies it depends on into a single NuGet package, which is uploaded and stored in the PluginPackage table. At runtime Dataverse extracts the package into the sandbox so the dependencies are available, and plug-in types in the package are registered automatically. The package can be created with the Power Platform CLI or Visual Studio and registered with the Plug-in Registration Tool, and projects in it must use the SDK-style format. Registering dependent libraries as separate plug-in assemblies does not make them loadable as dependencies; plug-in assembly registration is for assemblies containing plug-in types, and the sandbox does not resolve references across separately registered assemblies. Microsoft does not support ILMerge for plug-ins, and the dependent assemblies capability is described as providing the same functionality and more. Loading assemblies from a web resource with Assembly.Load is not a supported pattern; the sandbox restricts dynamic loading, and web resources are for client-side content. Exam caveat: dependent assemblies are not supported for custom workflow activities, on-premises deployments or unmanaged code. Operational check: build the package, register it, confirm the plug-in types appear under the package in the tool, and trigger a step that uses the JSON library.