If you’re publishing AL apps from VS Code to a Business Central Docker container and hitting this error:

[2026-06-19 11:07:27.48] The request for path /BC/dev/apps?tenant=default&SchemaUpdateMode=forcesync&ForceUpgrade=true&DependencyPublishingOption=default failed with code UnprocessableEntity. Reason: Publishing failed due to 'Specified part does not exist in the package'. The original extensions have been restored.

You’ve already verified: compilation succeeded, no dependency issues in the build output, warnings are minimal. Yet publishing fails silently. This is maddening because the error message gives you nothing to work with.

Initial Troubleshooting (The Wrong Path)

My first instinct was to blame Business Central container versioning. I checked app dependencies, reviewed event logs in the container, verified app.json configurations. Everything looked correct. The apps compiled cleanly in VS Code without a single error or warning. Dependencies resolved properly. Yet the runtime rejected them during publishing.

Hours of digging through Docker event logs later, I finally checked something obvious: the AL Language extension version running in VS Code.

The Real Issue: Compiler Adding Packages Not Supported by Runtime

Here’s what was actually happening:

I was running AL Language extension v18.0.x (prerelease) while my Docker container was Business Central 28.1 running runtime 17.0.x. The newer AL compiler in the v18.0.x extension includes features and compiler optimizations that pack additional metadata or package structures into the compiled .app files. These new internal packages don’t exist in runtime 17.0.x.

When the BC runtime tried to deserialize and validate the compiled app package, it couldn’t find these new internal components. The “Specified part does not exist in the package” error is the runtime’s way of saying: “I found references to package components that aren’t in my schema.”

The apps compiled successfully because VS Code’s AL compiler just packaged everything according to its current version. But when the older runtime tried to unpack and process those same apps, the version mismatch caused deserialization to fail.

The Fix

Downgrade your AL Language extension to match the runtime version in your Docker container. Check your container’s BC version, identify the corresponding runtime version, then pin your AL extension to a compatible version. Recompile and republish.

In my case: AL extension downgraded to v17.x to match runtime 17.0.x on BC 28.1. Problem solved immediately.

End Note: Why This Isn’t Obvious

Business Central’s versioning scheme doesn’t help here. BC version 28 is marketed as “2026 Release Wave 1” but runs on runtime 17.0.x. There’s no intuitive numerical relationship. Without explicitly checking your container’s runtime version, you won’t know which extension version to target. Microsoft could improve this by making version relationships explicit in documentation or extension metadata.

TL;DR: Newer AL compiler versions pack features unsupported by older runtimes. Match your extension version to your runtime version, recompile, and republish.