Salesforce Managed Packages

This is one area of the Salesforce.com platform that I’m no fan of.

In short, you code a complex application and it’s beautiful. You marvel at the wonder of the sleek UI, the intelligent complexity of the code, and the comprehensive unit testing you’ve implemented. Now you wish to package your application up, advertise it briefly and have the customers pour in. Not so fast my friend.

Packaging can be a nightmare, and there are certain hurdles to this step that you won’t find officially documented. A few things you may want to consider:

  1. Never, I repeat never hardcode the name of a VisualForce page, class, or custom object anywhere in the code. This one is pretty standard in programming best practices, but it isn’t that obvious on the platform. This is because your code will work PRE-packaging. No checks are performed during packaging, but once(or should I say if) your package is deployed you will be privy to number of buggy areas should you not adhere to this rule. This is a side-effect of managed packaging. Once your code is moved into a managed package all class, objects, and package are automatically prefixed with the package namespace so any hardcoded references to these areas will cause the deployed application to fail.
  2. You must not qualify field names with the object name in SOQL queries otherwise you will receive errors stating that Salesforce does not understand the reference to said object. This is some sort of crazy inconsistent standard in the Salesforce system e.g. Select CObject.name From CObject Where CObject.id=.. will cause a managed packaged apex class to fail. You have to remove the field qualifiers so that the code reads thus, Select name From CObject Where id=.. This makes me a bit unhappy as it is not obvious, can waste a significant amount of time, and can make code less readable.
  3. You want to package what?! You have to pore through the documentation on packaging to find what is and isn’t packageable. The general rule I follow is, if it doesn’t explicitly say it’s packageable, then it probably isn’t. This can be painful, especially for areas such as profiles which are,let’s face it, a pain in the bottom(euphimism) to setup. Oh sure you can ‘map’ them onto an existing profile, but only a bit of them.
  4. Ever seen this exception before: MIXED_DML_OPERATION ? Neither had I until I started packaging. If you’re like me(6″ tall with green eyes) then you probably run all of your unit tests with Eclipse. Thinking my code and testing was flawless I begin the packaging process, and only then did I encounter this error. It seems that it only occurs within the browser testing environment and hotdang is it a pain in the bottom(again, euphimism). The error occurs because you try to perform DML on a ‘setup’ and ‘non-setup’ object in the same ‘context’. This is documented on page 483 201 subsection 6b paragraph 2 of a salesforce document somewhere on the interweb. Well sortof, because the documentation does not tie said error to said solution, and the solution has a bug. Figures. If you do come across this issue, the only real solution can be found on the discussion boards, and boy is it a doozy.
  5. Don’t even get me started on Sites packaging. Bleh.
  6. There is no way to log what happens once a package is installed. I had an experience in which an area of my application was failing only when installed from a managed package and had absolutely no way to tell at which point the code was failing. After some rather helpful communication with Salesforce I was told that there is a bug where in certain cases not all page/class/object references are correctly prefixed with the namespace, causing errors such as mine.

It’s not all gloom and doom ladies and gentlemen. Packaging is a relatively young area of the Salesforce.com offering, and all in all, once you have all the kinks worked out, you can install a package in a matter of hours.. a great improvement on the traditional months of deployment offered by most ERP and CRM systems.

13 thoughts on “Salesforce Managed Packages”

    • It is VERY tricky, and it will require a large amount of your effort for those pulling the package into their Orgs mostly because of packaging limitations; the biggest of these being you cannot package sites grrrr.. so short answer is yes, but with a large amount of post installation configuration e.g. create the site, setup profiles and if you use customer portal then it gets trickier. Good luck.

      Reply
      • The one thing I could never figure out how to do is use a separate template in a different org with a page that was part of a managed package. Have you gotten that to work?

        Reply
        • Never had the situation myself, but if I were to hazard a guess I’d say that the code inside of a package can’t peek out, but code outside the package can peek in. Just a guess though.

          Reply
  1. “I had an experience in which an area of my application was failing only when installed from a managed package and had absolutely no way to tell at which point the code was failing. After some rather helpful communication with Salesforce I was told that there is a bug where in certain cases not all page/class/object references are correctly prefixed with the namespace, causing errors such as mine.”

    I’m hitting the same bug, and I can’t find resolution on the forums… were you able to get this taken care of? I’m ready to go postal at SF headquarters. 🙂

    Reply
    • That’s still happening? They said they’d fixed it in a release last year some time and that did it for me. I’m afraid you’ll have to push it through your customer relationship person at SF. I feel your pain.

      Reply
      • I’ve got a juicy managed package that gets an internal server error on upload. No other message. Been w/ Tier 3 support for over a week w/ no response….

        Gar!

        Reply
      • Actually, it appears that it *wasn’t* the same bug. The namespace doesn’t get added to references that aren’t part of apex components, though it seems as if it was working fine before. Perhaps it’s a bug, or just a limitation that I haven’t seen yet in the docs. Either way, the solution for me was to set a public property in the constructor that referenced the StandardController.getRecord(); then I was able to access it from the installed managed package just fine.

        Kudos on a great blog, mate!

        Reply
  2. Good Info,just i want to clear out myself,as i have done managed packaging for my app ,and found many bugs once i installed in the test org.Now i want to change the field-type in the objects,its restricting me soo cant we change the field-type once we are done with the managed packaging.

    Please anyone suggest me the solution to get ride of this error..
    Its an ugent requirement.

    Reply

Leave a Comment