Is there a way to hard-delete custom objects using the Force.com migration tool? When you deploy a DestructiveChanges payload, the objects are "soft-deleted" and not erased from the platform. This creates an issue when you subsequently try to push back in those objects.
Is there a way to do this?
I did encounter the dreaded "An unknown exception has occurred" too; but it was when using related lookup filters which used reference fields to lookup to a 3rd object. The dependency checker in salesforce doenst seem to look beyound 1 level deep. I logged a case with them, which they accepted as an issue, are are trying to resolve.
My solution (i've not yet implemented) was to add logic in the scripts first step that edits page layouts and deploys them back prior to delete, to also clean up various things from .object files first too (related lookup filters, and perhaps rollup summary fields under simliar conditions). Then they undeployment should be allowed, this in principle though is very tricky due to the code possibly referencing these fields. So it thus is also necerssary to edit every class, trigger, page and empty them out and deploy too. I have some logic to do this, and will try and update the git hub repo soon.
Eric Wilcox (developer of the undeploy script)
Workflow Rules have their own component type, as do Workflow Tasks, try this...
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Custom_Object__c.MyRule</members>
<name>WorkflowRule</name>
</types>
<version>26.0</version>
</Package>
You may have to do this for WorkflowTask's as well.
Follow up question via comment below...
The WorkflowRule and WorkflowTask appear in the package folder structure as follows. They basically use the /workflows folder and the .workflow file extension. You can read more about them in the Metadata API developers guide here.
P.S. If your interested in the above code it is here.
Best Answer
A hidden gem in the Metadata API deploy operation takes a DeployOptions structure, in it is a purgeOnDelete setting that will do what you need!
Extending Salesforce Migration Tool to Support PurgeOnDelete.. For some reason this excellent feature has still not been exposed by the Salesforce Migration Tools via the sf:deploy Ant Task. However with a bit of Java skills you can create a new deploy Ant Task by extending the current one, to expose the attribute to your Ant build scripts, for example...
Prebuilt ant-salesforce.jar with deploypurge in it. You can download a modified ant-salesforce.jar here from the FinancialForce.com Developers Github repo (be warned this is API v22.0, though you can use it to deploy code at any version).
Building your own extended ant-salesforce.jar. If you want rebuild a new version, then you need to download this Java class, compile it, unzip the ant-salesforce.jar (rename .jar to .zip), put it in and zip it back up again and your all set!