FileSharer Development Notes 10 — From Executable to Installer: Distribution Is a Feature Too
FileSharer Development Notes · 10 / 10
The questions change as soon as a program that runs on your PC is handed over to someone else’s. You need to explain where it is installed, whether it starts automatically at sign-in, whether the previous share list is retained, and what is removed when it is uninstalled. FileSharer has a separate Setup.cs to handle this role.
In this final installment, I examine distribution as part of the product’s behavior, rather than just a finishing task. This was a source review: the installer and uninstaller were not run, no existing installation was overwritten, and registry and firewall settings were not changed.
Build from the inside out
A configuration that includes the relay for external sharing links three build artifacts together.
Go tsproxy executable
↓ embedded as a gzip resource
C# FileSharer application
↓ embedded as an executable resource
C# FileSharer installer
The installer extracts resources embedded within itself, rather than always fetching the latest application from the internet when it runs. If the application changes but the installer is not rebuilt, the installer can therefore distribute an older application. An unchanged filename is not evidence of a current build.
The same applies to the Go relay file. The C# source contains an error path for when the tsproxy.exe.gz resource cannot be found. Checking whether the code compiles and checking whether all required executable resources are present are separate tasks.
What the installer actually does
Installer.Run checks for a running instance of the application, creates the installation folder, and extracts the application and icon from resources. There is also a path that copies the installer itself under the uninstaller’s name. Depending on the selected options, it creates desktop and Start menu shortcuts and writes an automatic-start entry.
The default installation location is in the LocalApplicationData area under the user profile. The code also uses Registry.CurrentUser for the installed-program listing and automatic startup. This needs to be distinguished from an installation for all users of the system.
Firewall configuration is a separate option whose default is false. Even in an environment that allows file copying and user-registry registration, firewall changes are not guaranteed to be possible with the same permissions. The code likewise records the result of the firewall operation separately.
Automatic startup should be understandable to the user
The installer object’s AutoStart default is true. When enabled, it registers the application to run with the /tray argument. In the application, the window’s close button normally hides it in the tray instead of exiting. This combination means that ‘the window is no longer visible’ can differ from ‘file sharing has stopped.’
For a tool like this, the installation interface and user guidance should clearly explain whether automatic startup is enabled, why the application remains in the tray, and how to exit it. Users need to understand when a program is running, particularly when it has network functionality. This article does not provide a distribution with those defaults changed.
Updates involve a contract between binaries and data
Checking only that the new application has been installed is not enough. You also need to check how the new version reads share records saved by the previous version and supplies defaults for older fields. FileSharer’s store loader creates a new key for rows that lack an encryption-key field. That makes the continued usability of previous links another issue to address separately.
A release checklist tailored to this project can be specific.
| Stage | What to verify |
|---|---|
| Before packaging | Build order and hashes for the relay, application, and installer |
| Fresh installation | Selected path, shortcuts, and launch options |
| Updating an existing installation | Share-data format and handling of existing links |
| Uninstallation | Removal of automatic startup and the selected data-preservation behavior |
This table proposes source-derived checks; it does not report executed tests.
Check the scope of ‘keep data’ against a file list
When data preservation is selected, the uninstallation code keeps settings.txt, shares_db.txt, and access_log.txt. This does not mean that every related file is preserved. For example, the previous generation’s .bak file is not included in that list of three names. The recovery files a user expects and the files the code actually leaves behind need to be checked against each other.
Removing the uninstaller itself also differs from deleting an ordinary file. The original implementation has a path that performs cleanup in a separate process after the uninstaller exits. The scope of deletion and any files left behind on failure also need review.
What ten installments reveal about FileSharer
It begins as a small tool for sending files, but following the source shows how share state, HTTP input, partial transfers, ZIP preparation, QR codes, external connections, logs, storage, and distribution form a single user experience. Success in any one part does not establish success for the whole.
Before adding more features to the next version, one useful check is whether the meaning of each state remains consistent from link creation through receipt confirmation, restarting, and uninstallation. This is also why the series distinguishes observed execution results from static analysis. Recording exactly what was verified makes it possible to compare what the next change improves.
Setup.cs:25–51 AppInfo · Setup.cs:160–186 ExtractResource / ResourceSize · Setup.cs:391–506 Installer.Run · Setup.cs:953–1044 Uninstallation and data preservation · FileSharer.cs:1854–1905 ExtractProxy
The original project files were not modified. Proposed improvements are distinguished from implemented behavior.
댓글
댓글 쓰기