Your AppSource dependency is a live product and AVS0118 is the proof

Most multi-app BC publishers have a "Core", a shared library app that the customer-facing apps depend on. And most carry a quiet, wrong mental model of it: that Core is a private dependency, bundled into the consumer apps at build time, an implementation detail customers never see.

Then you hit AVS0118 during AppSource validation, the version you need "isn't available," and the wrong mental model sends you debugging the wrong app for a day. Here is the thesis that saves you that day: Core is not a private dependency at all, it is its own independently live AppSource offer and AVS0118 is the proof.

What AVS0118 is actually telling you

AVS0118 fires when a consumer app's release requires a Core version that is not yet live in AppSource, while an older Core version is live. The validator is comparing your dependency requirement against what is publicly available and finding a gap.

That comparison only makes sense if Core is a thing AppSource knows about as a published, versioned, independently live offer. Which it is.

The reality: Core is its own live offer

Here is the part that reorganizes everything once you accept it. With the bundling behavior turned off, which, if you have ever seen AVS0118, yours is, your release does not package its dependencies inside it. Core is therefore:

• a standalone offer that is live in AppSource in its own right,
• something customers actually have installed (so you cannot delete or unpublish it casually),
• versioned and validated on its own timeline, separate from the consumer apps.

The NuGet-style feed that your build pulls symbols from is not AppSource. The feed only feeds the build. Confusing the two is the root of most Core-related theories that turn out wrong: "it's a draft offer," "the feed is stale," "skip it." None of those is the mechanism.

So the fix is not where the error is

This is the practical payoff. When the consumer release throws AVS0118, the instinct is to change the consumer app, bump something, repackage, fiddle with the dependency line. Wrong app.

The required Core version has to go live first. You make Core's new version available in AppSource (and there is likely no Core pipeline doing this for you, it is a manual Partner Center step) and then you re-submit the consumer release that depends on it. The dependency must exist publicly before the thing depending on it can pass.

How to tell which mode you are in

All of this hinges on one behavior: whether your release bundles its dependencies or not. If dependencies were packaged inside each consumer app, Core would be an invisible implementation detail and AVS0118 could never fire. The fact that it fires tells you bundling is off, your consumer apps ship without Core inside them, so Core has to exist independently and publicly.

The practical tell: if you have ever seen AVS0118, you are in the non-bundling world, full stop. You do not need to go spelunking through build settings to confirm it, the error is the confirmation. From there, the model in this post is the one that holds.

The dead ends I chased first

I did not arrive at "Core is a live product" cleanly. I arrived at it after a sequence of plausible, wrong theories, each of which wasted time because it located the problem in the wrong place. If you are mid-AVS0118 right now, you have probably tried at least one of these:

• "The feed is stale." Tempting, because the feed is where the build gets symbols. But the feed only feeds the build; it has nothing to do with what AppSource validation checks. Re-pushing to the feed does nothing for AVS0118.
• "Core is just a draft offer I need to finish." No, it is a live offer with a version behind. The action is to publish the new version, not to complete a draft.
• "I'll skip the Core dependency / loosen the version." This treats the symptom and ships a consumer app that depends on a Core your customers may not have. It is how you turn a release-ordering problem into a runtime problem in production.

Every one of these put the fix in the consumer app or the feed. The fix was always in AppSource, on Core. Naming the wrong theories is useful precisely because they are the ones your instincts will reach for.

What this changes about how you work

Three habits fall out of getting the model right:

• Version Core deliberately and first. It leads; the consumers follow. A version-collision problem is solved by moving Core forward, not by pinning or hacking the consumer.
• Never treat Core as deletable. Customers depend on the live offer. It is a product with users, not a build artifact.
• Keep "feed" and "AppSource" separate in your head. The feed satisfies the compiler. Only AppSource satisfies AVS0118.

The error message is terse and the mechanism is invisible, which is why the folklore around it is so wrong. But it is consistent: AVS0118 is AppSource telling you a live product you depend on is behind. Treat Core as the product it is and the error stops being mysterious, it becomes a release-ordering checklist.

Part one of a short series on the parts of AppSource that only make sense once you have been burned by them. Next: the breaking changes you cannot see coming.