7. Where Publisher Reads Its Configuration

Local or central

Publisher configuration files live in one of two places:

• Local (the default): <Capital install>\publisher. Each workstation has its own copy.
• Central: a shared folder named by the system preference Paths > Publisher Config (System Preferences dialog, documented in the Capital Project Manager User Guide). When it is set, every client uses that folder, which is how Siemens expects a site to guarantee standard output.

If the preference is empty, Publisher falls back to the local folder.

A background PackagingTask can override both: its parameters file takes a <publisher_config_files path="..."> element. Siemens' own sample (doc\webservice\data\PackagingTask_Example.xml) gives the precedence as task parameter, then system preference, then <install>\publisher.

Who reads which copy

How the package is generated	Configuration used
Interactively on a client, preference empty	That client's local publisher folder
Interactively on a client, preference set	The central folder
Background Run / CIS task / web service	The configuration on the machine running CIS, never the client's

That last row is the one that bites. With local configuration, the same project can produce different packages depending on who pressed Generate and whether they ticked Background Run, and nothing in the output says which configuration was used.

Why this is hard to control out of the box

• The files are loose XML in a program folder. No history, no diff, no record of who changed what. A Capital update can overwrite them (pdf\html_to_fo.xsl on this install carries the 2608 update's date while its print\ twin does not).
• Several copies drift independently: every client's local folder, plus the CIS machine's.
• The dialog with "Configuration" in its name does not edit them. The Publisher Configuration Editor only manages diagnostic procedures.
• Some of the files hold credentials (server-config\, VIN\), so the folder cannot simply be pushed to a shared repository as-is.
• The shipped defaults are hidden in a zip (configurations.zip), so "what did we change from stock?" has no ready answer.

8. Controlling the Configuration Files proposes a way out.

What has been tested

EXERCISED 2026-09-28 (Capital 2512.2608, CIS on the same machine, a scratch project): a PackagingTask whose publisher_config_files named a folder holding only the configuration files (no runtime\) succeeded. The Service Explorer package it produced carries that folder's config.xml, NavigationPanel.xml and popup.xml under Resources/Config/. Deliberate markers in two of them came through, and a package built two days earlier from the stock folder carries the stock values. So:

• A central configuration folder does not need the 390 MB runtime, at least for Service Explorer.
• The folder a task names is the one whose files ship in the package.

Still open

• Whether the viewer applies the embedded files when the package is opened. The device tooltip in the package's devices.json did not change with a renamed navigation label, which is consistent with the viewer applying it at view time, but no package was opened to check.
• The System Preferences route: only the task parameter was exercised.
• Whether the preference is read at Capital start-up or at each generation.