I've already looked at the existing questions and made sure of the following:

  1. Only package.xml & destructiveChanges.xml are in the folder I'm trying to deploy.
  2. package.xml is empty outside of the version
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  1. The items in destructiveChanges.xml exist in the org I'm trying to delete them from.
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
  1. The folder is at the root of the project.
  2. Updated SFDX CLI

I've tried deploying it by the directory and by a zip of the directory. The same package.xml can be used to retrieve items from ORG via the VSC UI fine. I've only been able to find a bug from 2015 about this issue. Here's a picture of the attempts: Picture of VSC terminal attempting to deploy a destructive package by directory and then by zip

Is there anything I'm missing/overlooking? Did I format the command improperly? Any advice would be appreciated.

  • My understanding is that the complaint is about empty package.xml, so, I guess you cannot have a deployment to delete only, using the destructive changes xml. When I used it I always had something to deploy and some components to remove. – Jeferson Chaves May 13 at 17:36
  • @JefersonChaves other documentation I've read says that package.xml has to be empty but I'll try to add something random to it to see if it'll go. It'd be a bit upsetting if I have to deploy something random every time I want to clean up an apex class from production. – MadameEvil May 13 at 17:49
  • @JefersonChaves No, you can have an empty package.xml (given the example here). – sfdcfox May 13 at 17:49
  • 1
    Give me just a couple minutes while I do some testing, MadameEvil. I'll be right back with you. – sfdcfox May 13 at 17:59
  • @sfdcfox I feel that Metada API supports that (in fact remember using that with ANT) but sfdx mdapi is not honoring, yet: github.com/forcedotcom/cli/issues/188 – Jeferson Chaves May 13 at 18:42

This doesn't appear to be a problem in the latest version. I've tried the following:

sfdx force:mdapi:deploy -f manifest.zip -w 10


sfdx force:mdapi:deploy -d manifest/ -w 10

Both worked out well, and deleted the file in question. I also tried it with and without the normal XML header:

<?xml version="1.0" encoding="UTF-8"?>

Absolutely nothing I've tried has resulted in this error.

It might just be a problem with how PowerShell works, or maybe you have a space in your file path (e.g. C:\Users\Brian Fear\workspace has been known to cause problems in some commands/versions).

The only real suggestion I have is to try and move your project to a space without spaces, such as C:\workspace\myproject\.

  • Just to make sure since SFDX has lied to me about being updated before, this is the version I'm on sfdx-cli: Updating CLI... already on the latest version: 7.100.0-9d243d8 does that match up with the version you're running? – MadameEvil May 13 at 19:08
  • @MadameEvil sfdx-cli/7.101.0 win32-x64 node-v14.6.0 is what I'm on. It may be worth noting that I use the npm package npm install -g sfdx-cli and not the binary installer. I am aware that the bin install has had occasional issues, so I prefer the npm version instead. – sfdcfox May 13 at 19:13
  • I tried from bash shell instead of power shell to the same effect. I reinstalled via npm and still can't seem to get the version you're on. I wonder if it's a difference in the node versions causing issues? sfdx-cli/7.100.0 win32-x64 node-v16.0.0 I may try on a different machine with a fresh instal of CLI and see if that helps. – MadameEvil May 13 at 19:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.