Azure / Azure/azure-functions-core-tools
func start fails to load Microsoft.Azure.WebJobs.Extensions.EventGrid on a .NET 10 isolated app: Could not load file or assembly 'System.Net.Http, Version=8.0.0.0'
- Dominant language
- C#
- Stars
- 1.5k
- Forks
- 498
- Avg merge
- 5d 4h
- Merged PRs (30d)
- 15
Description
## Title
`func start` fails to load `Microsoft.Azure.WebJobs.Extensions.EventGrid` on a .NET 10 isolated app: `Could not load file or assembly 'System.Net.Http, Version=8.0.0.0'`
## What happened
A .NET 10 isolated-worker app containing an `[EventGridTrigger]` cannot be started with
`func start`. The host fails while configuring services and shuts down:
Possibly related to #5138, but distinct — that report names no assembly, doesn't involve Event Grid, and its workaround is installing .NET 8. This machine has 8.0.30 installed and it makes no difference, because the Core Tools host is self-contained on net10.0 and never looks for one.
```
Loading startup extension 'EventGrid'
Loaded extension 'EventGrid' (3.5.0.0)
...
Error configuring services in an external startup class.
Error configuring services in an external startup class. Microsoft.Azure.WebJobs.Extensions.EventGrid:
Could not load file or assembly 'System.Net.Http, Version=8.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
A host error has occurred during startup operation '...'.
Value cannot be null. (Parameter 'provider')
Host startup operation has been canceled
Stopping host...
Host shutdown completed.
```
**The same application deploys and runs correctly in Azure** on Flex Consumption — the Event
Grid function is indexed with its `eventGridTrigger` binding, which is only possible if the host
loaded the extension. So the extension itself is fine; the local host cannot load it.
## Expected
`func start` starts the host and indexes the Event Grid function, as Azure does.
## Repro
1. A .NET 10 isolated worker app (`net10.0`, `dotnet-isolated`).
2. Reference `Microsoft.Azure.Functions.Worker.Extensions.EventGrid` 3.6.0 — the current latest
stable, which brings host extension `Microsoft.Azure.WebJobs.Extensions.EventGrid` 3.5.0.
3. Add any `[Function]` with an `[EventGridTrigger] string` parameter.
4. `func start`.
Removing only the Event Grid package reference (and the trigger) makes the host start cleanly —
every HTTP route mapped, timer triggers indexed and scheduled, `Job host started`,
`Host lock lease acquired`. Nothing else about the app is involved.
**When reproducing, delete `bin` and `obj` first.** With `_FunctionsSkipCleanOutput=true` the
previously-built extension DLL survives in `bin/output/.azurefunctions/` and the host keeps
loading it, so the failure looks unchanged and appears to exonerate the package.
## Probable cause
The pieces, all read off the installed artefacts:
| | |
| --- | --- |
| Core Tools host | **self-contained on `net10.0`** — `func.runtimeconfig.json` has `"tfm": "net10.0"` and `includedFrameworks` `Microsoft.NETCore.App` 10.0.x, and the install directory ships its own `System.Net.Http.dll` (assembly version 10.0.0.0) |
| Event Grid host extension | **targets `net8.0`** — `.azurefunctions/function.deps.json` reports `runtimeTarget: .NETCoreApp,Version=v8.0` — and binds `System.Net.Http, Version=8.0.0.0` |
| How they meet | the host logs `Script Startup resetting load context with base path: '...\.azurefunctions'`, i.e. a **custom `AssemblyLoadContext`** |
A custom ALC does not get the automatic framework-assembly version unification the default
context provides, so the 8.0.0.0 reference has nothing to bind to in a self-contained 10.0.x
host. Having a .NET 8 runtime installed on the machine makes no difference, and did not here —
the host is self-contained, so it never looks for one.
## Versions
| | |
| --- | --- |
| Azure Functions Core Tools | **4.13.0 and 4.14.0** — both fail identically |
| `Microsoft.Azure.Functions.Worker` | 2.52.0 |
| `Microsoft.Azure.Functions.Worker.Sdk` | 2.1.0 |
| `Microsoft.Azure.Functions.Worker.Extensions.EventGrid` | 3.6.0 |
| `Microsoft.Azure.WebJobs.Extensions.EventGrid` (transitive, host-side) | 3.5.0 |
| Target framework | `net10.0`, `dotnet-isolated` |
| .NET SDK | 10.0.303 |
| Runtimes present | `Microsoft.NETCore.App` 10.0.11, 9.0.19, 8.0.30 |
| OS | Windows 11 |
| Deployed platform where it works | Linux Flex Consumption (FC1), `dotnet-isolated` 10.0 |
**Every one of those package versions is the current latest stable**, so this is not a project
holding an old dependency: the `net8.0`-targeted host extension is what ships today.
## Impact
Any .NET 10 isolated app with an Event Grid trigger cannot be run locally at all. The failure is
total — the host exits, so no function in the app is reachable, not just the Event Grid one.
Contributor guide
Research direction
Start by reproducing with `func start` after deleting `bin` and `obj`, then inspect `func.runtimeconfig.json` and `.azurefunctions/function.deps.json` alongside the custom assembly-load-context logs. Trace how the Core Tools host loads the Event Grid extension and its `System.Net.Http` dependency. Done means a net10.0 isolated app starts locally and indexes its Event Grid trigger.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure, csharp
- Domain
- backend, cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100