Symlinker: a Windows GUI for symbolic links, hard links and junctions

The one command it wraps

Symlinker is a simple Windows GUI for creating symbolic links, hard links and directory junctions, with no command line needed.

That is the entire scope, and the honesty of the scope is the point. The Windows command for this is mklink, and it is not difficult, but it has three separate forms for the three link types, a requirement for administrator rights that produces a confusing failure when it is not met, and a syntax that has to be typed exactly. The application is a form for that.

The three link types are genuinely different things, and a GUI makes the choice visible rather than leaving it to a flag. A symbolic link is a pointer that resolves at access time, a hard link is a second directory entry for the same data, and a directory junction is the Windows mechanism for linking directories across volumes. Both file and folder link types are supported, so the tool covers the cases where you want a link to a file as well as the cases where you want one to a directory.

Paths can be dragged and dropped directly into the application, which removes the typing for the part of the command line that is most error prone, a long path with spaces in it.

Automatic UAC elevation is the other feature that matters more than it sounds. Administrator privileges are required for symlink creation, and when a user runs the tool without them the underlying operation fails. The application asks for elevation itself, so the failure mode of the command line becomes a consent prompt.

Why a GUI for mklink is worth an application at all

The obvious question about a tool that wraps one command is why it should exist at all, and the honest answer is that the command is not as simple as it looks.

Windows offers three ways to point one path at another and they are not interchangeable. A symbolic link is a pointer that is resolved at access time, so if the target changes the link follows it. A hard link is a second directory entry for the same data, which is a different thing entirely and is not available across volumes. A directory junction is the Windows mechanism for linking directories, and it is the one that behaves the way people expect a directory link to behave when the two are on different drives.

The mklink command encodes that choice as a flag, and it also encodes the elevated privilege requirement and a path syntax that has to be quoted correctly when it contains a space. So the three things a user gets wrong are the link type, the privilege, and the quoting, and a form removes all three.

There is also a category of task where a GUI is genuinely better than a command. If you create a link occasionally, learning a flag syntax is pure cost. If you create dozens, you would script it and not use this tool at all. The window of usefulness is the person who creates a handful of links a week and would otherwise look up the syntax each time, and for that person a form that always asks for elevation and always shows the link type as a choice is a clear win.

None of this is a criticism of the command line. It is the reason the tool exists, and understanding it tells you when it is worth installing and when it is not.

Three ways to install, and the one you would want on a work machine

There are three distribution routes, and they differ in what they require of the machine.

The ClickOnce installer supports automatic updates, and the standalone executable is the alternative for people who would rather not have application deployment machinery on their system. Both are linked from the README through a short redirect.

The third route is Scoop, and the commands are:

scoop bucket add extras
scoop install extras/symlinker

The extras bucket is a third-party bucket rather than the main one, which is worth knowing, because a bucket is a source of packages and the trust model of a third-party bucket is a decision you make by adding it.

For a work machine, the standalone executable is the one to take. ClickOnce installs a per-user application with an update mechanism that runs on a schedule, and while that is convenient it is more machinery on a corporate desktop than a single file needs to be. Scoop is reasonable if the machine already uses it for everything else, since the package manager then owns the update cycle along with the rest of the installed software.

The requirements are minimal: Windows 10 or Windows 11, and the .NET 8 Runtime. Signed releases are provided for verified authenticity, with the signing handled by SignPath.io under a certificate from the SignPath Foundation, and the privacy policy is a separate file in the repository.

The release history shows v3.0.0 on 2026-03-25, v4.0.0 on 2026-04-26 and v4.1.0 on 2026-07-31, so two major versions in about four months, which is a busy pace for a utility of this size and suggests the rewrite was recent.

The theme following the OS, and what the WPF rewrite bought

The light and dark mode support is the feature list item that reveals most about the current codebase.

The description is that light and dark mode support syncs with your Windows theme and accent color. That is a WinUI-era behaviour: an application that picks up the system accent colour and follows the system light or dark setting without the user configuring anything. The original Windows Forms application could not have done that, because the framework did not expose it in a usable way, and the 2026 migration is what made it possible.

So the rewrite was not a cosmetic refresh. Moving from Windows Forms to WPF with a UI inspired by WinUI 3 gave the application a modern look, and the specific technical consequences show in the repository. The primary language is recorded as C#, the project structure includes a Directory.Packages.props for central package version management, which is the modern way to keep transitive versions aligned across a solution, and the build is a standard dotnet CLI workflow rather than a Visual Studio-only one.

The distribution story also modernised. ClickOnce deployment with automatic updates is a Windows-native mechanism, and a signed release is provided for verified authenticity, with the signing handled by SignPath.io and a certificate from the SignPath Foundation. Together those two give you an application that updates itself and that Windows can confirm came from the expected publisher, which is the combination that makes a small utility acceptable on a managed desktop.

The build-portable.ps1 script in the repository root points at a third artefact, a portable build, alongside the ClickOnce installer and the standalone executable. Three formats for a tool that does one thing is generous, and it reflects the three situations people are in: a personal machine, a work machine where deployment machinery is unwelcome, and a machine where the application is carried on a drive.

Seventeen years, two rewrites, and a change of UI framework

The history section is the most interesting part of the README, because it explains why the repository looks the way it does.

The project has been around since 2009, originally hosted on Google Code and built with Windows Forms, and it has been revived multiple times. The timeline is: 2009 for the first release with a basic folder symlink GUI, 2010 for file symlinks, tooltips and UAC support, 2015 for the migration from Google Code to GitHub, 2025 for the upgrade to .NET 8 and the drop of support for anything before Windows 10, and 2026 for the migration from Windows Forms to WPF with a modern UI inspired by WinUI 3.

The 2026 rewrite is the one that shaped the current codebase. WPF rather than Windows Forms means the UI is XAML, which is why the primary language is recorded as C# with a project structure that includes a Directory.Packages.props for central package version management, and the theme work is visible in the feature list: light and dark mode support that syncs with your Windows theme and accent color, which is a WinUI-era behaviour that the old Windows Forms application could not have done.

The continuity across the rewrites is worth noting. The previous project link still points at the original Google Code page, and the Featured On section lists Softpedia and addictivetips as current, with TecFlap and Zhacks as archived links. The application has outlived its host, its language and its UI framework, which is a decent argument for the packaging choices it makes now.

The build story is also modern. Building from source needs the .NET 8 SDK and the commands are:

dotnet build Symlinker/Symlinker.csproj
dotnet run --project Symlinker/Symlinker.csproj

The repository has a solution file, a release.ps1 and a build-portable.ps1 for the portable build, and a cliff.toml which is the configuration for git-cliff, the changelog generator, paired with a CHANGELOG.md.

Editorial conclusion

Symlinker suits a Windows user who creates symbolic links often enough to have learned the mklink syntax and the elevation requirement by heart, since the whole application is a form for the one command. It does not suit you if you need links in bulk or on a schedule, because the interaction is manual, and it does not suit you on anything other than Windows, since directory junctions and the elevation model are Windows specific. Before you install it, take the standalone executable rather than the ClickOnce installer if you dislike application deployment machinery on a work machine, and note that symlink creation needs administrator rights, so the app will prompt for elevation on every run.

Frequently asked questions

Official sources

1. amd989/Symlinker on GitHub
2. License: MIT
3. Project website
4. README
5. Releases