Hi,
It would be great if we were able to convert an existing project into a solution. This would increase organization for projects and allow for easier and cleaner version management and deployment.
Thank you for your suggestion, @thomas_v , I’ve filed this feedback on our side.
Just want to check if you are aware @thomas_v, you can make a new solution any time you want and include existing packages you have published etc, and include libraries if they are dependencies. Its a pretty good way of migrating between tenants or organizations.
They dont just exist in Studio web is what I want to make sure you are aware of.
Hi @Jon_Smith,
We only use Studio Desktop 2025.10 LTS, no Studio Web. We were specifically looking for creating solutions for libraries, not processes. But that is feature-request is being handled here.
Also there is no support for creating solutions either in Studio or Studio Web on LTS and I wasn’t aware that was already part of STS upon making this post. (even though the documentation states it is possible to create a solution from Studio Web)
As of now we have no use for solutions as long as we aren’t able to include libraries. I was aware you could import/add existing projects to solutions, but I appreciate the heads-up anyways!
Yeah, you dont need any specific Studio Desktop version to use Solutions, and I am telling you. If you are on cloud, you can make a solution, with Libraries included aswell as your normal projects, without touching Studio Web.
Solutions existed before Studio Web did, and all that legacy functionality is there.
You can make sure all your packages and artifacts are present in for example your Dev tenant, build the solution in the Orchestrator (not Studio web or Studio desktop) and then use that solution to upload it to another tenant.
I honestly much prefer it, cause I dont like working in Studio Web and need desktop, but I dont like having to manually handle things like queues and assets etc.
I am pretty sure what you want exists but you aren’t aware of it, thats what I am trying to get at.
The request you have for libraries, as I understand them processing it, is that you have the library project as part of your solution, which I dont think is good architecture. If you want to have the packaged depdendencies in the solution. That exists, I can show it you right now.
Hi,
I’m not sure what you mean with the first part of your message. Do you mean packaging deployed projects (including libraries and assets) to be able to move then to different tenants?
I’m aware that you generally want to have libraries as dependencies and not included in the solution. (And that’s also what we do)
We specifically have a need for a solution for only libraries. As we have about 7 libraries right now that are all for a single application and we expect library count for just that application may reach >30. Being able to have these all in a solution would make organization and maintenance much easier. We also wouldn’t need >30 GitHub repo’s and would be able to cache nuget packages using UIPCLI all in one, instead of all separately.
As to why we have that many separate libraries instead of 1 big one? Firstly: easier for employees to maintain and know what each library does, secondly: because not every process requires every library, thirdly: regulations require us to do pen testing on every process, and this is easier if we only include libraries that are needed instead of really large ones where 75% of the functions aren’t used. (And this is obviously better for security)
A picture perhaps explains it clearer.
Look, Solutions have a section where you can upload library packages.
When you deploy the solution, those library packages are uploaded to the tenant library feed.
Its an oversight or missing feature right now that you cannot directly select a library from the tenant library feed, but you can manually add it. Thats what I am trying to explain and what I believe you are not aware of.
Interesting. I wasn’t aware of that.
It isn’t what we were looking for, but still good to know.
Also interesting then.
You want the uncompiled library project included in a solution? Otherwise I dont understand what you want.
You can start a fresh solution at any time, and select an existing project that is in a folder etc, and use libraries in it, I thought thats what you asked for?
Yes correct, see 2 posts ago, we want multiple uncompiled libraries in a single solution.
Fair enough. I dont understand why you want uncompiled ones then. If the library is not compiled it cannot be used in a project.
Lets say your current robot is using version 26.5.1, what do you want the solution to do with the uncompiled one? Publish it to 26.5.2? That published version won’t be able to be used in the project.
Or is it that you dont want the library in the same solution as the project that consumes the library, but more that library deployments can also be managed via the solutions? If so I understand a little but more, but am curious what the benefit you see is. In my opinion best practice for a library means that you do not include any artifacts from the Orchestrator in there, so packaging queues, assets, buckets, entities etc doesn’t help. At that point what is the benefit.
(Hope you dont mind me grilling you, genuinely curious on your use case to perhaps consider an angle I havent thought of).
This exactly.
Let’s say we have an application called ‘Application1’.
I want a solution called ‘Application1’, then I want to create (inside solution ‘Application1’) library ‘Application1.Authentication’, ‘Application1.Management’, ‘Application1.Message’, and so on. If I would have 30+ of those and combine those all, the 1 library would be huge (and thus hard to maintain for colleagues unfamiliar with the library), if I would separate them all, we would need tons of repo’s, caches, hard to maintain (or even find the right library).
Now if I could put them all in a solution, I can publish all to a single GitHub repo, and use ‘uipcli solution restore’ to get all nuget packages and cache all of these together.
Now when there’s a problem with Application1 everyone can easily find it in a single repo, clone it, and have a nice overview of all the libraries instead of having to search for a specific one in dozens of repo’s.
Now we could even use CI-CD and have all libraries match version numbers based on eg Application1 version, or just all libraries having the same version. (Not something we are currently planning on doing but at least possible)
Ok, the use case is clear now, deployment of several libraries together. Interesting thought, I’ll keep it in mind and if I see something that works regarding that I’ll let you know thomas_v