Inconsistent DLL dependencies in the MS Graph Core DLL

[liebichw]

I am developing a plugin for a .NET program, i.e. a DLL which is dynamically loaded.
In this plugin, I want to use the MS Graph SDK (version 5.44.0), as this is the latest stable version of the MS Graph toolkit. MS Graph 5.44.0 depends on MS Graph Core 3.19.0

The problem I have is that MS Graph Core 3.19.0 has following conflicting dependencies:

• It depends directly on Microsoft.Kiota.Abstractions 1.7.9
• It also has a dependency on Microsoft.Kiota.Serialization.Form 1.1.3
  • This DLL in turn has a dependency on Microsoft.Kiota.Abstractions 1.7.8

So the full dependency tree has a dependency conflict on Microsoft.Kiota.Abstractions 1.7.8.
I know that this can be resolved by .NET "binding redirects", but I am developing a DLL, which is used as a plugin for the final application. This means that I have no direct control over the final application's configuration file (the .exec.config file) - so binding redirects do not solve this problem for my use case.

Expected behavior

A consistent set of DLL dependencies over the whole MS Graph Core dependency tree, without having to configure binding redirects.

Actual behavior

When running the final application without the binding redirects in the .exe.config file, I get an exception during startup ("Microsoft.Kiota.Abstractions, Version=1.7.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is not found - which is correct, the setup contains Microsoft.Kiota.Abstractions, Version=1.7.9.0).
Currently, the only way around that problem is to edit the final application's .exe.config file - which is a problem in production.

Steps to reproduce the behavior

Build a test application using MS Graph core.
Run the application without the binding redirects for the .exe.config file.

[andrueastman]

Thanks for raising this @liebichw

Any chance you can share a sample project that replicates the issue to help with validation of this?

[liebichw]

Thanks for raising this @liebichw

Any chance you can share a sample project that replicates the issue to help with validation of this?

This will be complex, because I do not develop the executable program which uses our library as a plugin - so I cannot be sure that my test solution would exactly reproduce the features of the final program. I can try to write a simple test program, but that will take some time.

[andrueastman]

I can try to write a simple test program, but that will take some time.

This will be highly appreciated.

[liebichw]

I can try to write a simple test program, but that will take some time.

This will be highly appreciated.

The problem here is that our code also uses MSAL, which introduces it's own incompatibilities - see AzureAD/microsoft-authentication-library-for-dotnet#4664

[liebichw]

I added a demo project (a stripped down version of one of our test programs) which shows the version conflict with MSAL. See https://github.com/liebichw/msgraph-dependency-problems-demo - the README.md of that project should document the solution and the problems encountered.

[andrueastman]

@liebichw We've made some improments here related to the changes at microsoft/kiota-http-dotnet#258

However, I still issues related to the Identity library which we do not own. Any chance you were able to resolve this using the updated packages.config as you suggested at AzureAD/microsoft-authentication-library-for-dotnet#4664 (comment)

One thing we could also try is to use a range dependency here. However, according to the docs 6.x version will no longer be receivin updates.

msgraph-sdk-dotnet-core/src/Microsoft.Graph.Core/Microsoft.Graph.Core.csproj

Line 60 in bf981e3

<PackageReference Include="Microsoft.IdentityModel.Protocols.OpenIdConnect" Version="7.6.0" />

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.