I’m suffering from the same problem in a project I converted from Windows Legacy a couple of days ago:
NU1101: **Unable to find package ActiproSoftware.Wpf**. No packages exist with this id in source(s): C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\, C:\Program Files\UiPath\Studio\Packages, C:\tmp\paquetsUiPath, https://api.nuget.org/v3/index.json, https://cloud.uipath.com/XXXXXXXXXXXXXXX/DefaultTenant/orchestrator_/nuget/v3/cXXXXXXXXXXXXXXXXXXXXXXXXXXXX/index.json, https://gallery.uipath.com/api/v3/index.json, https://gallery.uipath.com/api/v3/index.json, https://pkgs.dev.azure.com/uipath/Public.Feeds/_packaging/UiPath-Official/nuget/v3/index.json, https://pkgs.dev.azure.com/uipath/Public.Feeds/_packaging/UiPath-Official/nuget/v3/index.json
This sort of errors keep arising in my projects every now and then.
It doesn’t seem to cause any side effects but its so annoying.
I don’t have any broken dependences in the project; I already manually removed the ones from activities Studio couldn’t convert.
are you using any of the packages mentioned above in the topic? (if yes, which ones and which versions)
will the same keep happening if you start a blank project and then copy-paste the XAML files one by one (if there are multiple) to see which one will trigger the issue
typically not advised, but worth checking if the above yields some results to debug the issue → do you have any remaining references to ActiproSoftware in your XAML files (when checked via a text editor)
I’ve investigated it a bit by creating a test Legacy project with a Workday package 1.2.0-preview (which had ActiproSoftware.Wpf as a dependency). The library is indeed no longer on any public feed (including our UiPath official one), in which case it fails to be downloaded.
I then converted the project from Legacy to Windows (with an unresolved Workday package at this point), and the Workday package was automatically upgraded to version 1.4.1 which no longer uses this package as a dependency.
My current suspicion is that the migration might have went wrong and some references to the old library are still being used in your project, but it is hard to say without more detail.
I don’t have that Workday activity dependency mentioned above.
These are the ones I have, and I don’t see any in grey or red; the two ones I had in that last color where from activities that couldn’t be converted automatically and I already removed: Invoke Power Shell (I got rid of it) and another one related to Sharepoint, I think, that I already replaced with an equialent one:
I already deleted it, as it seemed that was not the one I needed to mess with Microsoft Teams. Then in the same operation some other Teams-related packages were updated. Now there are changes in my project I don’t know they are a a consequence of deleting this or updating the other ones. To be hones, I have difficulties finding out which activities are the ones I should be using, as many times there are some that overlap functionality with other ones. Gosh! Some are even called the same, have same (or different) icons, but then they are in different packages. And/or from some version to another there’s substantial changes, but this is not reflected anywhere, or nothing I’m aware of. Then some remain in alpha state for years, with never having a stable release, even if they are in advanced version numbers. Some others you never know if they are abandoned. For the sake of god: can you tidy up this?
All in all: is it safed / convenient deleting this activity, as I did, if I want to perform Microsoft Teams tasks? The description of the package itself couldn’t be even more confusing, also: “A set of activities for interacting with Azure Form Recognizer V3”. What the heck has that to do with Microsoft Teams??
This assumes (and requires) the usage of the Integration Service. A single package that then takes care of dynamically providing the latest version of the activities per service.
In this sense, it is safe to remove all the other Teams packages, which are then not required.
I believe the activities that you can add from the + icon (and the Command Palette) will also default to the new way with a single Integration Service package.
So before we dive into trying to figure out the other activities and what is the deal with them… Is the above context maybe enough for your use case?
(A) Is the way I tried yesterday. It worked. It had a “Microsoft Teams Scope” activity that it forced me to use in order to use the “Insert Record” one, which was the one that provided the finall functionality I needed. That belongs to UiPath.MicrosoftTeams.IntegrationService.Activities.Scope.
After I removed the package that I mention causing problems in this thread and getting some updates to toher packages,
(A.1) looked this weird; there’s no “Microsoft Teams Scope” activity anymore in that set of activities and the “Insert record” now seems to work without a need for that scope (C).
Finally, there’s the (B) activity, that looks quite similar to the (C) one, apart from the icon. And the fact that it doesn’t have a “Switch to Object View”/“Switch to Additional Properties View” link, that otherwise “works” at its on will, as it never reacts to my clicks but, later, when reopening the project or messing around, appers in one state or another.
So, all in all, which one should I stick with?
Why you keep the older ones around and update them if only one is to be used?
I will send this screenshot to our Integration Service team, wow.
But as far as being able to progress here. If you check my previous post and have the Integration Service Activities 1.2.0 package installed that I showed on the screenshot, then I would personally remove all other Teams packages and go with that.
From your screenshot, the activity B should be the only one that is left after that.
prashant1603765
ashokkarale
mively
anjasing
Yoichi
sonaliaggarwal47
lrtetala
V_Roboto_V
pikorpa
sharazkm32