function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
sparkysparky 

phantom package reference?

Check out this screenshot:

 http://screencast.com/t/w3WHvQ3cmSxJ

 

This is a class in our developer instance.  It's one we wrote.  It has nothing whatsoever to do with Vertical Response, except for the fact that VR is also installed in this instance. 

 

So why is the VR package and namespace showing up here?   It also shows up in the -meta file in eclipse.  This looks like a bug to me.  Is it?  

 

Thanks!

 

BTW, I have checked a little further and:

* the VR reference shows up on most of the classes in this developer instance (haven't yet taken the time to confirm if it's all of them, but it looks like it is)

* I checked a production instance that contains both this class and VR, and the reference was not present there.

 

 

 

 Edit: although I just noticed this, we have evidence that this behavior has been around since at least June, so it's not a Winter '10 thing.

Message Edited by sparky on 10-13-2009 04:43 PM
Message Edited by sparky on 10-13-2009 04:55 PM
Best Answer chosen by Admin (Salesforce Developers) 
A_SmithA_Smith

There is a slight difference between developer edition organizations and all other organizations.  Since developer edition organizations can be used to produce managed packages, we must record a version for all installed packages for every class you create in the org.  Of course if you aren't calling that package, then there should be no negative effect from doing this.  In all other editions, we only record the version for installed packages you are explicitly referencing.  

 

Thanks, 

All Answers

WesNolte__cWesNolte__c

Hey

 

I've had something similar before and opened a case with Salesforce.. it was a bug in that instance. As long as the file isn't a member of the package it shouldn't be inheriting the namespace.

 

Wes 

sparkysparky
Were they able to fix it for you?  Did they tell you how/why it happened?
A_SmithA_Smith

This is actually working as expected.  The version settings tab is a way for you to specify what version of the salesforce API and installed packages your class/trigger/page would use if/when it calls something from that package (aka API).  I know you aren't calling anything from the Vertical Response package, so right now that setting isn't doing really anything.  If you started to call it though, it would use that version to communicate with the installed package.

 

So for instance, if that package had an Apex method added in a version that is installed in your org, but later than the version you set in the version settings, then your class would not be able to call that particular method.  You'd have to adjust the version settings for that package on your class in order to access the new method.

 

Make sense? 

 

Thanks, 

sparkysparky

Thanks, Andrew.  That sort of makes sense.  But if that's the case, then why is it that in another SF instance that I'm looking at right now, there is no VR reference listed for any of the classes, even though VR is also installed in that instance?

 

That was part of the puzzle from the beginning - it's only in this instance that we seem to be getting these references.  Do developer instances work differently than production instances in this regard?

WesNolte__cWesNolte__c

I ended up creating a new Dev Org as they couldn't source the exact issue. Files that aren't in a package should not be prefixed with the namespace. If you're a Salesforce partner or have paid support log a case and escalate to your Salesforce connection.

 

To answer your question I've seen a number of inconsistencies between production and developer instances re: packaging. Some areas of testing for example behave very differently.

 

Good luck,

Wes

A_SmithA_Smith

There is a slight difference between developer edition organizations and all other organizations.  Since developer edition organizations can be used to produce managed packages, we must record a version for all installed packages for every class you create in the org.  Of course if you aren't calling that package, then there should be no negative effect from doing this.  In all other editions, we only record the version for installed packages you are explicitly referencing.  

 

Thanks, 

This was selected as the best answer