Add “Version Settings” to the check-list…

I have some global code in a managed package that is used by some non-packaged (source) code in a customer’s org. An upgrade of the managed package broke the non-packaged code in a rather confusing way. The runtime error reported was:

System.TypeException: Invalid conversion from runtime type DefaultContactHistorySource to ContactHistorySource

where ContactHistorySource was a recently introduced managed package global interface and DefaultContactHistorySource was a recently introduced non-global implementation of that interface. Neither of these was used directly by the non-packaged code.

The work-around (discovered after many hours of failure) was to simply change the version number of the managed package that the non-packaged code depended on via the “Version Settings” tab. It appears that although ContactHistorySource and DefaultContactHistorySource were not being used directly, some version filtering was nevertheless being applied – perhaps because ContactHistorySource was global. Unfortunately the error that was reported didn’t offer much help in identifying the problem. This is also a rather nasty case of a managed package upgrade breaking existing code.

Other things to watch out for with managed packages are Add “Deployment Status” to the check-list… and Always double check that managed packages are deployed.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s