Apex Code Development You need to sign in to do that
Don't have an account?
ScottWells "Could not resolve field" error when adding VisualForce pages to managed package
We're in the process of readying our application for security review. The application was developed as an unmanaged package and was updated to be delivered as two managed packages, one that is an extension of the other. As we ready for review, we've installed the base managed package (essentially a shared library containing custom objects, Apex classes, etc., that will be used by multiple products) as a beta in the org where we're developing the extension managed package (the actual product). Now several of our VIsualForce pages that have always worked fine suddenly fail with errors like:
Could not resolve field 'CustomFieldName__c' from <apex:inputField> value binding '{!CustomFieldName__c}' in page productNamespace:visualForcePageName
I've searched a bit and found the following links with similar errors:
http://boards.developerforce.com/t5/Visualforce-Development/New-Build-on-NA1/m-p/89501
The first link documents an existing bug with VisualForce pages and managed packages, but we haven't actually uploaded a managed package with the custom objects, pages, or controllers that are failing in this case. At this point they're still unmanaged assets in an org, albeit one for which we have already registered a namespace.
The second link is about the user not having proper authorization for the object or fields, but this happens even when I'm logged in as a System Administrator.
The third and fourth links are about what seems to be a short-lived bug in the platform four years ago that only occurred when Developer Mode is on, but I don't have that on when this is happening and I would imagine that was fixed long ago given the age of the posts.
Based on this, I'm assuming that our problem is most closely related to the first link, but again technicaly the objects, pages, and controllers here aren't in a managed package yet. I'm hoping someone here has run into this problem and has a solution or workaround for it because this is gating our progress toward submission for security review.
For what it's worth, I've already tried qualifying the custom field names in the <apex:inputField> tags with the correct namespace, but they're automatically removed on save because, again, these pages are referencing custom objects in the same package and therefore shouldn't be namespaced.
Thanks in advance for any help you may be able to provide!
Hi Scott:
I am seeing the same issue as you describe. For us it happens only inside of salesforce, the page works fine on the customer portal.
Did you find a solution to this?
Thanks,
Matthias
Hi, Matthias. Unfortunately we have not found a solution, but we have found a workaround, albeit less than ideal.
In our case, the issue appears to be a shift in symbol visibility as execution moves from the extension managed package into the base managed package. Code in the extension package can "see" everything in that package plus everything global in the base package, but the reverse is not true, so when the execution context shifts to a class in the base package, you get this error when the call requires it to resolve a symbol from the extension package.
Just in case that was clear as mud(!), I'll give an example. Let's say you have a base package with namespace "basepkg" that contains an Apex utility class like:
global Object MetadataUtil.getFieldValue(SObject obj, String fieldName);
And in that same package you have a custom VisualForce component that renders the value for an SObject based on its describe metadata using the method above.
Now let's say you have an extension package with namespace "extpkg" that uses this custom VisualForce component from one of its VisualForce pages to render one of the custom objects also in that package:
<basepkg:Render obj="{!ExtensionPackageCustomObject__c}" fieldName="FieldOnExtPkgCustObj__c"/>
So basically when the page is rendered, it's rendered in the context of "extpkg", but when the custom component is rendered, the context shifts to "basepkg", seemingly including what symbols are visible, and therefore excluding access to the symbols from "extpkg". When MetaUtil.getFieldValue() is invoked, it has no idea what "extpkg__ExtensionPackageCustomObject__c" or "extpkg__FieldOnExtPkgCustObj__c" are and gives this error.
So again, that's my take on what's happening based on debugging this pretty extensively.
Our workaround has been to create a local copy of the VisualForce component (or page, template, etc.) that is included in the extension package as well as in the base package, and have usages of the custom component always be against the "local" version. The good news is that it appears that only the VisualForce page/component/template and, sometimes but not always, its controller class must be duplicated. In the example above, the utility class MetadataUtil does not need to be duplicated. I assume this is tightly related to the events that cause a change in execution context and symbol visibility, and perhaps it's primarily VisualForce markup that causes the issue and not direct Apex calls.
If you refactor things well when you hit the issues, you can really minimize the amount of duplication to the point that it's an annoyance but not really a big maintenance issue.
I hope this helps! Please let me know if my description doesn't make sense or doesn't apply to your particular instance of this issue!
Scott Wells