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
jStarkjStark 

Deleting using the migration tool

Hello everyone, I've been trying to do some research on deleting Salesforce components from my DE org using the migration tool but haven't found much for answers. My unanswered questions are:

 

1) How does the delete handle dependencies? If I have an Apex class as a controller for a Visualforce page, and I wish to delete both, can I have them both in the same destructiveChanges.xml file? Or if I just want to delete the class and leave the page, do I need to manually change the dependency first?

 

2) When I've tried to use a destructiveChanges.xml file, and follow the documentation here, I get errors saying "object missing from package.xml", but nowhere is it mentioned I need to have a package.xml for deleting nor what should be in it. Is this documented anywhere? I've even read on the discussion boards that I shouldn't have anything in the deployRoot but my 2 xml files.

 

3) If I want to clean out a DE org to use with a new project, can I list all of my classes, custom objects, etc, in any order in my destructiveChanges.xml file and have it be successfull? (Similar to #1). I am aware that if I try to delete something that isn't there, Ant will stop. This hinders team development quite a bit, and I know is listed on the idea boards. (I voted!)

 

I need to document and prove these processes out before we begin development. If anyone has done any of these things, or knows where more thorough documentation lies, please reply.

 

Thank you!

Jed

Best Answer chosen by Admin (Salesforce Developers) 
sfdcfoxsfdcfox

1) Dependencies are first simulated through a validation process (the same as the "Validate Deployment" option in Eclipse, for example). Basically, all components listed in deployRoot are run through a simulation, and the new environment is examined to make sure there are no unresolved dependencies after all changes have been simulated. This is a trivial task for the system, because all metadata is "tagged" to determine which features, fields, objects, etc that are required for it to work. It is not a "top-down" process; you do not need to concern yourself with the order of the elements in your destructiveChanges.xml or package.xml files. Even if pages/myPage.page references classes/myPageController.cls, and vise versa, they can be ordered any way you'd like, and both will successfully delete assuming no other dependencies exist that would prevent their removal (i.e. a custom tab). In the second scenario where you'd like to remove the class but keep the page, you must first update the page code so it no longer references the class, then you are free to delete the class, just as you would do in the UI.

 

2) Package.xml should exist for a successful deployment. If you are not adding or updating any items, you must still have a package.xml file. It would appear like this:

 

 

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>21.0</version>
</Package>

As you can see, you need a package.xml, even if just for version information. The data directory must not contain random folders or files (i.e. items that were previously in package.xml but then moved to destructiveChanges.xml. Do make sure you're including the above XML code verbatim if you have no new changes to deploy. The error "object missing from package.xml" states that there is something in your deployRoot that should not be there; if you are deleting an item, its manifest file must not appear in deployRoot.

 

3) According to the Spring '11 Migration guide, "missing" items in destructiveChanges.xml do not cause an error (Spring 11 Force.com Migration Tool Guide, page 18). So, if you did want to wipe a developer organization back to a sort of "default" state, you could do so by listing all code and fields you would like to remove by basically building the file (I'd really just use the Eclipse toolkit to make sure you get all the custom fields on standard objects), and then copying the entire package.xml content into a destructiveChanges.xml file.

 

 

I hope that this sufficiently answers the questions that you had about metadata deletion.

All Answers

sfdcfoxsfdcfox

1) Dependencies are first simulated through a validation process (the same as the "Validate Deployment" option in Eclipse, for example). Basically, all components listed in deployRoot are run through a simulation, and the new environment is examined to make sure there are no unresolved dependencies after all changes have been simulated. This is a trivial task for the system, because all metadata is "tagged" to determine which features, fields, objects, etc that are required for it to work. It is not a "top-down" process; you do not need to concern yourself with the order of the elements in your destructiveChanges.xml or package.xml files. Even if pages/myPage.page references classes/myPageController.cls, and vise versa, they can be ordered any way you'd like, and both will successfully delete assuming no other dependencies exist that would prevent their removal (i.e. a custom tab). In the second scenario where you'd like to remove the class but keep the page, you must first update the page code so it no longer references the class, then you are free to delete the class, just as you would do in the UI.

 

2) Package.xml should exist for a successful deployment. If you are not adding or updating any items, you must still have a package.xml file. It would appear like this:

 

 

<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
    <version>21.0</version>
</Package>

As you can see, you need a package.xml, even if just for version information. The data directory must not contain random folders or files (i.e. items that were previously in package.xml but then moved to destructiveChanges.xml. Do make sure you're including the above XML code verbatim if you have no new changes to deploy. The error "object missing from package.xml" states that there is something in your deployRoot that should not be there; if you are deleting an item, its manifest file must not appear in deployRoot.

 

3) According to the Spring '11 Migration guide, "missing" items in destructiveChanges.xml do not cause an error (Spring 11 Force.com Migration Tool Guide, page 18). So, if you did want to wipe a developer organization back to a sort of "default" state, you could do so by listing all code and fields you would like to remove by basically building the file (I'd really just use the Eclipse toolkit to make sure you get all the custom fields on standard objects), and then copying the entire package.xml content into a destructiveChanges.xml file.

 

 

I hope that this sufficiently answers the questions that you had about metadata deletion.

This was selected as the best answer
jStarkjStark

Thank you sfdcfox, that's exactly what I was looking for!

 

I'll run some tests later this morning or early afternoon, and accept the solution if more questions don't arise.

 

Thank you,

Jed

jStarkjStark

Tested and works like a charm.

 

Thanks again!