Erstellen von Aktivitätspaketen

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-Dateien

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 enthält die Metadaten, die nur für dieses Projekt vorhanden sind (z. B. MeinUnternehmen.MeinProdukt).

• 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

#i DEBUG
[assembly: AssemblyVersion("1.0.*")]
#els
[assembly: AssemblyVersion("1.0.0")]
#endi

The next Assembly file, 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 Activities</tags>
    <dependencies>
    </dependencies>
  </metadata>
  <files>
    <file src="$OutputPath$**\)\)MyCompany.MyProduct*resources.dll" target="lib\)
et461"/>
  </files>
</package>

Hinweis:

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-Metadaten

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());
          }
      }
  }
  

  

Erstellen des Aktivitätssatzes

Sobald die oben genannten Dateien vollständig sind, ist das Erstellen des Aktivitätssatzes einfach. Klicken Sie im Projektmappen-Explorer einfach mit der rechten Maustaste auf Ihre Lösung, und wählen Sie Projektmappe neu erstellen aus.

Der Ausgabebereich zeigt dann an, dass alle drei Projekte erfolgreich erstellt wurden, und gibt den Pfad zu Ihrer gebündelten nupkg-Datei an.

Hinweis:

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

Skripte nach der Erstellung

Navigieren Sie zu Eigenschaften > Buildereignisse Ihres Designprojekts, und Sie finden ein Post-Build-Skript, das sofort ausgeführt wird, nachdem alle Ihre Projekte erstellt wurden.

Die erste Zeile dieses Skripts löscht alle älteren, veralteten Versionen des Pakets, die im Ausgabeverzeichnis vorhanden sind, um Ordnung zu schaffen.

In der zweiten Zeile wird das NuGet-Befehlszeilentool (nuget.exe) verwendet, um die DLLs Ihrer drei Projekte in einem NuGet-Paket zu kombinieren, das von UiPath Studio gelesen werden kann.

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)