OpenSite/Guides/Update OpenSite
Test a new development build without risking the only copy of your work.
- Stable identifier
opensite.help.update-opensite
Prerequisites
The old and replacement authorized packages, build identifiers, and backups.
Steps
Record the starting state
Record the application build, extensions and saved file format where known. Export/retain important scripts and plot images. Save engineering documents and make external copies.
Read compatibility notes
See OpenSite/Release notes and OpenSite/File formats. Format 4 readers accept formats 1–3; older builds do not read format 4. Saving an old file with a new writer is not a reversible “Save as old format” conversion.
Keep installations separate
Use a new package folder and matching runtimes/extensions. Do not overwrite a working development package file by file or mix Debug/Release DLLs.
Open a copy and check
Open a backup copy, inspect object counts/status, material units, expressions and unresolved references. Do not enable Python expressions until you trust their source. Re-run your own validation for work that matters.
Save to a new destination
Retain the old file/build until the new workflow is accepted. If a problem occurs, return to the untouched old file with its compatible old build, rather than editing JSON to reduce a format number.
Expected result
Both the old working data and a separately tested new-build copy remain available.
Limitations
There is no verified automatic updater or public installer migration workflow in this snapshot.
