O365 List Item added activity - creates type of Studio.Generated.TypedDataRow

Hi friends, I have a problem when trying to using the Event trigger List Item Added.
When setting up the process in Studio, data types of Studio.Generated.TypedDataRow are created, and I can see them in the XAML as Studio.Generated.TypedDataRow1, Studio.Generated.TypedDataRow2, and so on. This causes an error when trying to publish the project to Orchestrator.

I can of course go into the XAML and manually remove this generated types, but really… should that be necessary? Also when I later activity, wham the generated types are back. What is going on here?

Using Orchestrator Cloud and Studio 2025.10.1 LTS.

Hi @ripers,

Can you please mention exactly what error you are getting or you can share the screenshot of the error that you are getting while publishing the project to Orchestrator. It will help us to gain a better understanding of the issue.

Thanks for the reply.

I get this error:

The assembly compilation returned the following errors:
 * (618,106): error CS0266: Cannot implicitly convert type 'System.Data.DataRow' to 'System.Data.DataRow3'. An explicit conversion exists (are you missing a cast?)
 * (618,106): error CS1662: Cannot convert lambda expression to intended delegate type because some of the return types in the block are not implicitly convertible to the delegate return type
 * (624,24): error CS0266: Cannot implicitly convert type 'System.Data.DataRow' to 'System.Data.DataRow3'. An explicit conversion exists (are you missing a cast?)

Screenshot:

Initially my variable was like this:

But I changed it to this:

If I go into the XAML and manually removes all references to DataRow3 I can publish, but the moment I changes something I get new generated type is created (DataRow4, 5, and so on)… and then have to clean up XAML-again. Very cumbersome.

Let me know if you need some more information. Thanks.

Hey @ripers ,

Is it possible for you to share the .xaml file?

@ripers

It does generated these hard types because of the new change to sync with cross platform and studio web..but ideally it should not revert automatically

can you please delete the .local files and other folders starting with . in the project folder after changes and save and then reopen and check…

or to verify try to create a new xaml with same activity instead of creating the variable automatically try to add datarow variable and select it in the output field of the activty and see if that sorts the issue

this was one of the reported issues earlier

cheers

Hi @ripers

Could you please still share the version of the MicrosoftOffice365 activity package that you are using in this project?


Aside from that, could you explain why you took these steps:

It sounds like you changed the type of that variable and then the errors appeared. Did I correctly understand the order of events here?

Good morning,
I am using version 3.5.10 of Microsoft activities. Have tried several version, same issue.

As for why I am changing to normal System.DataRow:

  1. We are working in a team, and checks in code to Bitbucket. If using DataRow3 etc, then someone else who checks out my code with DataRow3 will get an error on that type.
  2. Also (if I remember correctly) I also got errors myself when trying to publish DataRow3, 4, 5, etc.

So just to clarify: I can change from DataRow3 to System.DataRow and the project runs fine locally, no problem. It is just when I am trying to publish to Orchestrator I get the error mentioned above. If I manually go into the XAML and edit it manually by removing all references to DataRow3, I can publish to Orchestrator and everything works fine. But the next moment someone changes this activity, wham another Studio.Generated.DataRowX is back, and we once again need to manually remove all references to DataRowX.

Why does it change to generated types? Why not use normal DataRow?

Thanks again for your follow up.

1 Like

Thank you for the extra context. Two quick questions:

  • when you push it to Git, do you include the .local folder of the project?

In general, just to answer some questions as well:

Why does it change to generated types? Why not use normal DataRow?

The types are custom because they extend the functionality based on the source:

So that this is possible:
image


If possible, testing it out on one of the latest STS Studio releases would be really appreciated. There was work related to how those types are handled, and there is a chance it is already fixed.

We have git-ignore on .local.

I can try to test one of the latest STS Studio releases, will let you know how it goes. Thanks.

1 Like

Thank you. This would help us rule out certain possibilities of what could be wrong here. From the look of it, the Studio team might have already fixed it on the latest STS.