Building Activity Packages

Given that UiPath's platform is built on the .NET framework, all activities take the form of a Nuget package (this is the .nupkg file you get when downloading an activity directly from Go! to Marketplace or from the feeds in UiPath Studio's package manager). There are 4 types of files required to bundle your files into a single Nuget package:

AssemblyInfo Files

Whenever you build a project within Visual Studio, the Microsoft Build Engine (aka MSBuild) transforms that project's code into a DLL, a library that can be used by other Windows applications. The metadata for this library comes from three AssemblyInfo files stored within the Properties section of your project and which supply information for different levels of an activity set. Let's take a look at each one:

1. AssemblyInfo.cs

[assembly: AssemblyTitle("MyCompany.MyProduct.Activities")]
[assembly: AssemblyDescription("This activity was made using the UiPath Activity Set extension.")]
[assembly: ComVisible(false)]
[assembly: Guid("133E5191-68DA-4F05-9A81-D5CFA16525C8")]

AssemblyInfo.cs contains the metadata unique to this particular project (e.g. MyCompany.MyProduct).

• AssemblyTitle gives a friendly name to your DLL. For simplicity, this should match the name of the project.

• AssemblyDescription is a short summary of the nature and purpose of the assembly.

  There are several other attributes, such as culture or version number, that may be included. For a full list, see Microsoft's official documentation.

• ComVisible and Guid are default attributes used by applications referencing this project's eventual library. They remain untouched for most activities, but you can read more about their effects here.

2. MyCompany.MyProductAssemblyInfo.cs

#if DEBUG
[assembly: AssemblyVersion("1.0.*")]
#else
[assembly: AssemblyVersion("1.0.0")]
#endif

The next Assembly file, <your activity name>AssemblyInfo.cs, contains the metadata that is unique to the activity set as a whole but is shared between all the projects; in this case, only the activity version. Notice that the version differs for each Visual Studio configuration:

• Debug: If Visual Studio is in debug mode, the activity is built with a version number 1.0.*, meaning the major and minor versions are set (1.0) and the patch version increments on each build. This is useful when making frequent changes to the same code as each subsequent package will be built with a new version, making it easily distinguishable.

• Release: If Visual Studio is in release mode, the version number is set (e.g. 1.0.0). This provides complete control when it's time to officially release a package.

  
  

  

  
  

3. GlobalAssemblyInfo.cs

[assembly: AssemblyCompany("MyCompany")]
[assembly: AssemblyProduct("Product A")]
[assembly: AssemblyCopyright("MyCompany © 2019")]
[assembly: AssemblyTrademark("MyCompany™")]
[assembly: AssemblyCulture("en-CA")]
[assembly: NeutralResourcesLanguage("en-US")]

GlobalAssemblyInfo.cs contains the metadata shared between all the activity sets you produce. The UiPath.GSuite.Activities and UiPath.MicrosoftOffice365.Activities packages, for example, were created by the same Company (UiPath), target the same Product (UiPath Studio) and have the same Copyright, Trademark, and language information, so they used the same GlobalAssemblyInfo.cs file to avoid unnecessary duplication.

Nuspec

Once all of your projects are compiled into DLLs, these libraries are bundled into a Nuget package that can be used in UiPath Studio. The metadata for this package comes from the nuspec file within your Design project.

You can see the complete list of metadata elements available via the nuspec here, but take a look at the basic example below first. These elements correspond to fields displayed in UiPath Studio's package manager and allow users to find and distinguish your activity set.

Note that some of the elements, such as id and version, contain tags in the form $element$. These are taking their values from the corresponding tags in the AssemblyInfo files to prevent duplicating information.

