I created a Custom Activity which I called PasswordGenerator - and it works great, very happy with it and currently sharing it with my colleagues and considering putting it on Go! as it provides a better solution than the others I have seen (UiPath solution doesn’t use SecureString and has too many options for my liking). I’ve managed to get it in my Studio, although I’ve noticed that perhaps as it shares a name with another Package it is getting them mixed up, and I don’t want anyone using my package, especially those in my company, using a non-verified solution thinking it’s just an update I pushed.
Any help would be appreciated:
(when first clicking on Project Dependencies)
(after about 5 seconds)
I could rename my solution, but feel that this is not necessary and the packages shouldn’t be confused, assume this is a bug? @loginerror (sorry to tag you but only UiPath guy I’ve spoken to really on the forums)
If you’re trying to create a package that (potentially) has the same name as a pre-existing project, which how it appears since you’re installing 1.0.1 when there exists a 2.0.1, you’re probably best off changing your project name. Give it a unique tag in the name or something perhaps?
Another potential solution is to upload this as the highest version possible, but enable pre-release. This way you would know to “enable pre-release versions” in package manager to access it, but a normal user using the “PasswordGenerator” Activity would (and should) only be downloading/implementing the most recent stable version of the Package.
Hope this helps, I assumed your question was about something else, so feel free to ignore the previous comments that have been deleted and will be removed in the future.
Question for clarity: Is this a library you’ve created or a package? I’m assuming this is correctly labeled as a package, but from what I remember those must be named with “Activities” in the name in order for UiPath’s Activities Panel to pick them up.
Thanks for your reply. I might have to rename then, just seems like UiPath should be smart enough to notice that whilst they share a name, they’re not linked (different author, ID key etc?). I was also tempted to update to 3.0.1 to up Sean’s by 1, but didn’t want his users switching to mine if they meant to use his. The pre-release seems like an option but as I’m trying to push this out to multiple users some might feel they have the incorrect version.
For clarity question, it’s a library, I was under the impression they were also known as custom activities so apologies for any confusion! I will be sending it round as a nupkg file with a readme in a zip file though as we have multiple users on different Orchestrator tenants so this seems easiest.
I think renaming is probably the best option, and as for my clarity question, from what I’ve seen there’s a small difference between “custom activities” and “libraries”. They could be used interchangably, but “Custom Activity” tends to refer to one created in Visual Studio, whereas the “Library” is created within UiPath (and could contain Custom Activities) but is handled all internally by UiPath Studio.
The issue with being on Orch feed is that I’ll be sharing it with colleagues who don’t have access to our Orch, so will be in Local packages when they copy to their C drive/other location. However if they also have the nuget feed, mine will be “overwritten” by that, as shown in the above screenshots as I don’t have the other activity from Sean installed on my machine yet it’s still showing up in Local Packages?
Apparently, this one is based on the default behaviours of the NuGet and is an expected behaviour that will stay like it is. Please check out these sources:
In conclusion, the solution is to build your own libraries with a unique prefix name that will reduce the risk of confusing the packages.
I half understand why they do this, but it’s also arguably a bad design choice - the chance of there being similarly named activities/packages is too high, especially as more time goes on. Oh well, I’ve renamed mine PasswordGeneratorLite - as it’s simple to use with only 3 inputs, 2 of which are prepopulated and only need changing if you want to overwrite complexity rules. Soon to be hitting Go! I hope
