XML validation errors in Salesforce projects

[tzinm]

Summary

I’ve encountered a recurring issue in my Salesforce project when using VSCode. All *-meta.xml files are flagged with errors in the Problems panel.

The error shown is exactly the same as described in this previously closed issue: All XML files produce 'cvc-elt.1.a: Cannot find the declaration of element' in VSCode · Issue #3552

Steps To Reproduce:

The issue seems to originate from the vscode-xml extension which uses the Lemminx XML Language Server to provide XML support via the Language Server Protocol.

Expected result

No XML validation errors.

Actual result

XML validation errors like: cvc-elt.1.a: Cannot find the declaration of element 'CustomApplication'.

Show fixes suggest: Replace 'CustomApplication' with 'LightningComponentBundle'.

Possible Workarounds

While none of the following are perfect solutions, they at least suppress the validation errors, making it easier to focus on actual issues.

1. Disable validation for *-meta.xml files via xml.validation.filters

You can configure this in your settings.json (It is necessary to take into account the settings precedence):

"xml.validation.filters": [
  {
    "pattern": "**-meta.xml",
    "enabled": false
  }
]

This disables validation for any file ending in -meta.xml.

References: https://github.com/redhat-developer/vscode-xml/blob/main/docs/Validation.md#xmlvalidationfilters

2. Set xml.validation.schema.enabled to "onValidSchema"

This limits schema-based validation to cases where a valid xsi:schemaLocation or xsi:noNamespaceSchemaLocation is found.

References: https://github.com/redhat-developer/vscode-xml/blob/main/docs/Validation.md#xmlvalidationschemaenabled

3. Modify xmlns to use HTTPS
   Some suggest changing the namespace URI in xmlns from http to https. However, this is not reliable: SFDX rewrites the namespace on retrieve, which will undo this change.

Additional information

Salesforce Extension Version in VS Code: 64.1.0

Salesforce CLI Version: @salesforce/cli/2.92.7 wsl-x64 node-v22.15.0

OS and version: Debian 12 in WSL 2.4.13.0

VS Code version: version 1.101

Most recent version of the extensions where this was working: -

[svc-idee-bot]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[daphne-sfdc]

Hi @tzinm, Does the error go away when you change the language of the -meta.xml file to ForceSourceManifest?

From the status bar, click "XML"

Then from the command palette, select "ForceSourceManifest"

[tzinm]

Hi @daphne-sfdc!

Yes, the error goes away when I change the language to ForceSourceManifest.

[daphne-sfdc]

Yes that's good as a temporary workaround option, but there's one problem - the commands for manifests and metadata XML files are different. 😅

You see the deploy and retrieve from manifest commands instead of the regular deploy/retrieve commands.

We'll figure out a better way to get around this issue. Thanks for bringing it to our attention. 🙂

[git2gus]

This issue has been linked to a new work item: W-18831011

[laszlo-foldi-attentioncrm]

Hi @tzinm

I've faced this issue since forever too. The suggested quick fix is only temporarly, as it's still an XML file, and if you have your VSCode setup to auto detect language based on extensions, you'll need to manually change this in the settings to exclude the *-meta.xml pattern from the XML language detection.

You can add this to your global or workspace settings.

{
"files.associations": {
"*-meta.xml": "forcesourcemanifest"
}
}

This will prevent VSCode from manually changing back the language to XML, but leave all your other XMLs alone.

[tzinm]

You can add this to your global or workspace settings.

{ "files.associations": { "*-meta.xml": "forcesourcemanifest" } }

As @daphne-sfdc shown in the screenshot of her last reply, when we set the language to XML, the commands displayed don't match the regular deploy/retrieve commands.

As a temporary solution, I'll stick with the first option I mentioned in my initial comment:

Disable validation for *-meta.xml files via xml.validation.filters

You can configure this in your settings.json (It is necessary to take into account the settings precedence):

"xml.validation.filters": [
  {
    "pattern": "**-meta.xml",
    "enabled": false
  }
]