After upgrade to Graph .NET SDK 5 with the removal of "Request()", the usageRights object is no longer available from the users[id] API

[jimbarrett33]

Describe the Problem
In a ASP.NET 6 Core app, I was/am using the Graph Beta endpoint where the usageRights API is (only) available (it's been in beta for a long time).

Before the upgrade to Graph SDK 5 this code worked:

var usageRights = await _graphServiceClient.Users[user.Id].UsageRights
        .Request()
        .Filter(<my filter>)
        .GetAsync();

After upgrade to Graph SDK 5, and the removal of the Request() from the fluent API, this code does not compile:

var usageRights = await _graphServiceClient.Users[user.Id].UsageRights
         .Filter(<my filter>)
         .GetAsync();

Error CS1061'UserItemRequestBuilder' does not contain a definition for 'UsageRights' and no accessible extension method 'UsageRights' accepting a first argument of type 'UserItemRequestBuilder' could be found (are you missing a using directive or an assembly reference?)

To Reproduce

• Install nuget Microsoft.Identity.Web.GraphServiceClientBeta
• remove "Request()" from the Fluent API code
• get compiler error

Expected behavior
I expect the usageRights object/API to be available like before.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Visual Studio 2022

Additional context
I am trying to upgrade to keep current and also use the new Retry interface but seem to be blocked now. I guess I could use the REST endpoint directly but I want to keep using the SDK for code consistency.

[andrueastman]

Thanks for raising this @jimbarrett33

I believe the code should look something like

            var usageRights = await graphClient.Users["user-id"].UsageRights
                    .GetAsync( requestConfiguration => requestConfiguration.QueryParameters.Filter = "filter expression");

Any chance you can confirm how you are creating the _graphServiceClient object, as the UsageRight api is available on in beta, the object should be created/imported from the Microsoft.Graph.Beta namespace

https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/dev/docs/upgrade-to-v5.md#namespacesusings-changes

[jimbarrett33]

@andrueastman Thanks for the quick reply. It turned out that my package imports were not resolving to beta client so I was able to get past the error by fixing that and your code above. Thanks for that.

Now I am faced with the issue of configuring the service for dependency injection. Below is code that used to work and updated code using the latest SDK, which results in an error.

Before

builder.Services.AddMicrosoftIdentityWebApiAuthentication(builder.Configuration)
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddMicrosoftGraph(builder.Configuration.GetSection("DownstreamApi"))
    .AddInMemoryTokenCaches();

After

builder.Services.AddMicrosoftIdentityWebApiAuthentication(builder.Configuration)
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddMicrosoftGraphBeta(builder.Configuration.GetSection("DownstreamApi"))
    .AddInMemoryTokenCaches();

Notice the change to use AddMicrosoftGraphBeta(...) which results in error:

Compile Error
Error CS1929 'MicrosoftIdentityAppCallsWebApiAuthenticationBuilder' does not contain a definition for 'AddMicrosoftGraphBeta' and the best extension method overload 'GraphBetaServiceCollectionExtensions.AddMicrosoftGraphBeta(IServiceCollection, IConfiguration)' requires a receiver of type 'Microsoft.Extensions.DependencyInjection.IServiceCollection'

Note that if I use the "Before" code with Microsoft.Identity.Web.GraphServiceClientBeta installed and try to inject GraphBetaServiceClient graphServiceClient in my API controller I get a DI error (which I think makes sense).

Note also that I am implementing the behalf-of-flow for the API using EnableTokenAcquisitionToCallDownstreamApi() so this is an important line of code.

You have any ideas how to make this work?

I think this may eventually help others too. I have an office-js add-in that implements SSO and the OBO flow with code initially based off of this article https://learn.microsoft.com/en-us/office/dev/add-ins/develop/create-sso-office-add-ins-aspnet#configure-microsoft-graph-and-obo-flow

Also, regarding that article, it seems that the MicrosoftGraphOptions class is gone now, also invalidating the article: https://learn.microsoft.com/en-us/office/dev/add-ins/develop/create-sso-office-add-ins-aspnet#create-the-apifilenames-rest-api

Thanks again.

[jimbarrett33]

@andrueastman One other thing is related to the retryHandlerOption not working. I simulated 500 errors locally using devProxy tool and the retries never happen.

My code is verbatim to the code below which is the exact example from https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/dev/docs/upgrade-to-v5.md#per-request-options

I am using the GraphBetaServiceClient but I don't think that should matter. The retries never occur so it seems maybe the GetAsync(requestConfiguration => is not setting the configuration correctly?

var retryHandlerOption = new RetryHandlerOption
{
    MaxRetry = 7,
    ShouldRetry = (delay,attempt,message) => true
};
var user = await graphClient.Me.GetAsync(requestConfiguration => requestConfiguration.Options.Add(retryHandlerOption));

[andrueastman]

Any chance the following docs are helpful?

https://github.com/AzureAD/microsoft-identity-web/blob/master/src/Microsoft.Identity.Web.GraphServiceClient/Readme.md#usage

This may need to change from

builder.Services.AddMicrosoftIdentityWebApiAuthentication(builder.Configuration)
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddMicrosoftGraphBeta(builder.Configuration.GetSection("DownstreamApi"))
    .AddInMemoryTokenCaches();

to

builder.Services.AddMicrosoftGraph(options => 
                           services.Configuration.GetSection("DownstreamApis:MicrosoftGraph").Bind(options) );

[andrueastman]

@andrueastman One other thing is related to the retryHandlerOption not working. I simulated 500 errors locally using devProxy tool and the retries never happen.

My code is verbatim to the code below which is the exact example from https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/dev/docs/upgrade-to-v5.md#per-request-options

I am using the GraphBetaServiceClient but I don't think that should matter. The retries never occur so it seems maybe the GetAsync(requestConfiguration => is not setting the configuration correctly?

var retryHandlerOption = new RetryHandlerOption
{
    MaxRetry = 7,
    ShouldRetry = (delay,attempt,message) => true
};
var user = await graphClient.Me.GetAsync(requestConfiguration => requestConfiguration.Options.Add(retryHandlerOption));

Following up in #2357

[gruering]

We are also having issues with the usageRights API (https://github.com/microsoftgraph/microsoft-graph-docs-contrib/issues/8879) and based on your feedback @jimbarrett33 regarding reliability we are wondering what is the current recommended approach the verify usageRights in a SPFx webpart or Office-addin.

[jimbarrett33]

@gruering I'm not sure if this will be of any help but I found my issues with the usageRights API by using Application Insights in my app and reviewing logs/metrics on the Azure portal. I am seeing a lot of 500s when calling the API. It doesn't seem to be the same as your issue because I believe you are getting a 200 back. With Application Insights and using the Azure portal, you can see the events and/or API calls that happened before and after your API call so that may help you. However, not sure if you're using Application Insights or if that's even possible in SPFx Web Parts.

I opened this issue /microsoftgraph/microsoft-graph-docs-contrib/issues/9203 which was immediately closed by automation because it was started from inside MS docs.

I did not get anywhere with Azure support either.

I am looking to connect with others that are using the usageRights API in hopes to push Microsoft to give it attention and move it out of beta. If your interested, let me know.

[gruering]

Yes I am very interested and also curious to know how you are accessing the usageRights API. Can you share some details about that? We are having troubles to access the usageRights API in multi-tenant scenarios (response is always empty)

[jimbarrett33]

@gruering Sure. I would prefer not to share here though. If you want to shoot me an email at jim@strivetech.com we can discuss or setup a meeting.