Configuration file per project

Now that we have dependencies per project available, why not continue in this way? (the Visual studio way)

Every project could have its “.config” file as it is the case for app.config in Visual studio.
The UiPath studio could allow to open/change this file in a user-friendly way via a dedicated dialog/window.

This type of feature is now worked around in a standardized way in the framework but having to open the spreadsheet every time and having to close it is a bit of a pain.

If you look closely at it, this would somewhat fix the issue of the Global variables.
There could also be an option to configure this config file from the Orchestrator level, via the release itself.


Something like each project will have a config for

  • queue name
  • assets

This will help further when migrating a package from one Orchestrator to another as it will create the assets/queue if they do not exist?

I personnally think that Assets and configuration should be separated concepts.

Assets: Having A global outreach, apply to several process/project within an environment or tenant (as it is now)

Configuration: Scope to a specific project or release. Like the Config.xlsx, having the same role as Config.xlsx from Reframework.

The improvement idea here would be to have it in a similar way as Visual studio is doing it via some kind of friendly UI as bellow

Bind this would a .config file (xml) where effective value would be stored.


Other Continuous improvement idea that you mentioned are good tho, but should be part of a different discussion I believe :slight_smile:


So. Would you be able to edit the config file in Orchestrator? In different environments?

If yes, that will pose a problem since we need to unpack and re-pack the package itself with the new config file. In the future we want to introduce package signing. Would it work if we alter the package?

Edit is in a friendly way from Studio would be a good start.
Then yes later, Would be good to have it editable only for the specific release if required.
The Package could set the settings mapping, The release the value.

ex: I publish one automation package with 3 settings and their default value, when I release, I can edit Values on for release of those three settings.

At the end, the should just be modifying some XML, which will be consumed only on run-time by the Robots.
this could be done via some kind of orchestrator UI such as Robot Settings in Orchestrator.

The difference is that configuration would vary from one project to another.


Again this will pose a problem because we need to unpack and re-pack the package itself with the new config values. In the future we want to introduce package signing and unpaack-repack will not work anymore.

I’m confident you have the software engineering power to solve this issue :slight_smile:
Worst case, you republish once the config file is changed


1 Like