The framework 'Microsoft.WindowsDesktop.App' is required by ConfidentalClient preventing migration from ADAL to MSAL

[ayrton97]

We are trying to migrate from ADAL to MSAL in the azure function (currently we are using ADAL targeting net6.0-windows10.0.17763.0 w/o any issues)

The migration seems to be straightforward, we added reference to the latest identity client Microsoft.Identity.Client (4.42.0) and updated the code, but the Azure Function doesn't start and complains on missing dependency

The framework 'Microsoft.WindowsDesktop.App', version '6.0.0' (x64) was not found.

Looks like the MSAL has a dependency on Desktop runtime which is not deployed on the Azure Function VM and apparently there is no easy way to get it there.

The current setup is: a library (targets netstandard2.0) => Azure Function (targets net6.0-windows10.0.17763.0 (due to specific Windows dependency). We've tried explicit binary targeting in the function to Microsoft.Identity.Client netcore2.1 binary => same issue.

Ideally, it would be great to split MSAL library to provide a lightweight client w/o any Desktop runtime dependency for Net 5+

[gladjohn]

Looks like the MSAL has a dependency on Desktop runtime which is not deployed on the Azure Function VM and apparently there is no easy way to get it there.

The workaround for now is to publish using a self-contained azure function.

[Kavya-Gogula]

I am currently working on the migration of azure functions to v4 and .net framework from net472 to net 6.0. This defect blocks me. Can you please give us the ETA for this bug to be resolved?

[bgavrilMS]

@Kavya-Gogula - why does this block you? Do you need to target net6-windows10.0.smth.smth i.e. need to call Windows SDK?

[Kavya-Gogula]

Yes @bgavrilMS , I need to use the target framework as net6.0-windows10.0.19041.0.

[bgavrilMS]

Ack, will provide an update on this by mid next week.

[bgavrilMS]

We've investigated 2 approaches to this:

• drop net5-window10.x.y.z target and try to provide good exceptions to users. Sadly, this is a breaking change and we do not have telemetry to understand how many ppl are impacted. In some scenarios, we will not be able to provide exception. Instead, a redirect URI error will be shows to users. So while this is still an option, we are trying to avoid it.
• we are now investigating separating the confidnetial client logic into a separate package. MSAL.Confidential would only be built against netstandard2.0, net6 and net461. MSAL would still have both public client and confidential client flows, but the confidential APIs would be moved to MSAL.Confidential. Type forwarding will have to be used. This is being worked on and I'll update the thread with findings.

[pmaytak]

@ayrton97 @Kavya-Gogula Were you able to use Microsoft Identity Web instead of MSAL directly?

[bgavrilMS]

I can't seem to repro this. Here's what I did:

1. Created a new Azure Function app and edited the csproj like so:

2. Left the publishing profile as is:

3. Added some code to call MSAL, just be safe

  [FunctionName("Function1")]
        public static async Task<IActionResult> Run(
            [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req,
            ILogger log)
        {
            log.LogInformation("C# HTTP trigger function processed a request.");

            IConfidentialClientApplication cca = ConfidentialClientApplicationBuilder
                .Create("1d18b3b0-251b-4714-a02a-9956cec86c2d")
                .WithClientSecret("not-a-real-secret")
                .Build();

            var result = await cca.AcquireTokenForClient(new[] { "User.Read" }).ExecuteAsync();

This all seems to work fine. What I am doing wrong?

[pmaytak]

@bgavrilMS Can you repro with 4.47.0? Maybe it's net5 specific issue?

[bgavrilMS]

No, I can't repro with 4.47.0 either when targetting net6-windows10.0.17763.0. Maybe the functions runtime has relaxed the requirement?

[Kavya-Gogula]

Hi @bgavrilMS ,

Are you testing it locally or did you push it to the cloud? It worked fine for me locally, But when I deploy to Azure Cloud, It is giving me the issue.

[bgavrilMS]

@Kavya-Gogula - I pushed it to a newly created Azure Function, not locally.

[pmaytak]

Looks like the MSAL has a dependency on Desktop runtime which is not deployed on the Azure Function VM and apparently there is no easy way to get it there.

The workaround for now is to publish using a self-contained azure function.

After further investigation - yes the self-contained option seems to be the only one working; other deployment combinations do not.

From offline discussion, the self-contained would like to be avoided because of it's disadvantages, like increased deployment size and need to patch manually.

We're waiting for a confirmation / more info from the Azure Functions team if it's possible to deploy on desktop runtime. Meanwhile, will continue work on Bogdan's public/confidential client split proposal.

[pmaytak]

Closing this as the separate MSAL package without Windows dependencies was provided. The investigation for the confidential/public client split will be tracked via #3900