function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
Daniel BallingerDaniel Ballinger 

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.
Managed package first installed version less than required version.

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?
Daniel BallingerDaniel Ballinger
I've encountered this again in another org. I think it is related to refreshing a sandbox. The steps would be something like:
  1. Install managed package version 1 in a sandbox.
  2. Perform development against managed package version 1.0 in sandbox. Creates Apex classes with a packageVersion with majorNumber 1 and minorNumber 0
  3. Create a new version 1.1 of the managed package.
  4. Install v1.1 of the managed package in production.
  5. Deploy the Apex class with the dependency on v1.0 to production.
  6. Refresh the sandbox from production. The Sandbox will get productions "First Installed Version Number" of 1.1.
  7. Subsequent attempts to update the Apex class in the sandbox will fail with
The specified Package Version number does not exist for that Package: Namespace, 1.0

So it would appear the problem started with the change set allowing the Apex class with the dependancy on v1.0 being deployed to produciton. That, or the "First Installed Version Number" in the sandbox isn't correct after refreshing it from production.
ShashankShashank (Salesforce Developers) 
Hi Daniel,

Could you please email me at ssrivatsavaya@salesforce.com with the org Id, login access, and exact replication steps in detail so that I can investigate on this issue?

Thanks,
Shashank
ShashankShashank (Salesforce Developers) 
Please see this known issue: https://success.salesforce.com/issues_view?id=a1p300000008XrsAAE
Daniel BallingerDaniel Ballinger

Hi Shashank,

That is similar. However, I think it is distinct from the issue I’m encountering. That known issue is around version checking for extension packages not being enforced during installation but then preventing subsequent deployment to another org.
 
My issue is that that the deployment to production is not being prevented when the apex classes have a dependency on a managed package version that isn’t available in the target org. Subsequent refreshes of sandbox orgs from production then create an inconsistent state where the apex classes can’t be updated via the metadata api.

Thanks,

Daniel