+ Start a Discussion

Instantiating an inner class - a salesforce bug

We have recently raised a case with Salesforce support because our app is failing on installation. From the little information I have got back from support it seems to be failing on instantiating an innerclass. See below:


UtilityClass.ResolvedTemplate resolvedTemplate = new UtilityClass.ResolvedTemplate();

 Where the inner class is as follows:


public with sharing class UtilityClass {
... ... // Inner classes public class ResolvedTemplate { public ResolvedTemplate () { Subject = ''; Body = ''; TemplateAttachments = new List<Attachment>(); } public string Subject { get; private set; } public string Body { get; private set; } public List<Attachment> TemplateAttachments { get; private set; } } ... ... }

The app installation failed with the following message:

Your requested install failed. Please try this again.
None of the data or setup information in your salesforce.com organization should have been affected by this error.
If this error persists, contact salesforce.com Support through your normal channels and reference number: 1043502955-384 (-1811678545)


We're told by support the following error occurred on installation:

[DeployMessage] FAILURE problem: Invalid type: UtilityClass.Reso= lvedTemplate fullName: EmailAuthorController id null fileName: classes/Emai= lAuthorController.cls lineNumber: 1070


My problem is this. We have been informed that our case has identified a bug but as yet they haven't told us what the bug is. We're working on trying to get that information. But in the meantime has anyone else experienced this bug possibly? Or experienced a similiar problem? Or have any useful information on this issue? At the moment our app is uninstallable and we're completely in the dark as to what the bug actually is. If I can get some information on the bug we can probably find a work around until the fix is available. I thought its worth a shot posting it on here just in case anyone else has experienced the same problem.







Haven't seen this issue before, are you deploying a package?


Over time I've learnt (the hard way) that it's usually better use top-level classes instead of inner classes. The lessons learnt include: testing is easier this way; reusability becomes less noisy; and there are some bugs when using inner classes (as you've seen).


If possible I'd promote your inner class to a top level class. The only other option is to go through you code with a fine-tooth comb, removing functionality and seeing if that fixes the issue.


Good luck,



Wes, thanks for your reply. I finally heard back from Salesforce support and it turns out the issue was that the class in question was using an Organization field named MonthlyPageViewsEntitlement. I was pointed to the API documentation which states: "To access this field Force.com Sites must be enabled for your organization". Sites had not been enabled in my DE org and the code worked without problem but when an install of the app was attempted into an org that did not have Sites enabled, the installation failed. This has now been identified as a bug.


It seems it wasn't anything to do with the instantiation of the inner class after all. But I take your point on using inner classes and I'll keep this in mind in future.






If you would like to instantiate an inner class, make sure it's defined using a public or global access modifier, then you could do it this way:

OuterClass.InnerClass instance = new OuterClass.InnerClass()