Live publish for 05 April 2024.

Author: bishalgoswami

powerapps-docs/developer/data-platform/build-and-package.md

@@ -1,59 +1,60 @@
 ---
 title: Build and package plug-in code
-description: Learn about building plug-in code into assemblies and packages for later registration and upload to the Microsoft Dataverse service.
-ms.date: 03/18/2024
-ms.reviewer: pehecke
-ms.topic: article
+description: Learn about building and packaging plug-in code for Microsoft Dataverse, including assembly constraints and dependent assembly limitations.
+ms.date: 04/04/2024
+ms.topic: conceptual
 author: divkamath
-ms.subservice: dataverse-developer
 ms.author: dikamath
-search.audienceType: 
+ms.reviewer: pehecke
+ms.subservice: dataverse-developer
+search.audienceType:
   - developer
 contributors:
   - phecke
   - JimDaly
+ms.custom:
+  - ai-gen-docs-bap
+  - ai-gen-desc
+  - ai-seo-date:11/16/2023
+  - bap-template
 ---
 
 # Build and package plug-in code
 
-This article describes what you need to know about configuring and building an assembly for your plug-in project. We'll also discuss how to create a plug-in package that can contain your plug-in assembly plus any other require dependent assemblies your plug-in needs at run-time.
+This article describes constraints and limitations you need to know about when you're configuring and building an assembly for your Microsoft Dataverse plug-in.
 
-## Building the plug-in assembly
+## Plug-in assembly constraints
 
-When building a plug-in project, keep the following output assembly constraints in mind.
+When you build a plug-in project, keep the following output assembly constraints in mind.
 
 ### Use .NET Framework 4.6.2
 
-Plug-in and custom workflow activity assembly projects must target .NET Framework 4.6.2. While assemblies built using later versions of the .NET Framework should generally work, if the plug-in code uses any features introduced after 4.6.2, a run-time error will occur.
-
-### Optimize assembly development
+Plug-in and custom workflow activity assembly projects must target .NET Framework 4.6.2. Assemblies that are built using later versions of the .NET Framework should generally work. However, if the plug-in code uses any features introduced after 4.6.2, a runtime error occurs.
 
-Your assembly may include multiple plug-in classes (or types) and even custom workflow activities, but can be no larger than 16 MB in size. It's recommended to consolidate plug-ins and workflow assemblies into a single assembly as long as the size remains below 16 MB.
+### Limit assemblies to 16 MB
 
-### Signed assemblies are required
+Your assembly can include multiple plug-in classes or types and even custom workflow activities, but it can't be larger than 16 MB. As a best practice, we recommend that you consolidate plug-ins and workflow assemblies into a single assembly, as long as the size remains below 16 MB.
 
-Assemblies must be signed before they can be registered with Dataverse only if you aren't using the [dependent assemblies](#dependent-assemblies) capability. You can use the Visual Studio **Signing** tab in your project's properties or the [Sn.exe (Strong Name Tool)](/dotnet/framework/tools/sn-exe-strong-name-tool) command to sign the assembly.
+### Sign assemblies before registering them
 
-### Dependency on the CoreAssemblies NuGet package
+If you're not using the [dependent assemblies](#dependent-assemblies) capability, assemblies must be signed before you can register them with Dataverse. To sign the assembly, use the Visual Studio **Signing** tab in your project's properties or the [Sn.exe (Strong Name Tool)](/dotnet/framework/tools/sn-exe-strong-name-tool) command
 
-Adding the `Microsoft.CrmSdk.CoreAssemblies` NuGet package to your project includes the required Dataverse assembly references in your project, but it doesn't upload these assemblies along with your plug-in assembly as these assemblies already exist in the server's sandbox run-time where your code executes.
+### NuGet CoreAssemblies are in the sandbox
 
