Practical guide
Edit existing WiX projects visually
Keep your existing WiX sources as the starting point. This workflow explains the difference between opening source files in the browser and working with a local .wixpie project, then shows what to check before saving changes.
1. Start from a known working copy
Commit or back up the installer before editing it. Identify the main .wxs source, included .wxi files, localisation .wxl files, payload paths and any WiX extensions or preprocessor variables used by the existing build.
Check the root XML namespace to identify the authoring family. WiX 3 uses http://schemas.microsoft.com/wix/2006/wi. WiX 5 uses http://wixtoolset.org/schemas/v4/wxs. Keep the current toolset while making your first visual edit so a toolset migration does not become part of the same change.
2. Open source files or a WixPie project
In a browser session, use File → Open files… and select the .wxs and .wxi sources you want to open. Select a compatible editor template when prompted. This gives you a document-editing workflow; it does not give the browser access to all files referenced by the installer.
With the Windows Local Agent and extension connected, File → Open Project… opens an existing .wixpie project. A .wixpie file records WixPie project settings; an existing .wixproj is an MSBuild project and is a different format. To bring MSBuild-based work into WixPie, start from its WiX source files and retain the original .wixproj and build configuration.
3. Make one change and inspect the XML
Start with a small change such as the package name or one editable file property. Use the available template pages and property controls, then compare the XML preview with the original source. Check that referenced IDs and file paths still point to the intended installer elements.
A template determines which operations have a visual view. An advanced custom action or extension-specific element may need a different compatible template or work in the source itself. Review the result rather than assuming every part of an arbitrary WiX project has a specialised visual editor.
4. Keep includes, localisation and build inputs together
For a local .wixpie project, keep its source and payload files within the authorised project directory. Preserve relative include and payload paths. Record required WiX extensions and preprocessor variables in the project settings and use the same requested toolset as the original installer.
A .wxl file contains localisation data rather than a normal installer source tree. Keep it with the build inputs. Browser source selection alone is not a replacement for the complete local build context, especially when a project depends on includes or paths outside its working folder.
5. Save, compare and rebuild
Use Download current file for an edited browser document, or the local project save commands when working through the agent. Review the version-control diff before replacing the original files. Check IDs, namespaces, references, include directives and the source file that owns each change.
Build with the original toolset and project configuration, or a matching configured agent project. Test the resulting installer in a separate Windows test environment, including upgrade and uninstall behaviour relevant to your change. A successful XML import is the start of that verification, not the end of an installer release.
Try the workflow in WixPie
Open the browser editor to explore a compatible template. For local files and MSI builds, follow the Local Agent and extension setup on the Downloads page.