Resolving Ignition Designer 'no-project' on Every View

A Designer session on 8.1.48 connects, lists the project and its resource tree, then shows only no-project in the editor pane for every view, including a brand-new one. Other users open the same project on the same gateway, and the same user opens it on the development gateway. That pattern points at the path this one Designer takes to the gateway, not at the project or the view.

Which fixes fail on a local machine, and why?

Four fixes are the usual first moves. None of them touches the actual fault.

• Creating a fresh view. The editor pane fails before it loads any view resource. A new view fails identically because the view content is never the input that is wrong.
• Deleting the cache in the .ignition directory. The cache holds downloaded client libraries and launcher data. The project tree loaded correctly, so the cached data was not the problem. The cache rebuilds to the same state on the next connect.
• Downgrading the Designer Launcher (from 1.3.0-beta2 to 1.1.48 in this case). Both launcher versions send the same connection to the same address. If that address is wrong, the launcher version has no effect.
• Blaming antivirus. AV or Windows policy blocking the embedded browser library does produce an editor pane that will not render. That failure follows the PC and appears on every gateway, though. Here the same PC and user opened the project on the development gateway, so the local browser stack was not the primary fault.

The discriminating fact is that the same user, PC, launcher and project work against one gateway and fail against another. Compare the address the launcher uses in each case before touching anything else on the PC.

What is the actual cause: a load balancer address in the launcher?

The test-environment entry in the Designer Launcher pointed at a load balancer in front of the gateway, not at the gateway server. The address came from the host name at the start of a URL in a screenshot of a Perspective session in a browser. A Perspective session URL carries the public front-door name, which in a load-balanced environment is the balancer. Pasting it into the launcher connects without any error, which hides the mistake.

Replacing the entry with the true gateway server address fixed every view immediately. No project, cache, launcher or PC change was needed.

Why does the project tree load through a balancer but views fail?

The Designer does not use one request. It authenticates, pulls the project list and resource tree, then opens long-lived gateway sessions and, for Perspective views, loads the editor in an embedded Chromium-based browser that calls back to the gateway with a project context. A balancer can pass the first requests without trouble and still break later ones in three ways:

• It sends consecutive requests to different gateway nodes, so the editor page asks a node that has no design-time session for that Designer.
• It does not keep the persistent connections (websocket or long-lived HTTP) attached to the same backend.
• It rewrites or terminates the connection so the editor's callback to the gateway reaches a host or scheme the Designer session does not match.

In each case the editor page loads but cannot resolve a project, so it shows no-project. Loading the project list while views fail is exactly the split you would expect. A working tree is therefore not proof that the address is the gateway itself. Which of the three behaviours applies depends on the balancer configuration, so read it from the balancer's session-persistence and protocol settings.

How do I separate an address problem from a local browser problem?

Trace the signal chain from the address the launcher uses to what the editor pane renders. Each link has its own wrong-value symptom.

What is the step-by-step procedure to confirm and fix it?

1. Open the Designer Launcher and note the exact address on the test-gateway entry. Compare it with the address on the entry that works (development).
2. Ask the infrastructure owner whether a load balancer, reverse proxy or DNS alias sits in front of the test gateway. Get the host name or IP of the gateway server itself, not the front-door name.
3. Check where the address came from. If it was lifted from a browser URL for a Perspective session, it is the public entry point and may be the balancer.
4. Delete or edit the test entry and add a new one with the true gateway server address and port. Keep the original entry until the new one works.
5. Launch the Designer through the new entry, open the same project and open an existing view, then a new view.
6. If the view still shows no-project on the direct gateway address, move to the local browser check in the next section.

What if a Windows policy or AV blocks the embedded browser library?

If the fault follows the PC across gateways, treat the embedded browser as the suspect. The Designer unpacks a JxBrowser library on the local machine, and AV or a Windows policy can block that unpacking. Check the wrapper log for JxBrowser errors, then check the Windows Security protection history and the Defender logs. An empty protection history does not clear a group policy that blocks file creation silently, so the wrapper log is the reliable indicator.

When IT policy cannot be changed quickly, one field workaround is to copy the already-unpacked files for the matching JxBrowser version from a machine where unpacking succeeds into the local Designer setup. The version must match the one the installed Designer expects. Treat it as a stopgap and ask IT for a policy exception covering the Designer's unpack location, because a later Designer or launcher update can change the required version and break the copied files.

How do I confirm the fix and prevent a repeat?

• Confirm the path. The direct gateway address opens both an existing view and a freshly created view without no-project.
• Confirm editing. Change a component property, save the project, and reopen the view to verify the change persisted on the intended gateway.
• Confirm against another user. A colleague on the direct address sees the same saved change.
• Name entries clearly. Label launcher entries with the environment and role, for example gateway versus balancer, so a front-door name is not reused as a Designer target.
• Document addresses. Publish the direct gateway host names for each environment beside the browser URLs that users see. Browser URLs and Designer addresses differ whenever a balancer exists.