arnobpl/symlinkcreator

1. Project type and runtime

- This is a Windows desktop WPF application written in C#/.NET.

- Its purpose is narrow and tool-like: create NTFS symbolic links by generating and running a mklink-based script.

- The app is explicitly Windows-only and depends on administrative privileges for symlink creation.

2. Top-level structure

- The solution is split into three main areas:

- core/: symlink creation logic and script execution

- ui/: WPF windows, view model, and window-specific helpers

- SymlinkCreatorTests/: unit tests for utility behavior

- The root App.xaml / App.xaml.cs act as the WPF application entrypoint and bootstrap layer.

3. User-facing application boundary

- The primary interaction surface is ui/mainWindow/MainWindow.xaml with its code-behind and MainWindowViewModel.

- The main window is the orchestration point where the user supplies source paths, destination path, and options such as:

- relative paths when possible

- retaining generated script files

- hiding successful operation dialogs

- ui/aboutWindow/ is a secondary informational window, not part of the core execution path.

4. Core symlink workflow

- The central workflow is likely:

1. collect selected file/folder sources from the UI

2. validate and normalize paths

3. build an executable script using mklink

4. run the script

5. report success or failure back to the UI

- This flow is implemented across SymlinkAgent, ApplicationConfiguration, and ScriptExecutor.

5. core/SymlinkAgent.cs as the domain coordinator

- This is the main domain service that appears to own symlink generation logic.

- It likely decides how each source path maps to a destination path, whether the target is a file or directory, and whether a relative path can be used.

- It is the best place to think of as the app’s business-logic boundary between UI inputs and OS-level execution.

6. core/ScriptExecutor.cs as the OS execution boundary

- Script generation is not enough; the app must actually invoke the Windows command shell or command interpreter to run the script.

- ScriptExecutor is the boundary that turns generated script content into an executed process.

- This is also where failures from the OS layer would surface: privilege issues, invalid paths, long-path problems, or mklink errors.

7. Configuration and behavior flags

- core/ApplicationConfiguration.cs suggests a small configuration model holding app-level options.

- The README’s options map well to this configuration layer:

- relative path preference

- retain script file

- suppress success dialogs

- These options influence both the script content and the user feedback path.

8. UI-to-core data flow

- The ViewModel is the main bridge between WPF controls and the core services.

- The UI likely collects drag-and-drop input, binds it to observable state, and triggers symlink creation through commands.

- This separates presentation concerns from execution concerns, with the ViewModel acting as the mediator.

9. Windows-specific helpers

- ui/utility/LongPathAware.cs indicates the application is built with long path support, which is important because symlink targets and sources can exceed legacy path limits.

- NativeAdminShieldIcon.cs and WindowMaximizeButton.cs are window chrome / shell integration helpers.

- These are UI-adjacent, platform-specific pieces rather than core logic.

10. Packaging and app identity

- app.manifest, App.config, and packages.config show a classic desktop packaging/runtime setup.

- The manifest likely carries privilege and compatibility settings; the README explains the app needs elevation to create symlinks.

- FodyWeavers.xml indicates build-time weaving/instrumentation is used, though it is not central to runtime architecture.

11. Resources and static assets

- resources/icons/ contains application icons and supporting visuals.

- _ReadMe/ stores screenshots and donation images used by the repository documentation and release presentation.

- These assets affect presentation, not execution.

12. Testing boundary

- SymlinkCreatorTests/ contains focused unit tests, with SymlinkUtilityTest.cs suggesting validation around path/script utility behavior.

- The tests likely target non-UI logic, which is the most stable place to verify behavior in a tool that depends heavily on filesystem rules.

13. Architectural summary

- The app is essentially a thin WPF shell around a Windows command-based symlink engine.

- The key architecture boundary is between:

- UI state and user interactions

- core path/script generation

- privileged external command execution

- When drawing the diagram, the most important arrows are: user input → ViewModel → core symlink agent/config → script executor → Windows shell / mklink → filesystem.