Resolving Shared Script Imports in 7.9-to-8.0 Projects

After saving the imported project and reopening the Designer, the shared scripts should appear under Scripting > Project Library > Shared. If they remain hidden, test the same export in a new project and investigate the script resource directory name, especially a case mismatch between script-python and Script-python.

What is the screen telling you?

The 7.9.10-to-8.0.1 import can accept shared scripts without displaying them in the Project Browser. The clearest symptom is a second import that presents an overwrite prompt even though no script is visible. A script originally named Script_1 may appear in that prompt as Unknown - Script_1.

That overwrite prompt changes the diagnosis. The import is not simply rejecting or omitting the resource. The destination already has an object corresponding to the script, but the Designer cannot represent it correctly in the browser. What the screen is telling you is that resource storage and browser presentation have fallen out of agreement.

Which recovery approach should you use?

Three approaches help separate a stale Designer view from a project-specific resource-layout problem. Start with the least invasive option.

The recommended first recovery is to import once, save, close the Designer, and reopen it. This sequence directly addressed the reproduced case where scripts inside a folder were accepted but did not appear immediately. Use the new-project test next because it provides a clean diagnostic boundary without altering the affected project’s resource layout.

Why can an imported script remain invisible?

The Designer builds the Project Browser from recognized project resources and their hierarchy. A shared-script import must therefore satisfy two conditions: the resource must exist, and its stored location must map to the hierarchy the Designer expects. The tag is right; the binding is wrong is a useful analogy here—the script data can be present while its browser placement is unresolved.

Foldered imports exposed this failure mode. When the imported script was inside a folder, the resource did not appear correctly in the Project Browser until the project was saved and the Designer was restarted. The restart forces a new read of the saved project resource tree instead of relying on the in-session representation created during import.

Directory-name capitalization creates a second path to the same symptom. Changing the script root from script-python to Script-python reproduced the behavior. Even where the operating system normally treats filename case permissively, application resource loaders can compare canonical directory names or use the name as a resource-type key. A case difference can leave the files on disk while preventing the expected browser node from being constructed.

How do you recover the hidden shared scripts?

1. Open the 8.0.1 project in the Designer and import the shared-script export created from 7.9.10.
2. Complete the import once. If an overwrite prompt appears for Unknown - Script_1, cancel unnecessary repeat imports; that prompt already demonstrates that the destination contains the resource.
3. Save the project so the imported resources are committed to the project resource tree.
4. Close the Designer completely. Closing only the import dialog or changing browser selections does not perform the required project reload.
5. Reopen the Designer and open the same project.
6. Expand Scripting > Project Library > Shared. Check both the shared root and any folder represented in the export.
7. Open each recovered script and confirm that its functions and nested folder placement match the 7.9.10 export.

If the branch still does not appear, create a new project and import the same global-script export there. Save, close, and reopen that Designer session as well. A successful import in the new project establishes that the export is usable and directs the investigation toward the original project’s resource hierarchy.

How do you diagnose a script-root naming problem?

Use the project directory on the server only as a diagnostic location. Compare the actual script-root name with the expected script-python spelling and capitalization. The problematic variant reproduced in testing was Script-python. Also confirm that a foldered shared-script export identifies a hierarchy equivalent to Script-python\shared in the import view.

Do not rename or move server-side project resources during production operation as an exploratory fix. Record the exact project version, import sequence, root-directory spelling, folder hierarchy, and overwrite text, then use the product’s official support channel if the clean-project comparison isolates the fault to the existing project.

How do you verify the repair?

Visibility alone is the first check, not the last. Verify resource identity and execution references before returning the migrated project to service.

1. Confirm that Scripting > Project Library > Shared remains visible after another normal Designer close and reopen.
2. Compare script names and folder placement against the 7.9.10 export. A script must not remain represented only as an Unknown overwrite item.
3. Open every migrated script and check that its source is present rather than an empty resource shell.
4. Inspect project components and event scripts that call the shared library. Resolve any broken script paths created by a changed folder hierarchy.
5. Run a controlled call to each migrated entry point and check the Designer console or gateway diagnostics for import, name-resolution, and runtime exceptions.

FAQ