<?xml version="1.0"?>
<package>
  <metadata>
    <id>$title$</id>
    <version>$version$</version>
    <title>$title$</title>
    <authors>$author$</authors>
    <owners>$author$</owners>
    <description>$description$</description>
    <copyright>$copyright$</copyright>
    <requireLicenseAcceptance>true</requireLicenseAcceptance>
    <licenseUrl>https://www.apache.org/licenses/LICENSE-2.0</licenseUrl>
    <projectUrl>https://integrations.uipath.com/docs/integrating-with-uipath</projectUrl>
    <iconUrl>https://raw.githubusercontent.com/NuGet/Samples/master/PackageIconNuspecExample/icon.png</iconUrl>
    <tags>UiPath Activit</tags>
    <dependencies>
    </dependencies>
  </metadata>
  <files>
    <file src="$OutputPath$**\)\)MyCompany.MyProduct*resources.dll" target="lib\)
et461"/>
  </files>
</package>

Note: If you're familiar with Visual Studio, you may know it is actually capable of building Nuget packages on its own using only the AssemblyInfo files and MSBuild. So why use an extra nuspec file? Certain metadata properties, such as the package Owner and Localization files, are only available in a nuspec, which is why we like to keep it around.

Designer Metadata

After your activities have been created and your designers (UI elements) built, they must be linked together and registered in the metadata store in order to be displayed in the Activities panel of UiPath Studio. The code below creates two activities (Parent Scope and Child Activity) by registering the following information on behalf of each:

• Category: The section of the activities pane in which these activities will appear. By default, this is set to MyCompany > MyProduct and can be changed by modifying the Category attribute in Resources.resx. See how line 12 links a class from your activity project to the category specified in line 10.
• Designer: The UI for that activity. See how line 13 links a class from your activity project to a class from your design project.

• Documentation: Online docs for the activity. Select any activity in one of your UiPath workflows, press F1, and the help documentation for that activity will open in the default browser. The URL for this documentation is specified here, as in line 14 (go.uipath.com is used as a placeholder).

  namespace MyCompany.MyProduct.Activities.Design
  {
      public class DesignerMetadata : IRegisterMetadata
      {
          public void Register()
          {
              var builder = new AttributeTableBuilder();
              builder.ValidateTable();
              var categoryAttribute =  new CategoryAttribute($"{Resources.Category}");
              builder.AddCustomAttributes(typeof(ParentScope), categoryAttribute);
              builder.AddCustomAttributes(typeof(ParentScope), new DesignerAttribute(typeof(ParentScopeDesigner)));
              builder.AddCustomAttributes(typeof(ParentScope), new HelpKeywordAttribute("https://go.uipath.com"));
              builder.AddCustomAttributes(typeof(ChildActivity), categoryAttribute);
              builder.AddCustomAttributes(typeof(ChildActivity), new DesignerAttribute(typeof(ChildActivityDesigner)));
              builder.AddCustomAttributes(typeof(ChildActivity), new HelpKeywordAttribute("https://go.uipath.com"));
              MetadataStore.AddAttributeTable(builder.CreateTable());
          }
      }
  }

  
  

  

  
  

Building the Activity Set

Once the aforementioned files are complete, building the activity set is easy. Within the Solution Explorer, simply right-click your solution and select Rebuild Solution.

The output panel will then indicate that all three projects were built successfully and will provide the path to your bundled nupkg file.

Note: To build your activity package, you could also have right-clicked and "Rebuilt" the the MyCompany.MyProduct folder or the MyCompany.MyProduct.Activities.Design project. Why is this? See the next section on post-build scripts.

Post-Build Scripts

Navigate to the Properties > Build Events of your Design project and you'll find a post-build script, which runs immediately after all of your projects are built.

The first line of this script deletes any older, stale versions of the package that exist in the output directory in order to prevent clutter.

The second line uses the NuGet Command Line tool (nuget.exe) to combine your 3 projects' DLLs into one nuget package that can be read by UiPath Studio.

if exist $(TargetDir)Packages\)\)MyCompany.MyProduct*.* del $(TargetDir)Packages\)\)MyCompany.MyProduct*.*
if $(ConfigurationName) == Debug "$(SolutionDir).nuget\)\)NuGet.exe" pack "$(ProjectPath)" -OutputDirectory "Packages" -IncludeReferencedProjects -Prop Configuration=$(ConfigurationName)