A Windows frontend for gin
WinGIN is a graphical frontend for the gin infrastructure developed by the German Neuroinformatics Node. It features an easy-to-use UI that allows users to perform basic operations on gin repositories; It also integrates into Explorer so that it can be used similar to commercial products like Dropbox(TM).
At their heart, gin repositories are git repositories using the git-annex extension to store large files. This means that the bulk of data in a given repository is not actually present on user harddrives when they make a checkout; as a result, files stored within gin are not directly accessible right away. To make them available for use, it is necessary to use the gin client to perform the actual file retrieval. WinGIN simplifies this process by automating it. When a file in a repository is accessed, WinGIN's background service will automatically intercept that file access call and, if necessary, retrieve the file from the remote repository. To make this process invisible to the user, WinGIN stores the actual data within its AppData directory while putting a mirror of that directory on the user's Desktop.
Installers and instructions can be found in the Installers repository on GIN.
This project is built for Visual Studio 2017. The following extensions should be installed in order to fully build the project:
- Visual Studio Installer Projects
- (Optionally) The Windows Communication Foundation component, available in the Visual Studio Installer under Development Activities
The project uses the following nuget packages:
- DokanNet
- MetroModernUI
- Newtonsoft.Json
- SharpShell
The GinClientApp solution is comprised of the following subprojects:
- GinClientApp
This contains the source code for the desktop client - GinClientLibrary
This project contains common code referenced by the other projects. It also contains the implementation of the Dokan driver interface, GinRepository and RepositoryManager classes the service relies on - GinShellExtension
This project contains the source code for the Shell Extension component - InstallerLibrary
This project contains the source code for custom actions used within the Setup project - Setup
A Visual Studio Installer project that builds the installer
The version of app is patched by AppVeyor during a build and compared to AppVeyor project json in the wingin-installers repository(https://web.gin.g-node.org/G-Node/wingin-installers). Version consists of Major_version.Minor_version.Build_number.
This project uses ReSharper style throughout.
Private variables and fields should always be lowercase and preceded by an underscore, i.e. private int _someint;
Wherever possible, use var instead of an explicit type.
Brace style is Allman.
The GinClientApp is a Windows Forms-based client. By default, the only UI displayed is the notification area icon created through the GinApplicationContext class. To achieve a more modern look, the MetroModernUI is used. When adding new dialogues or new messages, take care to place these within the app's Resources (resources.resx) to allow for easier localization. The GinClientApp also incorporates a WCF service component, which is started on program start and runs in a separate thread. This component is responsible for all the low-level interaction between Windows and gin; it executes all gin-related commands the user issues either through the notification area context menu, file context menus, or the UI.
The output of this project has to be signed, preferably using the same key used for the GinShellExtension library.
The shell extension uses the SharpShell framework by Dave Kerr. Documentation for its use can be found here: https://github.com/dwmkerr/sharpshell
The InstallerLibrary performs custom actions that cannot be replicated within a VS Installer project. At the moment, these are:
- Downloading, unpacking and installing the gin-cli client for Windows
- Giving the user the right to reserve the url "http://+:8738/GinService" on the local system
- Starts the service and the client after installation is complete The setup itself is a mostly straightforward VS Installer project, except for one thing: When the installer is built, the script file "ModifyMsiToEnableLaunchApplication.js" is executed to enable the installer to launch the DokanSetup.exe after installation is complete; this is something that cannot be defined within a VS Installer project for unknown reasons.
The following tasks are planned to be executed sometime post-initial release:
- Switching the WCF communication backend to use named pipes At the moment, the project is using HTTP-based methods to communicate. While certainly straightforward and, within the context of a locally hosted and executed application, reasonably fast, it is also more open than it needs to be; using a named pipe would resolve this.