A CODESYS sample project shows its library as unresolved when the downloaded package was unzipped by hand: extraction exposes the files but installs nothing. Install the package with Tools → Package Manager, reopen the packaged copy of the sample, and build to zero missing-library errors.
The sample opens, the build fails, and the Library Manager flags the XML library as unresolved. The cause is usually not the library file: it is the path the package took onto the machine. A CODESYS package unzipped with an archive tool delivers the files and none of the installation, so the environment never learns that the library exists, and "Download Missing Libraries" will not rescue the project, because it retrieves published dependencies, not uninstalled package components. The repair is short: install the package through Tools → Package Manager, open the sample the package carries, and build to zero missing-library errors. This page covers what went wrong, the install steps, the acceptance checks, a worked four-day demo scenario, and the branch to take when a reference stays unresolved after a clean install.
Why is the sample library missing after you extracted the package yourself?
A CODESYS package is an installation container, and unzipping it with an archive tool only exposes the files: the libraries inside never get registered in the library repository, so every reference the sample project makes to them stays unresolved.
What the Package Manager adds over an archive tool is the registration step. Installing a package records it in the installed-packages list, places its components where the environment looks for them, and runs the setup steps the package carries. An archive tool does one thing: it puts files in a folder. The environment resolves a project's library references against its repository, so the extracted library file can sit complete and healthy in the extraction directory while the Library Manager still flags the reference. Nothing about the file is wrong, and nothing about the installation has happened yet. If you edited the extracted copy of the sample and want to keep the edits, save them outside that folder now, because the repair replaces the extracted copy with the package's own.
Why does "Download Missing Libraries" keep failing?
The command retrieves library dependencies that your configured library sources actually offer, and a library that ships only inside a package you never installed is not offered anywhere, so the download reports failure every time you run it.
Two different operations sit behind the two things you tried. Installing a package registers every component the package carries. "Download Missing Libraries" works on the other end: it takes the references a project declares and fetches libraries that your configured sources offer for download. A library that exists only inside an uninstalled package is offered by no source, so the command fails, and the twentieth retry fails for the same reason as the first. Retrying asks the same question and gets the same answer. Check the network, the proxy and the source addresses only when the missing library is one that is genuinely published for download, or when a clean install is already in place and different references still fail.
What do the symptoms tell you?
Each symptom in this failure sorts into one of three causes: an uninstalled package, a reference that does not resolve to the version you have, or a library that no configured source offers, and you can tell them apart before touching anything.
- Unresolved row in the Library Manager, whatever the marker looks like. The reference has no matching library in the repository. Read the row's status text and the reference details, and write down the requested library name and version before you change anything.
- "Download Missing Libraries" fails every time. No configured source offers the library. When the sample arrived inside a package, that points straight at the uninstalled package, and it is why retries change nothing.
- The build reports missing-library errors. Count them: that count is the acceptance number for the repair, and the job is done when it reads zero.
- A dongle is attached and licensing looks healthy while the project stays broken. The repository question and the license question run on separate tracks, and the dongle answers only one of them.
How do you install the package the way CODESYS expects?
Open CODESYS, go to Tools → Package Manager, run its install action on the downloaded package file, let it finish, and then open the sample project from the installed package, never from the folder you extracted.
- Find the original downloaded package file. If you deleted it, download it again: the manager needs the package itself, and the extracted folder is no substitute.
- Open CODESYS and go to Tools → Package Manager.
- Run the install action and select the package file. Let the manager unpack and register everything the package carries: libraries, the sample project, any device support it includes.
- Read the completion messages before you close the dialog. If a component reports a failure, keep that message and clear it first. If the package lingers in an upcoming-installation state instead of completing, that is a separate problem with its own fix: see Fix a CODESYS package stuck at upcoming installation.
- Save any edits you made in the extracted copy of the sample, then open the sample that ships with the installed package, so the project and its libraries come from the same release.
- In the sample's Library Manager, open the details of the XML library reference and read the resolved name and version, not just whether the marker is gone.
- Rebuild the sample and read the message list end to end.
Copying one library file out of the extracted folder into the repository can silence a single reference, but it installs none of the other components and leaves the sample running against libraries that no install record describes. Keep that move for the rare case where no package exists and one published library covers the reference.
How do you check that the library now resolves?
Two checks close the job: the reference details in the Library Manager show the intended library name and version, and a rebuild completes with zero missing-library errors in the message list.
Everything else the Library Manager shows after an install is background, and one piece of background is worth naming before you mistake it for the problem: rows that display greyed entries are locked dependencies the project pulls in, locked dependencies you cannot delete, and they are not the failure you were chasing. Judge the repair on the XML reference alone: unresolved marker gone, resolved name and version read out, rebuild clean. If the resolved version differs from a version the sample's own text names, open the reference details again and point the reference at the version that actually loaded.
Scenario: the demo ends Friday, in what order do you work?
Scenario inputs are illustrative: you downloaded the demo on Monday for an evaluation that must conclude on Friday, the toolkit's demo license runs 30 days, and what actually limits you is the 4 remaining working days, not the license.
Work the documented numbers first. The Professional Developer Edition demo is published as a 30-day license covering all of its tools, so a five-day evaluation fits inside it with room to spare. Some demo libraries stop after 30 minutes of run time until they are licensed, and that shapes how long each test run can last: see Why a CODESYS library stops after 30 minutes and how to license it. The illustrative inputs are the schedule: 4 working days left, 8 working hours in each, 32 evaluation hours in the window. An afternoon lost to download retries burns 3 of those hours, and 3 ÷ 32 = 9.4 percent of the evaluation, before a single valid test has run. The repair itself takes about 10 minutes: package install, reopen the packaged sample, rebuild. That is 10 ÷ 60 = 0.17 hours, and 0.17 ÷ 32 = 0.5 percent of the same window. So the order is fixed: install on day one and confirm 0 unresolved references and 0 missing-library errors, spend the remaining 29 hours on real evaluation, keep individual test runs under 30 minutes, and license the library before any test whose whole point is a longer run.
What if the library is still unresolved after a proper install?
Then the question changes from installation to identity: open the reference details, compare the requested library name and version against what the installed package actually provides, and check whether the repository holds that version at all.
Two branches cover the leftovers. Branch one: the repository holds no matching library or version at all. The usual reason is drift between releases, because samples get copied around and a reference written for one release resolves against nothing from another. Keep the downloaded package and the sample together, install the matching package again, and open the sample the package carries. Branch two: a matching library is installed but the reference stays marked. Read the requested version in the reference details and point the reference at the version the repository holds. When names collide across versions, the build complains in a different dialect, and Fix CODESYS C0180 ambiguous namespace library errors covers that pattern. When the install is clean, the reference resolves, and the sample still stops partway through a run, that is the demo clock from the scenario above, and the library has nothing to do with it.
Recommendation: Install every CODESYS package through Tools → Package Manager before opening a sample that came inside it, and keep "Download Missing Libraries" as the second tool, for references that stay unresolved after a clean install. A package-supplied sample with two or more failing references gets the install; a single stubborn reference on a clean install gets the version check in its reference details.
Questions
Does the security dongle have anything to do with a missing library?
No. The dongle answers the licensing question; the unresolved reference is a repository question. A valid dongle and a missing library can sit side by side in the same project, and replacing or renewing the dongle will not bring the library back. Check licensing in the licensing tools and the library in the Library Manager, as two separate steps with two separate fixes.
How long does a CODESYS demo license last?
Terms differ per product, so read the page or readme that ships with the one you downloaded. The Professional Developer Edition demo is documented at 30 days for all of its tools. Component demos can run on a shorter clock in a different way: some demo libraries stop after 30 minutes until they are licensed. Plan the evaluation around the shortest clock your package carries.
Do vendor packages for specific controllers install the same way?
Yes. Controller makers ship their device support, examples and libraries as CODESYS packages, and their setup guides route the install through the Package Manager before you open any example, whether the target sits on the bench or inside a machine. Run the package install once, then open the sample the package carries, and keep the two from the same release.
What happens if I install the package but keep opening the extracted copy?
You keep the failure. The extracted project is not the installed one: its references resolve only through the repository, and if the install succeeded, the packaged copy of the sample is the version whose references resolve cleanly. Mixing an old extracted project with freshly installed libraries also invites version mismatches. Archive or delete the extracted folder once the real install is done.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.