Workflow Analyzer Custom rules not working as nuget

Help Something Else
, ,
1

Hi

I am building my own custom rules for Workflow Analyzer using this site as basis for my understanding:

I have built several rules that are working just fine, but now I ran in to a wierd problem.

My rules are working fine when I select Build Solution within Visual Studio, that produces 3 .dll files that are copied to the following folder:

C:\Program Files\UiPath\Studio\Rules\net8.0

However after selecting the option to produce a .NuGet package on Build, the rules are not loaded correctly into Studio, after pointing Package Manager to the file.
I need the .NuGet file for Marketplace/Package Sources.

image
image419Ă—120 3.12 KB

This has not been a problem in the past.
Could there be any properties that I have accidentally turned on/off that is causing this problem?

Regards
Soren

2

Turns out the error lies in how rules are loaded into Workflow Analyzer I presume.
After installing a package containing Workflow Analyzer Rules, I have to Close the project and reopen it, for the rules to display/load in.

2 Likes
Forum Engagement Daily Reports
3

can be confirmed, and good to know

@cprima (one of the previous MVPs) has started an initiative for supporting writing WFA Custom rules. We can recommend this resource as a first stop support guide, and for any other development help as well

2 Likes
4

Ah yea thank you :blush:
I have already starred Watchful Anvil on Github but have yet to dive into it.
Perhaps now is the time :+1:

2 Likes
5

Indeed Closing and reopening UiPath Studio helps in many situations, since I started to use coded source files I find myself doing that a lot! :slight_smile:

:white_check_mark: Glad that it also solved your challenge.

With WatchfulAnvil I try to deliver a baseline that is known to work. Just this week I added a nupkg with custom rules as a dependency. The full solution project code is out there, for anybody to compare with their own setup.
Just following the GettingStarted instructions should give in 30min a folder that is known to work.
For example the .csproj in this folder

The repository’s wiki is my dump of everything I encountered: If you filter the Pages for “KB PS” (abbreviation for knowledgebase problem-solution) there I have documented all obstacles that I encountered, like

One feature of WacthfulAnvil: If you forked it, then the GitHub actions should also build dll and nupkg for you! IIRC only the 4th action “publish to myget” needs a secret and will fail.

In the hope that this URL is publicly accesible: Take a look at chore: normalize formatting across templates, solution, and project f… · rpapub/WatchfulAnvil@dbfece5 : Just yesterday I added the nupkg from that output into one of my UiPath Studio projects as a dependency and it worked (latest build is a “prerelease version”, the filter in Package Manager must be set)

image
image492Ă—675 19 KB

So far I did not get feedback on the repo, would be great if you told me if anything is not working.
If you decide to fork it first, why not into an organization that you could invite me to? I would gladly do some troubleshooting in case something is not working.

2 Likes
6

I just take this occasion to braindump my learnings about the folders:

  1. C:\Program Files\UiPath\Studio\Rules was my preferred way of doing it, besides the fact that Admin permissions are needed. On the job I do not have these permissions.
    But it is the only way where debug symbols work, and Visual Studio can connect to the UiPath Studio process.

    When I found out that it breaks the uninstaller of the UiPath Studio, I began to use C:\Program Files\UiPath\Studio\Rules only for active rule development, when I want to connect with the debugger.

  2. And indeed my initially least preferred way, to use a nupkg dependency, became my preferred way. Even if we have no “development dependencies”, and I prefer to remove the rule nupkg before publishing to production, it is the most hassle-free way.
    Because then it is easy to consume new versions from many machines.

  3. I always setup my UiPath Studio to also point AdditionalAnalyzerRulePath to e.g. C:\Users\Public\Documents\UiPath\Rules. This setting is made in the UiPath Studio backstage view > Settings > Locations. The setting is persisted into to %APPDATA%\UiPath\UiStudio.v2.settings
    Works like the C:\Program Files location with the .dll file(s). But again, as I need to have the dll files available on potentially many machines this approach became only a fallback.

    As it does not require Windows Admin permissions and does not break the uninstaller I think such a setting is a great option.

1 Like
7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.