Hi @Alexandru_Bizon ,
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.