⚙️ Azure Functions Core Tools: Version Mismatch

Azure Functions Core Tools: Why Your Version Is “Wrong” (and How to Fix It)

If you’ve worked with Azure Functions locally, chances are you’ve hit this:

func --version → 4.7.0

Even though you just installed:

npm install -g azure-functions-core-tools@4.9.0

Or Visual Studio shows something like:

Releases\4.125.0

…and now nothing makes sense.

This is not a bug.
This is a system design issue.

The problem: there is no single “source of truth”

Azure Functions Core Tools is distributed through multiple independent channels:

Each of these can install a different version, and all can coexist on the same machine.

The real root cause: PATH decides everything

No matter how many versions you install, Windows executes only one:

💡 The first func.exe found in your PATH

Example:

Get-Command func

Output:

C:\Program Files\Microsoft\Azure Functions Core Tools\func.exe (4.7.0)

👉 That’s it. That’s the one being used.

Everything else you installed is ignored.

The confusion multiplies: Visual Studio vs VS Code

VS Code

• Uses npm internally
• You see logs like:

npm install -g azure-functions-core-tools@4

✅ Transparent
⚠️ Not deterministic

Visual Studio

• Uses tooling feed (cli-feed-v4.json)
• Downloads silently to:

%LOCALAPPDATA%\AzureFunctionsTools\Releases\

✅ Feels “managed”
❌ No logging
❌ Not obvious

The most confusing part: fake version numbers

You might see:

C:\Users\...\AzureFunctionsTools\Releases\4.125.0

And expect:

func → 4.125.0

But instead:

func → 4.7.0

👉 Why?

Because:

• 4.125.0 = tooling bundle version
• 4.7.0 = actual CLI version

These are completely different version systems.

The full architecture (simplified)

flowchart TD

    A[Developer / VS Code] -->|Install / Update Core Tools| B[VS Code Azure Functions Extension]

    B -->|Executes| C[npm install -g azure-functions-core-tools@4]

    C -->|Pulls from| D[npm Registry]

    subgraph "Official Source of Truth"
        E["GitHub Releases<br/>(Azure Functions CLI)"]
    end

    subgraph "Tooling Orchestration"
        F["Tooling Feed<br/>(cli-feed-v4.json)"]
    end

    D -->|Installs| G[Local CLI Binary]
    E -->|Manual install| G
    F -->|"Guidance only<br/>(not installer)"| B

    G --> H[func --version]

    style E fill:#d0f0c0
    style F fill:#fce5cd
    style D fill:#ffd9d9
    style G fill:#cfe2f3

Real-world example (what happened)

A typical “broken” state:

• Installed via npm → expected 4.9.0 ✅
• Visual Studio installed → 4.125.0 bundle ✅
• Global MSI → 4.7.0 ❌

Result:

func --version → 4.7.0

👉 Because:

C:\Program Files\Microsoft\Azure Functions Core Tools\

wins in PATH.

The fix: make it deterministic

Step 1: find what is actually used

Get-Command func

Step 2: remove conflicting installs

• Uninstall MSI version (Program Files)
• Optionally:

npm uninstall -g azure-functions-core-tools
Remove-Item "$env:LOCALAPPDATA\AzureFunctionsTools" -Recurse -Force

Step 3: install a known-good version

👉 Recommended:

• Download from GitHub Releases
• Extract to:

C:\tools\func-4.9.0

Step 4: control PATH

setx PATH "C:\tools\func-4.9.0;%PATH%"

Step 5: verify

func --version

✅ Expected:

4.9.0

Key takeaways

🔹 1. Multiple install mechanisms = multiple truth sources

There is no unified versioning or installer.

🔹 2. Visual Studio and VS Code behave fundamentally differently

• VS Code → npm
• Visual Studio → tooling feed

🔹 3. PATH is the hidden decision engine

The version you run is not the version you installed.
It’s the version that wins PATH.

🔹 4. Tooling versions ≠ CLI versions

4.125.0 ≠ 4.12.5 ≠ 4.7.0

👉 They belong to different versioning layers.

Recommended enterprise approach

For regulated environments (e.g. banking):

✅ Install from GitHub releases
✅ Pin version
✅ Control PATH explicitly
✅ Avoid npm / IDE-managed installs

flowchart TD

    A["GitHub Releases<br/>(Source of Truth)"] -->|Download exact version| B[Controlled Install Folder]

    B -->|Explicit PATH| C[func.exe 4.x.x]

    C --> D[VS Code / CLI Usage]

    style A fill:#d0f0c0
    style B fill:#cfe2f3
    style C fill:#d9ead3

One-liner summary

Azure Functions Core Tools is not broken: it’s just multi-source, multi-version, and PATH-driven.