Skip to main content
Version: 2024.1

Package manifest

Package manifest is json file that have to be placed in extensions package, for full package description see Package overview. Manifest contains informations about extensions in package, dependencies and some additional informations.

Simple manifest​

This manifest describes package than contains only one action and is targeting version 2024

{
  "extensions": [
   {
    "guid": "da6f2447-83cc-49b3-85ab-d45d07f3bfec",
    "name": "ExampleAction",
    "description": "Description of ExampleAction",
    "assembly": "YourExtensions",
    "class": "YourExtensions.ExampleAction",
    "type": "CustomAction"
    }
  ],
  "dependencies": [
    "YourExtensions"
  ],
  "version": "24"
}

extensions​

This property is collecion of all extensions that are implementend in package, if some extenion exists in code but is not described here then it wont be deployed in Designer Studio.
Single object in extensions collection have to define properties:

  • guid - identifier unique acros all extensions deployed in BPS
  • name - name displayed in Designer Studio
  • description - description displayed in Designer Studio
  • assembly - name of assembly in which extension is implemented
  • class - class with entire namespace in which extension is implemented
  • type - type of extension. Possible values are: CustomAction, CustomDataSource, FormFieldExtension, CustomBusinessRule, CustomLabelPrint

dependencies​

List of dll that will be copied to zip package when in the BPS Tool "Publish" option is used. More about publishing package here. This list supports * as wildecard and by default assume extension is .dll. If package dont use ane external dlls then this list should contain only main dll with extensions.

version​

This property is filled automatically when in the BPS Tool "Publish" option is used. It prevents a package from being uploaded to BPS in a different version than the one for which the package was prepared. The version is set based on the WEBCON.BPS nuget package.

Additional properties​

serviceDependencies and portalDependencies​

Sometimes you may need to separate the dependencies for Portal and Service, more about how this works in Package overview. This operation can be automated by our VS extension if in manifest are provided correct paths for the dlls. In serviceDependencies and portalDependencies collections you can provide paths for dlls which will be placed in the corresponding folders in the zip package when you publish the package. All path are relative to the project(.csproj file) localization.

{
...
  "dependencies": [
    "YourExtensions"
  ],
  "serviceDependencies":[
    "ServiceReferecnceDll/ServiceDependencies1.dll",
    "ServiceReferecnceDll/ServiceDependencies2.dll"
  ],
  "portalDependencies":[
    "PortalReferecnceDll/PortalDependencies1.dll",
    "PortalReferecnceDll/PortalDependencies2.dll"
  ]
  ...
}

validation​

Possible values:

  • Standard - Used by default when this parameter is not specified, validation works as usual.
  • Skip - By default while uploading package in Designer Studio dll with extensions is loaded to check if classes defined in manifest exists. Designer Studio is written in .NET Framework but in extensions there can be sometimes .NET(Core) dependecies and it is not possible to load them in Designer Studio. If the situation occurs setting the validation parameter to Skip value bypasses the validation of package in Designer Studio and allows you to upload extensions package.
  • Native - Sometimes one of the dependencies can be native and then it is not possible to load them in stadard way(from database). Native dlls have to be loaded directly from disk so if validation is set to Native then instead of database this package dependencies will be saved on disk.
{
  ...
  "version": "24",
  "validation": "Standard"
}

loadOnStart​

Be default extensions dlls and its dependencies are loaded right before first use. But sometimes it may be necessary to ensure that the assembly is available before attempting to load it. If the LoadOnStart parameter is true, dll files content is downloaded from the database and loaded into memory before the extension code runs.

{
  ...
  "version": "24",
  "loadOnStart": true
}