Créer et empaqueter le code de plug-in

Cet article décrit les contraintes et limitations que vous devez savoir lors de la création et de l’empaquetage du code plug-in pour Microsoft Dataverse, notamment les contraintes d’assembly, les exigences d’assembly dépendantes et les options d’empaquetage NuGet.

Contraintes de l'assemblage du plug-in

Lorsque vous créez un projet de plug-in, gardez à l’esprit les contraintes suivantes de l’assembly de sortie.

Utiliser .NET Framework 4.6.2

Les projets d’assemblage de plug-in et d’activité de workflow personnalisés doivent cibler .NET Framework 4.6.2.

Limiter les assemblages à 16 Mo

Votre assembly peut inclure plusieurs classes ou types de plug-in et même des activités de workflow personnalisées, mais sa taille ne peut pas dépasser 16 Mo. En guise de meilleure pratique, regroupez les plug-ins et les assemblys de flux de travail dans un seul assembly, tant que la taille reste inférieure à 16 Mo.

Signer les assemblies avant de les enregistrer

Si vous n’utilisez pas la fonctionnalité d'assemblies dépendants, vous devez signer des assemblies avant de les enregistrer dans Dataverse. Pour signer l’assembly, utilisez l’onglet Signature De Visual Studio dans les propriétés de votre projet ou la commande Sn.exe (Outil de nom fort).

Les CoreAssemblies NuGet se trouvent dans le bac à sable

Si vous ajoutez le Microsoft.CrmSdk.CoreAssemblies package NuGet à votre projet, les références d’assembly Dataverse requises sont ajoutées. Toutefois, les assembly eux-mêmes ne sont pas chargés avec votre assembly de plug-in. Ils existent déjà dans le runtime de bac à sable du serveur où votre code s’exécute.

assembly dépendants

Utilisez la fonctionnalité d’assembly dépendant pour inclure d’autres ressources ou assembly .NET requis, tels que des chaînes localisées, avec votre assembly de plug-in dans un seul package NuGet chargé sur le serveur Dataverse lors de l’enregistrement.

Le fichier du package NuGet est stocké dans la table PluginPackage. Le contenu du package est stocké dans le stockage de fichiers plutôt que dans la base de données SQL.

Lorsque vous chargez votre package NuGet, tous les assemblys contenant des classes qui implémentent l’interface IPlugin sont enregistrés dans la table PluginAssembly et associés au package de plug-in. À mesure que vous développez et gérez votre projet, vous continuez à mettre à jour la ligne de table PluginPackage et les modifications des assemblys de plug-in associés sont gérées sur le serveur.

Lors de l’exécution, Dataverse copie le contenu du package NuGet depuis la ligne PluginPackage et l’extrait dans l'environnement d'exécution isolé. De cette façon, toutes les assemblies dépendantes nécessaires pour le module d'extension sont disponibles.

Les assembly signés ne sont pas obligatoires

Vous n’avez pas besoin de signer les assembly de plug-in utilisés dans les packages de plug-in.

Lorsque vous enregistrez des assembly de plug-in individuels sans la capacité d’assembly dépendants, la signature est requise car elle fournit un nom unique pour l’assembly. Toutefois, avec les assembly de plug-in dans un package de plug-in, les assembly sont chargés sur le serveur de bac à sable grâce à un autre mécanisme, rendant ainsi la signature inutile.

Limitations des assemblages dépendants

Les limitations suivantes s’appliquent lorsque vous utilisez des assemblys dépendants d’un plug-in :

• Les extensions de workflow, également appelées activités de workflow personnalisées, ne sont pas prises en charge.
• Les installations sur site ne sont pas prises en charge.
• Le code non géré n’est pas pris en charge. Vous ne pouvez pas inclure de références à des ressources non gérées.

Considérations relatives aux performances lors de l’importation ou de l’inscription d’un package de plug-in

Les packages de plug-in contenant des assemblys avec un grand nombre (centaines à milliers) de classes qui implémentent IPlugin prennent un temps relativement long pour les importer dans Dataverse.

Les temps d’importation de 15 minutes pour un millier de types de plug-ins ont été observés. Cette durée s’applique, que vous importez une solution à l’aide d’un appel d’API ou via l’interface utilisateur web, ou en inscrivant le package à l’aide de l’outil d’inscription de plug-in.

Créer un package de plug-in

Vous pouvez placer votre assembly de plug-in et tous les assemblys dépendants ensemble dans un package NuGet, puis enregistrer et charger le package sur le serveur Dataverse. Si votre projet de plug-in ne nécessite aucun assembly dépendant au moment de l’exécution autre que ceux fournis dans le package NuGet Microsoft.CrmSdk.CoreAssemblies, il n’est pas nécessaire de créer un package.

Découvrez comment créer et inscrire un package de plug-in à l’aide de l’interface CLI PAC et comment créer et inscrire un package de plug-in à l’aide de Visual Studio.

Tous les projets doivent utiliser le style du Kit de développement logiciel (SDK)

Un package de plug-in ne peut contenir que des assemblys personnalisés générés à partir d’un fichier projet dans un format spécifique appelé style sdk. Si vous ne suivez pas cette règle, vous obtenez une erreur (« fichier introuvable ») lorsque vous essayez d’inscrire le package à l’aide de l’outil d’inscription de plug-in.

Un projet de style SDK est un projet dans lequel le contenu du fichier .csproj du projet contient la ligne de code suivante : <Project Sdk="Microsoft.NET.Sdk">.

Lorsque vous créez un projet de plug-in à l’aide de l’un des outils, comme la commande CLI pac plugin init Power Platform, le fichier projet plug-in est au format correct. Voici un exemple de ce fichier de projet.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
    <PowerAppsTargetsPath>$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\PowerApps</PowerAppsTargetsPath>
    <AssemblyVersion>1.0.0.0</AssemblyVersion>
    <FileVersion>1.0.0.0</FileVersion>
    <ProjectTypeGuids>{4C25E9B5-9FA6-436c-8E19-B395D2A65FAF};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
  </PropertyGroup>
  ...
</Project>

Si vous ajoutez un autre projet à la solution Visual Studio, comme un projet de bibliothèque de classes, créez un projet de style SDK en procédant comme suit :

1. Dans Visual Studio, ajoutez le nouveau projet à votre solution à l’aide d’un modèle .NET ou .NET Standard. Ne ciblez pas .NET Framework.
2. Modifiez le fichier projet en cliquant avec le bouton droit sur le nom du projet dans l’Explorateur de solutions et en sélectionnant Modifier le fichier projet, ou ouvrez le fichier .csproj du projet dans un éditeur distinct.
3. Vous devriez voir la ligne <Project Sdk="Microsoft.NET.Sdk"> dans le fichier du projet. Modifiez la propriété TargetFramework en <TargetFramework>net462</TargetFramework> et enregistrez le fichier.
4. Vérifiez que votre solution est générée et vous avez terminé.

Pour plus d’informations, consultez le SDK du projet .NET.

Ne dépendez pas de System.Text.Json

Étant donné que le Microsoft.CrmSdk.CoreAssemblies package NuGet a une dépendance sur System.Text.Json, vous pouvez faire référence aux System.Text.Json types au moment du design. Cependant, le fichier System.Text.Json.dll dans le runtime du bac à sable peut ne pas être la même version que celle à laquelle vous faites référence dans votre projet. Si vous devez utiliser System.Text.Json, utilisez la fonctionnalité d’assembly dépendante et incluez-la explicitement dans votre package NuGet.

Étape suivante

• Enregistrer un plug-in

Voir aussi

• Utiliser des plug-ins pour étendre les processus d’entreprise