Studio screwing up things again when converting project to library

[pere]

Trying to convert a project to library for the 1st time.

1st I had to convert (back) a bunch of variables I “globalized” not long ago because… libraries don’t support globals. D’oh.

When it’s suppossedly done, a bunch of other problems arise when trying to publish.

Look at the screenshots.

Bugged one:

Original one:

As usual, Studio finds its way to corrupting everything. In this case, ye ole one “changing the type of the variable” on its own.

And a bunch of other problems like that. And the error messages couldn’t be more esoteric.

Please address this once and forever.

[pere]

The same stuff as usual. When converting the project, Studio corrupted it. Whe I reopen the project, every time it asks if I want to fix some “missing dependencies”. I say “yes”, it does its stuff, but fixes nothing.

In my attempt to get the variable type back, as it’s not available in the list of types,

• I drag & drop the same activity again.

Notice in the output panel it successfully installed, this time, a bunch of dependencies (that should already be there as the activity was there).

Please take a look at the difference between the two same activites.

The original one:

There’s no properties there. It says “All properties are visible within the activity card”. Which is false.

The new, re-dragged activity:

Properly shows the Output variable text input.

So finally re-dragging the activity brings back the proper output type as available again:

What a crappy naming; “C54DB what the heck teamsAsy.eAuBR whatsoever”, as I reported long ago in another bug nobody gave a damn about it.

And, even that, after configuring the new “instance” of the same activity with the proper output variable (“maerda”) with the proper type, and selecting the old one that Studio converted on its own to String back to teamsAsyncOperation_Retrieve… It still complains about being of type String and not of the proper type.

What a load of cr*p.

[loginerror (Maciej Kuźmicz)]

Thank you for reporting your findings. I sent it over to our team. It looks like the root cause is the global variable at the moment of exporting to the library project.