# Cinchoo/ChoEazyCopy: a copy tool whose best feature is showing you the command it will run > ChoEazyCopy is a Windows desktop front end for the built-in file copy utility, and the design decision that makes it worth reading is that every change to the property grid updates a text box containing the equivalent command line, so you can check the translation and run it yourself. It is also, by its author's own statement, a demonstration of a commercial framework, which changes who the software is actually for. **Cinchoo/ChoEazyCopy** — Simple and powerful RoboCopy GUI - Repository: https://github.com/Cinchoo/ChoEazyCopy - Stars: 2,268 · Forks: 142 - Language: C# - License: MIT - Published: 2026-09-30 · Updated: 2026-09-30 · Language: en - Canonical page: https://hysenlabs.com/projects/cinchoo-choeazycopy ## The command preview is the feature, and everything else is convenience The underlying utility is worth understanding first, because the front end adds nothing that the utility cannot already do. It ships with Windows Server, it performs advanced replication, and its distinguishing capability is creating a full mirror duplicate of a directory tree, subdirectories and files included, optionally. It can also preserve the file metadata that an ordinary copy throws away, and the readme names the two that matter most: timestamps and access control lists. That last one is the difference between a copy that preserves your permissions model and one that quietly resets it to the destination's defaults. Given that, the interesting question is what a graphical front end is for. Most wrappers hide the command. This one does the opposite, and the feature list is explicit about it: a text box containing the copy command associated with changes to the properties, updated as you change them, plus immediate contextual hints for whichever option is currently highlighted in either the property grid or the text editor. That combination is the whole argument for the tool. A property grid is fast to use and terrible to learn, because a label tells you what a switch is called and nothing about what it will do to your files. A command line tells you exactly what will happen and nothing about how to discover it. Showing both, and keeping them in step, means you can click through the options you recognise and read the command for the ones you do not. The hint on hover closes the remaining gap by explaining the switch in place. The payoff is that you are not locked in. Once you have clicked your way to a configuration you like, you can select the text and paste it into a command prompt, put it in a scheduled task, or hand it to somebody else. For an operation that can mirror and therefore delete, being able to leave the interface behind is not a minor convenience. ## By its author's own account, this is a framework demonstration The readme says something that ought to be in the first line and is in the fourth paragraph: this tool is developed using a framework for the .NET platform, and it is another working example of using some of the key features of that framework. That reframes the entire feature list. The system tray integration, the custom property grid with file and folder pickers, the themed window and system colour handling, the most-recently-used combo box with an observable collection behind it, the grid view column visibility manager, the sort adorner: these are not features a user needs. They are a catalogue of what a .NET desktop framework can do, demonstrated in an application small enough to read in an afternoon. This is not a criticism. Building a real tool to exercise a framework is a much better way to find its sharp edges than writing sample code, and the code does what anyone would want from a reference implementation: it is a desktop application with a settings object, a task queue, a manager class for the external process, custom value converters, and a user preferences store. Reading the file list is a tour of the architecture. It does change how you should evaluate the software, though. When the audience is framework adopters, the priorities are legible from the choices. Every type in the project carries a common prefix, which is what you do when your application classes share a namespace with the framework's own. The application has its own settings, theme and assembly version handling rather than using the defaults. The project is not minimal. None of that is wrong, and all of it is aimed at somebody evaluating the framework rather than somebody who needs to copy a folder at four in the afternoon. There is also a beta marker implemented as an assembly-level attribute file, which tells you the author wanted the build's beta status to appear in the program's own identity rather than only in the file name. ## Profiles, multiple instances and a tray icon turn it into a job runner Three features on the list only make sense together, and together they change what kind of program this is. Compose and save the options as a profile for reuse means the configuration is a first class object rather than a set of fields you retype. Run multiple instances means the tool does not assume it is the only copy job you care about. Run and launch from the system tray means it is expected to be present but not in the way, which is the behaviour of a program you leave running rather than one you open when you have a task. The source layout confirms that reading. There is a task queue manager and a task queue item class, and a separate class carrying log information for a queue item, plus a class describing backup task information. That is a persistent job system with per-task logging, not a modal dialog with two path pickers. This matters for how you would actually use it. A copy utility that is a dialog is something you open, configure, run and close. A copy utility with profiles, a queue and a tray resident is something you set up once for the backup you run every night, which is the use case the underlying utility's mirror and metadata-preservation features are designed for in the first place. The readme is quiet about scheduling, and there is no documented way to trigger a run from the command line, so the automation story is limited to the profiles themselves. But the shape of the code says the author was building toward unattended use even if the readme does not claim it. The one dependency the readme understates is the executable itself. The tool requires the copy utility to be present on the system path, and says it can be specified in the tool if it is not. In practice that means this is a Windows-only program in a stronger sense than just the runtime: on a machine without that executable there is nothing to drive. It also means the set of available options depends on the version of the operating system, since switches are added to that utility over time, and the property grid cannot offer what the local copy does not understand. ## A project file from before SDK-style, and a four-part version number The release history explains the shape of the project before you open a single file. There are three releases, and the version numbers have four parts: a two, three zeros, a zero and then a fourth counter. The third release in that sequence is from September 2024, a beta of the same fourth counter arrived in June 2025, and the final one shipped in January 2026. The last commit to the default branch is dated at the end of June 2026, five months after that release, so there is unreleased work sitting on the branch and no way to tell from the outside whether it is a fix or an experiment. A four-part version is a legacy convention and it is a reliable signal about the project era. The build uses the pre-SDK project format, evidenced by a packages reference file rather than a package reference section in the project, an application configuration file, a properties directory, and a separate solution file. It targets a desktop framework, and the readme links three versions of it, going back to the original. The build toolchain includes a weaver configuration, which is the file that tells a .NET code weaving tool what to inject at compile time, and a matching schema file for that configuration that has no business being in a repository at all except that the tool generated it there. The runtime requirement deserves one plain sentence: this does not run on macOS or Linux, and there is no path to making it. The desktop framework it targets is Windows only, and the command it drives ships only with Windows. If you are on any other operating system, the question is settled before you read anything else. The dependency file being in the old format also means the package set is pinned to a fixed list rather than resolved, which for a project of this size is a reasonable trade and for anyone rebuilding it is one more thing to migrate. None of this is criticism of a small utility that works. It is the practical boundary of what you can expect to maintain. ## A signing key is committed to the repository Among the files in the project root there is a personal key container, a file with a certificate extension, and its name includes the word temporary. Desktop .NET projects often sign their assemblies so that two components with the same simple name can coexist in one process, and the key used for that is conventionally generated once, kept out of the way, and referenced by the project file. Committing one is extremely common, usually by accident, and usually in a repository that nobody intended to publish. In this case the name suggests the author knew exactly what it was and did not care. For this application that is defensible, and the reason is worth stating so the finding is not overstated. Strong naming is an identity mechanism, not a security mechanism. It lets the runtime tell two same-named components apart, and it records who compiled the assembly, which for a desktop utility distributed as a zip from a release page buys nothing. Nobody verifies a strong name before running a program, and an attacker who wanted to impersonate this application would not be stopped by the key being public. What it does do is make the assembly's identity meaningless as a provenance claim. If you see that identity somewhere and conclude the binary came from this project, the conclusion is unsound, because anyone with the committed key can produce an assembly claiming it. That is worth knowing if you are the kind of person who checks, and it costs nothing to fix later by moving the key out of the repository and letting the build sign with a key from a secret store. The same casual posture shows up in a file that has no reason to exist outside a developer's machine and a settings class sitting in the project root rather than in a configuration folder. For a personal tool this is fine. It is a small tool. ## The documentation is a readme stub and two links that will not last The readme is about as short as a readme gets, and it is not incomplete by accident. It explains what the underlying utility does, lists the features, and then hands you off three times: to a code project article for a fuller write-up, to a blog post for help, and to a media platform article of the same name as the first one. Two of those three destinations are hosted on platforms that have changed ownership, changed URL structure, or both, and both articles are duplicates of each other in subject. A reader arriving in 2027 will find a readme that says, in effect, everything else is somewhere else, and somewhere else is a set of links to pages that may no longer resolve. For a tool this small that is survivable, because the feature list plus the underlying utility's own documentation is genuinely enough to operate it. The live command preview is self-documenting in a way most utilities are not, and the property grid hints exist precisely so a user does not need the articles. That is a better position than it first appears. The setup instructions are the part to read carefully instead, and they are concrete. Download the archive from the releases page, extract it to a folder on a local drive rather than a network location, and run the executable from there. The note that extraction tools matter is not made here, but the instruction to use a specific local path is a hint that the program expects to own its own directory. The readme also links the runtime download for each of the three supported framework versions, which is the tell that this is a program written for a world where the runtime is not present by default, a world that ended some time ago on current Windows but not on older or stripped-down installations. There is a star badge at the top that has no destination, which is a small blemish on an otherwise unusually honest readme: it tells you the project is valued and then tells you nothing about what. ## Conclusion ChoEazyCopy is worth installing if you are on Windows, you find the built-in copy utility's switches powerful and its syntax unmanageable, and you are willing to unzip a release archive rather than install a package. The live command preview is the reason to try it, because it turns the tool from a black box into a teaching aid that you can outgrow. It is a poor fit if you are on macOS or Linux, since it targets a desktop framework that exists only on Windows and depends on a utility that ships with the operating system, and a poor fit if you need automation, because there is no documented command line interface of its own. Before trusting it with an irreversible mirror operation, read the generated command once and confirm the destination yourself, and treat it as the framework demonstration its author says it is rather than as the most capable option available. ## FAQ ### What does Cinchoo/ChoEazyCopy do? It is a Windows desktop front end for the file replication utility that ships with Windows Server, adding a property grid interface, reusable profiles, a task queue, system tray support and a text box that shows the equivalent command as you change options. ### What operating systems and runtimes does ChoEazyCopy support? Windows only, in two independent ways: the application targets a desktop framework available solely on Windows, and it drives a copy executable that is part of the Windows operating system. The readme links three versions of that runtime, back to the original release. ### Is ChoEazyCopy's source code available? The project is MIT licensed and its source is in the repository, including the project file, the window definition and the controls directory. The readme states it was written as a working example of the author's own application framework for the platform, so it doubles as framework documentation. ### How do I install ChoEazyCopy? Download the binary archive from the releases page, extract it to a folder on a local drive, and run the executable from that folder. The underlying copy utility must be on the system path, or its location must be specified inside the tool. ## Sources - [Cinchoo/ChoEazyCopy on GitHub](https://github.com/Cinchoo/ChoEazyCopy) - [Issues](https://github.com/Cinchoo/ChoEazyCopy/issues) - [License: MIT](https://github.com/Cinchoo/ChoEazyCopy/blob/master/LICENSE) - [README](https://github.com/Cinchoo/ChoEazyCopy/blob/master/README.md) - [Releases](https://github.com/Cinchoo/ChoEazyCopy/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cinchoo-choeazycopy