Change in variable types after deleting/updating/upgrading packages

Feedback Studio
,
1

I was messing with packages. Initially, installing some FTP-related activities. After I finished my tests, which proved unsuccessfully, I proceeded to go to the package manager to uninstall them. By that time, I also found some updates. These are some of the ones I remember I marked for update:

UiPath.Excel.Activities, UiPath.UIAutomation.Activities, UiPath.systemActivities, UiPath.Testing.Activities

After it finished doing its work, suddenly a number of errors in my open project showed up that didn’t exist before. I had to manually solve them, and what happended involved 3 or 4 variables that changed its type without a reason. That I can remember:

  • One SecureString changed to plain text String.
  • There was one who changed from ILocalResource something to String.
  • An “In” Argument changed its direction to “Property” and its type from Dictionary<String,Object> to something I don’t remember.

Using Studio 2023.6.1 Community Edition.

To be honest, I don’t think this is serious for a production environment… :confused:

3

It’s not recommended to change versions randomly. Once you have a project developed with a version there is no need to change to a random version (especially if it’s an downgrade).

1 Like
5

I thought it was always recommended and a good practice to UPDATE packages, which is what I did, as I said in my original post. I didn’t downgrade anything, and I didn’t “change versions randomly”, but UPDATED because an update was available and I was having some problems that could have been bug-related. Still, I don’t understand why this should change my variable types if there was not any related change.

6

Alexandru is correct, there’s no reason to do this. If it ain’t broke, don’t fix it.

7

I didn’t mean to “fix” anything. I just updated. To my knowledge, it’s always been good practice and recommended by software vendors to update/upgrade to last versions, as it’s expected to fix bugs, security holes and improve performance. And, as I said, I was having problems with the activity; it could either be my fault (probably), or it could be a problem in the package.

In any case… there’s gonna be a point were, if the package keeps updated/upgraded, the user won’t have any other chance than updating. So they are probably gonna experience the same problem as me at some point. Sorry dudes, but simply recommending “not updating” to overcome this bug, and being recommended from one member of the staff himself is… not serious, to say the least.

8

There’s loads of bugs here and there and everywhere, the development team releases updates regularly, then even community version updates itself on its own, without a chance for the user to avoid it… and then the staff tells us “not to update ‘randomly’”. Yeah, so clever.

9

The error you get with the data type changing to String and Property I agree should be considered a bug.

Here is how it happens.

Lets say you have a property with a complex DataType. Lets say its a CustomType1.

If you update the dependency that CustomType1 is from and CustomType1 is no longer present, or has moved namespace, rather than the argument giving an error it transmutes into a Property and switches to a string.

This is gross, you lose your argument directions and data type, there should be a better mechanism to demonstrate the data type in the XAML is missing without wiping it out and converting it to a property. I firmly believe this should manifest in a much clearer error rather than it silently converting all of these arguments.
Variables suffer the same fate but at least stay as a variable.

So agreed on being careful on upgrading, for sure, but thats still not a valid reason to handle missing types like this in my opinion.