Use a CODESYS library object without the namespace prefix

Why the compiler insists on the prefix

A namespace gives the compiler one place to look. In TC.object, TC names the library namespace and object names a declaration inside it. The Qualified Access Only property, stored in the library's project metadata, makes that prefix mandatory for every object the library publishes.

Because the rule is compiled into the library, editing application code cannot remove it. The property belongs to the library project that defines TC. You change it there, rebuild, and hand the consuming project the new artifact. Task configuration, execution timing and controller hardware play no part in this error.

Symptoms and what each points to

• TC.object compiles and the bare object fails with a name-resolution error. The referenced library artifact carries Qualified Access Only. Make the property change in the library project.
• You deleted the value and the error is unchanged. The consuming project still compiles against the previous artifact. The dependency decides which build the compiler sees, so repoint it to the rebuilt library.
• The property is already absent in the library project. The artifact in use predates the current project settings, so rebuild and repoint.
• The bare object compiles but declaration navigation lands on a different declaration. A second declaration with the same short name is visible in scope. Keep the prefix on that one reference.
• Images went missing in the visualization after the project moved between machines. That is a file path problem, not a namespace one; handle it in HMI image path troubleshooting after migration.

Checks before you edit the property

• Open the library project, the one that defines TC, and confirm the value sits in its Properties table.
• Write down which artifact the consuming project references today, with its version or timestamp, so the rebuilt library is distinguishable from the old one.
• Search the application and its other referenced libraries for declarations sharing the short name you want to use.
• Build the consuming project once before the change and keep the diagnostics. Together with the build after the change, that gives you 2 comparable results.
• Save the library project first. A crash during the rebuild that damages the project file is a separate job, covered in Recover a corrupt CODESYS project file after a crash.

The fix, step by step

1. In the library project, open Project → Project Information.
2. In the Properties table, find the LanguageModelAttribute row and delete its Qualified Access Only value. Touch nothing else in the table. Allow 2 minutes.
3. Save the project and rebuild the library with your normal library build workflow; a small library build typically finishes in under 5 minutes.
4. Install the rebuilt artifact where the consuming project finds its libraries. If it ships as a package and the install stalls, clear it with the steps in Fix a CODESYS package stuck at upcoming installation.
5. In the consuming project, update the library dependency so it selects the rebuilt artifact.
6. Shorten exactly 1 reference, from TC.object to object, in its original code context.
7. Rebuild and read the diagnostics.

One reference first, then the rest. A single shortened reference separates a property problem from a name collision before you touch dozens of lines. When the test compiles and binds correctly, convert the remaining prefixes only where the short form reads better.

Working example: dropping the prefix on one object in the TC library

Inputs:

• Library name: TC, from your own library project.
• Working reference today: TC.object, the form that compiles.
• Blocking property: LanguageModelAttribute with the value Qualified Access Only, read in the library project's Properties table.
• References changed in the first pass: 1.
• Builds compared: 2, one before the change and one after.
• Time budget for the whole change: about 15 minutes, of which the property edit is 2 minutes and the rest is build time.

Rule in words: the prefix is mandatory only while the compiled artifact carries the property. Delete the value, rebuild, repoint the dependency, and the short name becomes legal wherever nothing else competes for it.

The arithmetic: 1 value deleted, 1 library rebuilt, 1 dependency repointed, 1 reference shortened, and 0 changes to object names, parameters or task configuration. The before build shows 1 name-resolution error on the bare name. The after build, about 15 minutes after you started, should show 0.

Decision: at 0 errors, with declaration navigation on the bare object landing inside the TC library, the change worked and you can shorten the remaining references. At 1 error persisting, the dependency still points at the old artifact; fix the reference selection before touching the property again.

Confirm the short name binds where you think

A clean build is the first check, and binding is the second. A short name can compile against a different declaration that happens to be visible in the same scope, so after the build:

• Use declaration navigation on the bare object and confirm it lands on the library declaration.
• Keep 1 qualified reference in the code as a comparison. It still compiles, and it documents which library owns the object.
• Read any new ambiguity or type diagnostics on their own; they name the competing declarations for you.
• Build the full application once the remaining references are converted.

The decision for each case

Recommendation: remove Qualified Access Only in libraries you build yourself, rebuild them, and shorten references one at a time where the short name is unambiguous; keep the TC. prefix in code that mixes libraries sharing short names.

• Your own library, prefixes are friction: make the property change, rebuild, repoint.
• A library you cannot rebuild, from a vendor or another team: keep writing the prefix, because the restriction ships inside their artifact.
• One short name that collides: keep the prefix on that reference even after the property change.
• The error persists after the change: repoint the dependency to the rebuilt artifact, then rebuild again.

For executable code, run your normal regression checks before deployment. This change touches source-level access only; leave task configuration and execution order alone.

Questions