I’m currently working on an installer that deploys custom Workflow Analyzer rules (.dll) to the appropriate folders, depending on the detected UiPath Studio version.
Before I finalize the logic, I’d appreciate confirmation (or correction) on the following assumptions:
The docs do not cover the latest changes, but my current UiPath Studio 2025.0.161 Community edition in System mode has the above folders for sure.
(Note: current Studio does not edit legacy projects anymore, but the folder net472\Rules is still present. I assume, but did not test yet, that the folder will remain for as long as the Robot executes “legacy” projects.
For my installer, which will be publicly available with a permissive license, I also plan as fallback to install into C:\Users\Public\Documents\UiPath\Rules, so that this folder could be configured in Studio > Settings > Locations > “Custom Workflow Analyzer Rules location”.
And yes, NuGet feeds are also being prepared, for project-specific consumption.
Am I missing anything?
Any surprises from Community vs Enterprise builds?
I plan to detect presence of the folder, and place custom workflow rule DLLs in all that are present. Because I did not have luck with the registry.
Seems that 2 installers will be most helpful, with and without elevated permissions.
Installer will optionally prompt for a user-specific location
If no folder is found, the installer peers into its glass ball and defaults to %Public%\Documents\UiPath\Rules, installing a net6.0 DLL.
Call to Action
If you’re using any version of UiPath Studio, especially Enterprise builds or uncommon install modes — please compare the folders listed above with your actual installation.
Do these folders exist on your machine?
Are the versions and DLL expectations accurate?
Any unexpected deviations? Hidden folders? Bonus surprises?
I’d love to hear back — even a one-liner like
“Confirmed on 2022.10.5 Enterprise, per-user mode”
is hugely helpful.
Let’s crowdsource some clarity here.
Thanks in advance!
Thank you for sharing your approach.
That said, I’d like to offer an alternative method that is more aligned with deployment needs in enterprise environments, particularly where security controls and scalability are a concern.
Recommended Approach: NuGet Package Deployment via Automation Ops
In large-scale environments, copying .dll files to local Rules folders introduces several challenges:
Security restrictions: Enterprise machines commonly enforce policies that block unsigned or externally downloaded .dll files. Microsoft Defender, for instance, may quarantine or prevent execution unless files are manually unblocked, which is not scalable or secure in managed IT environments.
Inconsistency and overhead: Manual steps create room for version drift or misconfiguration across teams, especially when onboarding new developers.
To streamline deployment and ensure consistency across all development environments, the recommended approach is to distribute custom rules as signed .nupkg packages and manage their availability and enforcement centrally via Automation Ops.
Deployment Procedure
1. Package Custom Rules into a NuGet Package (.nupkg)
Develop your custom Workflow Analyzer rules and compile them into a .dll file.
Create a .nuspec file containing metadata about your package and referencing the .dll.
Use the nuget pack command to generate the .nupkg file.
2. Host the NuGet Package on a Custom Feed
Upload the .nupkg file to a NuGet feed accessible to your development environments. This can be an internal NuGet server, Azure Artifacts, Artifactory, or a shared network location.
This feed will later be referenced from UiPath Studio via Automation Ops.
3. Configure Automation Ops to Deploy the Custom Rules
Access Automation Ops in UiPath Automation Cloud.
Create a new governance policy or edit an existing one targeting Studio.
Under Manage Sources, add the custom NuGet feed where the package is hosted.
Ensure the feed is enabled.
Assign the policy to the relevant tenants, user groups, or folders. Studio will now recognize the feed and the package in all governed environments.
4. Enforce the Use of the Custom Rule Using ST-USG-027
In the same Studio policy (in Automation Ops), go to the Workflow Analyzer section.
Enable and configure the rule ST-USG-027 - Required Packages.
Specify the required package ID and version to enforce the presence of your analyzer in all projects. Example: MyAnalyzerPackage>=1.0.0
Set the rule’s Action to determine whether a violation results in a warning or an error.
By using this approach, you ensure that:
Custom rules are distributed and versioned centrally.
Enterprise security requirements are respected.
Governance is consistent and scalable across all Studio environments.
Thank you again for initiating this discussion — it’s a valuable contribution to the community. I hope this complements your guidance with an approach tailored to global policy enforcement scenarios.
Thanks for taking the time for the detailled answer. In “ITIL lingo” I can only partially “accept” that as a solution though:
a) The nuget package then needs to be a project dependency, and if not removed will remain a dependency in production. Absent a “development dependency feature” like requirements_dev.txt in Python or devDependencies in Node.js I feel very strongly that a nupkg for a static code analyzer has nothing to do in a production package.
b) according to my tests and my GitHub Action-based build workflow dotnet pack simply does not work:
It needs a specially-crafted nuspec to exclude the dependencies.
This nuspec is nowhere documented on docs.uipath.com
c) Which brings me to my last aspect: The official docs at SDK - Building Workflow Analyzer Rules primarily document the use of dll files and the filesystem paths. Given the typical support processes in an enterprise setting (search docs first, then contact paid enterprise support) I feel I should follow the official docs, and not deviate based on “buried” forum posts. I highly encourage to update to the docs with the latest vendor suggestions, as docs are a bit brittle.
Typing out my thoughts about “dev deps” makes me wonder though, and I will try to find time once back from travelling: Maybe my build pipeline based on uipcli.exe can simply copy project.json to project_dev.json, add the dependency (easy to do in PowerShell as one can read a file as JSON) and then run uipcli package analyze "C:\userprofile\AutomationProject\project_dev.json" ?!?
I never tried to “mess with” the project.json filename. So far.
Lastly, the typical enterprise restrictions with dll files might be remedied through an installer. My build script already generates an Inno Setup-based .exe, although in my early hobbyist explorations I do not intend to pay for a code-signing certificate. Depending on the trust level a certificate aquired over time, or if there is an internally trusted certificate available, this seems to me the most feasible approach.
UiPath Version → Target Folder → Workflow Analyzer rule build DLL
Call to Action
