Beware Duplicate Custom View File Conflicts in Sitefinity

When working with Sitefinity CMS, custom view files for form elements can be a powerful way to tailor your user experience. However, we recently encountered an issue with duplicate custom view files that caused SiteSync to fail. This post shares our experience and provides guidance to help you avoid similar problems.

The Recommended Approach vs. Reality

Sitefinity's documentation suggests creating custom view files by copying the default view and placing it in:

ResourcePackages/Bootstrap/Mvc/Views/<ELEMENT_NAME>/Default.CustomName.cshtml

(See: https://www.progress.com/documentation/sitefinity-cms/create-and-edit-widget-templates-mvc )

However, we discovered that Sitefinity actually looks for these files in multiple locations, with a fallback hierarchy. The most reliable location is:

~/Mvc/Views/<ELEMENT_NAME>/Default.CustomName.cshtml

This is crucial because custom views placed in the ResourcePackages folder structure may not be detected as expected when selecting the view for the element in the CMS Form Element editor screen, leading to confusion when your customisations don't appear.

The SiteSync Breaking Point

The real problem emerged during a SiteSync operation between our staging and production environments. We had inadvertently created the same custom view file in both locations:

• In the ResourcePackages path (where documentation suggested)
• In the root Mvc folder (where it actually worked)

When SiteSync attempted to synchronize content using this custom view, it encountered two identical files and couldn't determine which one to use for creating the form element on the target environment. This caused the sync process to fail completely with a somewhat cryptic message:

Looking in the Sitefinity logs we have output to Seq, they are not particularly insightful either:

How This Happened

The duplicate files situation wasn't immediately obvious because:

1. Deployment processes don't automatically delete old files
2. A custom view placed in the ResourcePackages folder doesn't produce errors - it's simply ignored
3. When the correctly-placed file was deployed to the root Mvc folder, the incorrect file in ResourcePackages remained

Only by examining our server through Kudu did we discover the duplicate files causing the conflict.

Preventing This Issue

To avoid similar problems:

1. Use the correct path: Always place custom view files in ~/Mvc/Views/<ELEMENT_NAME>/Default.CustomName.cshtml
2. Clean up during deployments: Ensure your deployment process removes obsolete files
3. Check for duplicates: Before SiteSync operations, verify you don't have the same custom view defined in multiple locations
4. Inspect via Kudu: When troubleshooting SiteSync issues, examine your file structure in Kudu to identify potential conflicts

Conclusion

While Sitefinity's documentation suggests placing custom views in the ResourcePackages folder, for reliable operation, the root Mvc folder is the preferred location. Always ensure you don't have duplicate custom view files, as they can cause SiteSync operations to fail in non-obvious ways.

This seemingly small implementation detail can save you significant troubleshooting time when managing Sitefinity environments with SiteSync.