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.