Issue with Teams Bot: Incoming Call Event Not Reaching Bot (App-Hosted Media Sample)

Thanks for reaching out.

You’re hitting classic assembly binding/version skew on .NET Framework: the app compiles against one set of packages but loads different versions at runtime, which triggers errors such as:

System.IO.FileLoadException (0x80131040) Could not load file or assembly 'Microsoft.Graph.Core, Version=2.0.13.0... The located assembly's manifest definition does not match the assembly reference.
This typically cascades to System.Text.Json, System.Memory, System.Buffers, etc.

Below is a proven setup to eliminate these errors for the LocalMediaSamples (application‑hosted media) on Windows Server + .NET Framework.

1. Pin a compatible NuGet package set (no mixing)

Ensure all Graph Communications SDK packages and the Skype media library are version‑aligned. Install/update explicitly from Package Manager Console:
bot2.txt

2. Retarget to .NET Framework 4.8 (recommended)

You can stay on 4.7.2, but 4.8 reduces binding friction and enables modern TLS defaults.

• Project → Properties → Target framework: .NET Framework 4.8
• Install the .NET Framework 4.8 Developer Pack if missing.
  bot1.txt

3. Enable auto binding redirects and add an explicit App.config

• Project → Properties → Application → check Auto‑generate binding redirects.
• Add an App.config with explicit redirects for the assemblies that drift most often.

**Starter App.config (adjust newVersion to your installed versions):
**
4) Clean out stale binaries and caches
dotnet nuget locals all --clear
Reopen the solution → Restore → **Rebuild

**.5) Verify with Fusion Log Viewer (Fuslogvw.exe)

Use Fusion logs to see exactly which version the CLR is trying to load and where it probes:

1. Run Fuslogvw.exe.
2. Enable Log Failures and Bindings; set a custom log path.
3. Reproduce once; open the latest log entry.
4. Confirm your App.config redirects match the requested versions shown in the log.

6) Remove conflicting references

• Standardize on packages.config (or PackageReference)—avoid mixing across projects.
• Ensure all projects reference the same versions of Microsoft.Graph* and System.* packages.
• Make the bot executable the startup project (binding redirects apply to the entry appdomain).

7) Optional: fresh re‑setup (fastest if you’ve iterated a lot)

1. Clone the sample fresh.
2. Retarget to .NET Framework 4.8.
3. Install the package set from step 1.
4. Add the App.config above.
5. Restore → Rebuild → Run; use Fusion logs only if an error remains.

Why this works

  1. The Calling/Media SDKs were compiled against **specific** Graph client versions; mixing newer/older packages breaks assembly identity.
  
     1. `System.Text.Json` on .NET Framework pulls `System.Memory`, `Buffers`, `Unsafe` via netstandard—these must be **version‑compatible** and redirected to **one** resolved version at runtime.  
     Please let us know if you require any further assistance, we’re happy to help.
     
     If you found this information useful, kindly mark this as "Accept Answer".
     

Thank you. My problem is that the solution builds successfully but then gives one runtime error after another such as "System.IO.FileLoadException

HResult=0x80131040

Message=Could not load file or assembly 'Microsoft.Graph.Core, Version=2.0.13.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Source=Microsoft.Graph.Communications.Common". If I resolve this somehow then I get similar error for microsoft.text.json and then system.memory. Hence I feel that there should be better way to handle it. Is there any documentation on how to setup the project properly and get rid of these errors? Thanks again.

Thank you for reaching out.

If your bot builds successfully but does not receive the incoming call event, it usually means the bot is not reachable for signaling or media. Here are the main things to check:

Update SDK – Make sure you are using the latest Microsoft Graph Communications SDK. Older versions can stop working because APIs change.

Public IP and Ports – The VM hosting the bot must have a public IPv4 address and allow inbound traffic. Required ports:

• HTTPS signaling: 443
  • Media: UDP ports for ICE/STUN/TURN (commonly 3478–3481) and RTP streams.
  Firewall and NAT Rules – Confirm that firewall rules and NAT settings allow media traffic. If ports are blocked, the bot will not join the call. Bot Registration – Verify the App ID and secret, and ensure calling permissions are granted in Azure AD. The bot and Teams user must be in the same tenant. Logs and Correlation IDs – Check runtime logs for ICE negotiation or Graph API errors. These often show why the call event is not triggered.

Windows Server 2019 is supported, so the environment is fine. Most issues come from networking or outdated SDK. After fixing these, test with the latest GitHub sample.

Please let us know if you require any further assistance, we’re happy to help.

If you found this information useful, kindly mark this as "Accept Answer".