Fix CODESYS C0180 ambiguous namespace library errors

What a C0180 actually says

The error reference for C0180 in your environment's documentation defines the code as the namespace of a library not being unique, with the correction made on the library entry in its Properties dialog. The build output says the same thing twice per namespace. One line names a pinned version, for example CmpEventMgr, 3.5.8.0 (System). The next names the same library as CmpEventMgr, * (System).

The * entry is a placeholder. It carries no version of its own and resolves to a copy that the library repository of that install supplies. The compiler is therefore holding two definitions of one namespace, a pinned copy and a placeholder-resolved copy, and it reports the namespace as ambiguous. In this fault the four namespaces are system libraries, CmpEventMgr, Component Manager, CmpApp and CmpIecTask. An install normally pulls those in implicitly, and their pinned entries arrive when a project is written or re-saved under a different install generation.

Symptoms and what each line points to

Read the output from the top. Every line after the first C0180 group is downstream of it.

• C0180 on CMPEVENTMGR, COMPONENT_MANAGER, CMPAPP and CMPIECTASK, each namespace reported with its pinned version and again with *: four system libraries each resolving twice.
• C0136 : ambigous use of name 'ICmpEventCallback', spelled as the compiler prints it, followed by two C0181 information lines naming cmpeventmgr, 3.5.14.0 and cmpeventmgr, 3.5.8.0: the interface exists in two resolved copies of the same library, and the C0181 lines hand you both versions.
• C0136 : ambigous use of name 'EventParam' reported under Task Configuration: the same collision, seen from the code the task configuration generates.
• C0032 : Cannot convert type '__SYSTEMEVENTHANDLERFB' to type 'ICmpEventCallback(cmpeventmgr, 3.5.14.0 (system))': the conversion target names the 3.5.14.0 copy, so the compiler is holding two CmpEventMgr generations at once. Other controller families document this code on its own terms, and resolving the C0136, C0046 and C0032 error family is one such walkthrough; in this output the code is the tail of the duplicate namespace and needs no edit of its own.
• A build that fails after a project was archived under one install, opened under another, and taken back: the cross-version round trip is the usual route by which pinned entries and a newer repository copy meet.

Example: one build output, four duplicate pairs

Take the 14-error build of an application compiled under an SP9 Patch 1 based wrapper install, a vendor's own environment built on CODESYS 3.5 SP9 Patch 1. The PC carries four installs side by side: that wrapper, a standard SP9 Patch 1, SP14 Patch 3 and SP15. The project was archived from the wrapper, opened and saved under SP15, then reverted to a revision saved before the archive, and the build still fails on the wrapper install.

Count namespaces and entry types, not message lines; the list repeats some pairs. C0180 names four namespaces, and each namespace is defined by two entries, a pinned version and a * placeholder: 4 x 2 = 8 competing definitions, so 4 pinned entries to delete and 4 placeholders to keep. The pinned versions are 3.5.8.0 for CmpEventMgr and 3.5.9.0 for the other three. The C0136 lines name cmpeventmgr, 3.5.14.0 next to the pinned 3.5.8.0, a generation newer than either pinned entry: that 3.5.14.0 copy is what the placeholder resolved to on this machine. The output never prints which versions the other three placeholders took, and it does not need to; the fix is the same for all four.

The result to expect after about 10 minutes of edits and one rebuild: 0 C0180 lines on the next build, 2 C0136 names each resolving to a single copy, 1 C0032 conversion succeeding against one cmpeventmgr, and no edit inside Task Configuration. 4 deletions, 1 rebuild, 0 task edits: the compiler's 14-error report drops to a clean build in under 15 minutes of work at the PC.

Why the fault follows the file and the machine

Two inputs decide what the Library Manager resolves: the library references stored inside the project file, and the library repository that the running install reads. The cross-version round trip touches both.

Project side. Saving a project under a newer install can leave pinned system library entries beside the placeholders, and a revision saved after such a session carries them even after you revert. That is why the errors appear in the original project on the wrapper install: the pinned entries are inside the file.

Repository side. A 3.5.14.0 copy present on this PC and absent on the second PC makes the * placeholder resolve to a second generation. On the second PC the same file builds clean, which says its repository resolves that placeholder to the same generation as the pinned entry: one effective definition, no collision, no errors.

Keep the original project file untouched and work on a copy. A kept copy is also where you start when a file goes past a compile error and will not open at all; the steps to recover a corrupt CODESYS project file assume you have one.

The build test on a second PC

Copy the failing project file to the second PC, the one that never saw an archive of this project, and build it there without changing anything. The test costs one file copy and one build of a few minutes, and it names the half you need to fix.

• The same C0180 pairs appear there: the duplicates travel in the file. Run the deletion procedure in the next section.
• The project builds clean there: the pairs are not colliding on that machine's repository, so the difference is the repository on this one. Skip to the repository step in the section after the procedure.

Remove the duplicate entries

Work on a copy of the project, never on the only file.

1. Close the project and copy the project file to a separate folder. Gate: the copy opens and reports the same 14 errors.
2. Open the Library Manager of the application in the copy and locate CmpEventMgr, Component Manager, CmpApp and CmpIecTask. Gate: each is listed twice, once with a pinned version and once as *, matching the build output.
3. Open each pinned entry's Properties and note its version: 3.5.8.0 for CmpEventMgr, 3.5.9.0 for the other three. Gate: the versions you recorded match the C0180 text before anything is deleted.
4. Delete the pinned entry in each of the four pairs and keep the * placeholder. Gate: the Library Manager lists each of the four libraries once.
5. Run Build > Clean all, then Build > Rebuild. Gate: the C0180 groups are gone. A remaining C0136 on ICmpEventCallback means a second CmpEventMgr copy still resolves; go to the repository step in the next section.
6. Open Task Configuration and change nothing there. Gate: the C0032 on __SYSTEMEVENTHANDLERFB has gone on its own.

Download the rebuilt application to the controller only after Rebuild reports zero errors; a binary linked against the wrong library generation is not a verified program.

When the pairs come back

If the same pinned-plus-placeholder pairs reappear after a clean rebuild, something regenerates them. Work down this list and rebuild after each change.

1. Device version. Compare the device version in the device tree against the device repository and run Update Device to the version the SP9 based environment ships. The implicit system library requirements then regenerate for one profile instead of two.
2. Compiler version. Compare the compiler version setting in the project settings against the install in use. A project saved under SP15 can carry a newer profile than an SP9 generation compiler resolves cleanly; set it to the environment you actually build in.
3. Library repository. Open Tools > Library Repository on the failing PC and on the PC that builds clean, and search for CmpEventMgr. A 3.5.14.0 copy present here and absent there is the contamination. Remove or re-register that version. This change touches every project on the install, so run it only after the second-PC build has shown the machine is the side at fault.

Approaches compared and the decision

Recommendation: work on a copy, delete the four pinned entries in the Library Manager, keep the * placeholders, and rebuild clean. That is about 10 minutes of work and it matches the signature the output prints. Move to the device and compiler version alignment only if the pairs come back on the next build, and to the repository cleanup only after a build on the second PC has shown the fault travels with the machine. Skip the full reinstall: it costs hours, removes the side-by-side setup you rely on, and cannot touch duplicates stored inside the project file.

Questions