Skip to main content
Topics#IntegrationDaniel Ballinger's Question
Daniel Ballinger (Salesforce) asked in #Integration
May 22, 2015, 2:04 AM

The Tooling API isn't enforcing the package version dependency in the class/trigger metadata

I recently encountered an org with Apex classes and triggers that had dependencies on a third party managed package (http://salesforce.stackexchange.com/q/76791/102).

The Apex Classes and triggers had -meta.xml files like:

<?xml version="1.0" encoding="UTF-8"?>
<ApexTrigger xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>29.0</apiVersion>
    <packageVersions>
        <majorNumber>1</majorNumber>
        <minorNumber>1785</minorNumber>
        <namespace>loan</namespace>
    </packageVersions>
    <status>Active</status>
</ApexTrigger>

Note that it requires v1.1785 of the managed package with the loan namespace. The other triggers and classes had a range of minor versions, such as 1783, 1794 and 1795.

All of these were lower than the First Installed Version Number in the package details under installed packages.

As such, none of the affected Apex classes/triggers can be deployed/updated via the Metadata API without encountering the error:

triggers/foo.trigger-meta.xml -- Error: The specified Package Version number does not exist for that Package: loan, 1.1783

The affected triggers and classes can be successfully updated with the Tooling API, and hence the developer console.

This leaves a couple of questions:

  1. How did the org get into a state where there are Apex classes and triggers deployed that require a managed package version that isn't installed.
  2. Why isn't the Tooling API enforcing the managed package dependencies in the same way the metadata API is?
4 answers
Write an answer...
0/9000