Solutions for .NET Interop Issues involving Sensitivity Labels?

JK 40

We have code that is supposed to create an Excel document via .NET Interop, then save this workbook.

The problem is, starting with Office 365 Build 2312, the sensitivity label functionality has changed, seemingly to accommodate increased restriction on saving workbooks when an organization requires that there be sensitivity labels when saving a document.

If an organization requires that a user supply a sensitivity label for saving, the 'Workbook.SaveAs' function just simply does not even work anymore. Originally, this function would show a sensitivity label popup where the user could set the label, then the function would continue. This would occur regardless of whether the 'EnabledEvents' or 'DisplayAlerts' booleans were set or not, which was good for us.

The preferred solution would be to manually show this sensitivity label popup. However, I cannot find any API call, boolean, or other thing to set that would show this dialog. It does not seem to be possible to show it anymore. This dialog does still seem to exist, as if I load up Excel manually and save without setting the label, it will prompt me with it first before it successfully saves.

I did find that if DisplayAlerts is 'true', the Workbook Close function will show the Excel 'Save As' dialog, which allows the user to save to a location, and specify the sensitivity label at the same time. This is not ideal, however, because we need to be saving to a predictable location for use with temporary files.

I am aware that there is a Microsoft Information Protection SDK library which allows for software to load and specify sensitivity labels. This, however, seems to require some kind of agreement with Microsoft to publish the software? This does not seem ideal either. It would be far preferable for the Office applications to handle the sensitivity label setting themselves, as before.

The only other solution that comes to mind is to use other libraries which can generate Excel documents, without worrying about the sensitivity label at all.

So, I don't know if there is some solution that we missed. Or, if this might be a bug due to the intersection of these three (Intertop, Office, Purview) that might need to be looked at. Thanks.

Givary-MSFT 27,966 Reputation points Microsoft Employee

2024-02-29T03:35:12.1066667+00:00

@JK Thank you for reaching out to us, this might require detailed discussion with our support team, please send us an email on azcommunity [at] microsoft [dot] com referencing this issue with a subject line "ATTN:Givary" along with your Azure subscription id and we will help you with one time free support option for this issue.
Yiannis Papoutsis 10 Reputation points

2024-03-05T11:41:42.1866667+00:00

I have exactly the same issue as the Original Poster described. Since the last few days, my export function stopped working and no error was fired. Could you please post a solution rather than asking to contact you in private way?
JK 40 Reputation points

2024-03-05T20:24:07.2633333+00:00

Some additional information I discovered yesterday:

It looks like the Interop still works fine in the simplest possible example... export of a single cell to a datasheet.

If you attempt to modify the worksheet's orientation, then the save will no longer work. Not sure what this means, but maybe it's a clue to somebody.
JK 40 Reputation points

2024-03-05T20:28:37.6866667+00:00

[duplicate]
Dan Prodrick 0 Reputation points

2024-03-07T14:05:11.2333333+00:00
This workaround is only suitable for cases where there is user interaction, not for automated generation.

In our legacy application instead of using the SaveAs() method, we made the excel sheet visible to the user, then simply release the COM objects and call garbage collection for cleanup. Control is then handed to the user where they can set their own sensitivity labels and save where they like.

Make the workbook visible so that when it's created in the code, it displays to the user.

Remove any instances in the code that kill the Windows process the app is running in, and any instances trying to close/kill the excel app.

In the "finally" clause, release control of the COM objects and call the garbage collector to prevent memory leaks.

The user can apply their own labels and save.

1 answer

Yiannis Papoutsis 10 Reputation points

2024-03-28T16:54:15.26+00:00

is there any update?
Please sign in to rate this answer.
JK 40 Reputation points

2024-04-01T15:22:01.4133333+00:00

I have not yet heard anything back on this.
Sign in to comment