-### Where to go next
-
-If you're interested in learning about or using dependent assemblies, continue reading the next section in this article. If not, proceed to [Register a plug-in](register-plug-in.md).
+If you add the `Microsoft.CrmSdk.CoreAssemblies` [NuGet](https://www.nuget.org) package to your project, the required Dataverse assembly references are also added, but the assemblies themselves aren't uploaded with your plug-in assembly. They already exist in the server's sandbox runtime where your code executes
 
 ## Dependent assemblies
 
-The dependent assembly capability can be used to include other required .NET assemblies or resources (for example, localized strings) with your plug-in assembly in a single [NuGet](https://www.nuget.org) package that is uploaded to the Dataverse server during the registration process.
-
 > [!IMPORTANT]
-> The dependent assembly capability is so important to plug-in development that you should consider using it from the start even if you do not have an immediate need to do so. Adding support for dependent assemblies to your plug-in project is much more difficult later on in the development cycle.
+> The dependent assembly capability is so important to plug-in development that you should consider using it from the start, even if you don't have an immediate need. Adding support for dependent assemblies to your plug-in project is much more difficult later in the development cycle.
 >
-> We do not supported use of ILMerge. This dependent assemblies feature provides a solution we can support with the same functionality as ILMerge and more.
+> We don't support ILMerge. The dependent assemblies capability offers the same functionality as ILMerge and more.
+
+Use the dependent assembly capability to include other required .NET assemblies or resources, like localized strings, with your plug-in assembly in a single [NuGet](https://www.nuget.org) package that's uploaded to the Dataverse server during registration.
 
-This NuGet package file is stored in the [PluginPackage](reference/entities/pluginpackage.md) table. The contents of the NuGet package is stored in file storage rather than the SQL database.
+The NuGet package file is stored in the [`PluginPackage`](reference/entities/pluginpackage.md) table. The contents of the package are stored in file storage rather than in the SQL database.
 
-When you upload your NuGet package, any assemblies containing classes that implement the <xref:Microsoft.Xrm.Sdk.IPlugin> interface are registered in the [PluginAssembly](reference/entities/pluginassembly.md) table and associated with the plug-in package. As you develop and maintain your project, you continue to update the `PluginPackage` table row and changes to the related plug-in assemblies are managed on the server.
+When you upload your NuGet package, any assemblies that contain classes that implement the <xref:Microsoft.Xrm.Sdk.IPlugin> interface are registered in the [`PluginAssembly`](reference/entities/pluginassembly.md) table and associated with the plug-in package. As you develop and maintain your project, you continue to update the `PluginPackage` table row and changes to the related plug-in assemblies are managed on the server.
 
 At runtime, Dataverse copies the contents of the NuGet package from the `PluginPackage` row and extracts it to the sandbox runtime. This way, any dependent assemblies needed for the plug-in are available.
 
@@ -64,27 +65,26 @@ At runtime, Dataverse copies the contents of the NuGet package from the `PluginP
 
 You aren't required to sign plug-in assemblies used in plug-in packages.
 
-When you register individual plug-in assemblies without the dependent assemblies capability, signing is required because it provides a unique name for the assembly. But with plug-in assemblies within a plug-in package, the assemblies are loaded on the sandbox server using a different mechanism, so signing isn't necessary.
+When you register individual plug-in assemblies without the dependent assemblies capability, signing is required because it provides a unique name for the assembly. But with plug-in assemblies in a plug-in package, the assemblies are loaded on the sandbox server using a different mechanism, so signing isn't necessary.
 
 > [!IMPORTANT]
-> If you sign your assemblies, be aware that signed assemblies cannot use resources contained in unsigned assemblies. If you sign your plug-in assemblies or any dependent assembly, all the assemblies that those assemblies depend on must be signed.
+> If you sign your assemblies, be aware that signed assemblies can't use resources that are contained in unsigned assemblies. If you sign your plug-in assemblies or any dependent assembly, all the assemblies that those assemblies depend on must be signed.
 >
-> If any signed assemblies depend on unsigned assemblies, you will get an error similar to the following: Could not load file or assembly \<AssemblyName>, Version=\<Version>, Culture=neutral, PublicKeyToken=null or one of its dependencies. A strongly-named assembly is required.
+> If any signed assemblies depend on unsigned assemblies, you get an error like this: "Could not load file or assembly *AssemblyName*, Version=*Version*, Culture=neutral, PublicKeyToken=null or one of its dependencies. A strongly-named assembly is required."
 
 ### Dependent assemblies limitations
 
-The following limitations apply when using plug-in dependent assemblies.
+The following limitations apply when you use plug-in dependent assemblies:
 
-- [Workflow extensions](workflow/workflow-extensions.md), also known as *custom workflow activities* aren't supported when using the dependent assemblies capability.
+- [Workflow extensions](workflow/workflow-extensions.md), also known as *custom workflow activities*, aren't supported.
 - On-premises environments aren't supported.
-- Un-managed code isn't supported. You can't include references to un-managed resources.
+- Unmanaged code isn't supported. You can't include references to unmanaged resources.
 
-## Creating a plug-in package
+## Create a plug-in package
 
-Your plug-in assembly plus any required dependent assemblies can be placed together in a NuGet package and then registered and uploaded to the Dataverse server. You don't need to create a package if your plug-in project doesn't require any dependent assemblies at run-time, other than what ships in the Microsoft.CrmSdk.CoreAssemblies NuGet package.
+You can place your plug-in assembly and any dependent assemblies together in a NuGet package, and then register and upload the package to the Dataverse server. If your plug-in project doesn't require any dependent assemblies at runtime other than what ships in the `Microsoft.CrmSdk.CoreAssemblies` NuGet package, you don't need to create a package.
 
-<!-- Add correct links when available -->
-Instructions for creating a plug-in package using an interactive tool can be found in these separate how-to's: [Create and register a plug-in package using PAC CLI](/power-platform/developer/howto/cli-create-package), [Create and register a plug-in package using Visual Studio](/power-platform/developer/howto/vs-create-package).
+Learn how [create and register a plug-in package using PAC CLI](/power-platform/developer/howto/cli-create-package) and how to [create and register a plug-in package using Visual Studio](/power-platform/developer/howto/vs-create-package).
 
 ## All projects must be in the SDK style
 
@@ -122,10 +122,14 @@ More information: [.NET Project SDKs](/dotnet/core/project-sdk/overview#project-
 
 ### Don't depend on System.Text.Json
 
-Because the Microsoft.CrmSdk.CoreAssemblies NuGet package has a [dependency](https://www.nuget.org/packages/Microsoft.CrmSdk.CoreAssemblies#dependencies-body-tab) on System.Text.Json, you're able to refer to [System.Text.Json](xref:System.Text.Json) types at design time. However, the System.Text.Json.dll file in the sandbox run-time can't be guaranteed to be the same version that you reference in your project. If you need to use `System.Text.Json`, you should use the dependent assembly feature and explicitly include it in your NuGet package.
+Because the `Microsoft.CrmSdk.CoreAssemblies` NuGet package has a [dependency](https://www.nuget.org/packages/Microsoft.CrmSdk.CoreAssemblies#dependencies-body-tab) on [`System.Text.Json`](xref:System.Text.Json), you're able to refer to `System.Text.Json` types at design time. However, the `System.Text.Json.dll` file in the sandbox runtime might not be the same version that you refer to in your project. If you need to use `System.Text.Json`, you should use the dependent assembly capability and explicitly include it in your NuGet package.
+
+## Next step
+
+- [Register a plug-in](register-plug-in.md)
 
 ### See also
 
-[Use plug-ins to extend business processes](plug-ins.md)  
+- [Use plug-ins to extend business processes](plug-ins.md)
 
-[!INCLUDE[footer-include](../../includes/footer-banner.md)]
+[!INCLUDE [footer-include](../../includes/footer-banner.md)]