= WinFsp Rebranding

If you have a commercial WinFsp license and wish to produce a rebranded version of WinFsp, you can follow the instructions in this document.

== Overview

The WinFsp build is controlled by the file `build\VStudio\build.version.props`. The file contains properties that control the final build output in a number of ways. Some of the properties in this file control how the final build product is branded, others how it is versioned, etc.

=== Branding

The properties that control branding are the following:

* `MyProductName`: This is the overall product name. It should be a short name without spaces. For example: `MyCompanyFSP`. The default value is `WinFsp`.

* `MyProductFileName`: This is the file name that will be used for the primary WinFsp components. For example: if you use `mycompanyfsp` the FSD will be named `mycompanyfsp-x64.sys` and `mycompanyfsp-x86.sys`, the DLL will be named `mycompanyfsp-x64.dll` and `mycompanyfsp-x86.dll`, etc. The default value is `winfsp`. (Note that due to a limitation the WinFsp .NET implementation assumes that `MyProductFileName` is the lowercase version of `MyProductName`.)

* `MyDescription`: This is a longer product description. For example: `MyCompany File System Proxy`. The default value is `Windows File System Proxy`.

* `MyCompanyName`: This is the company name.

* `MyCopyright`: This is the product's copyright.

* `MyFspFsctlDeviceClassGuid`, `MyFspFsvrtDeviceClassGuid`: When creating devices the FSD needs to assign GUID classes to them; it uses the GUIDs specified by these properties. You MUST change these GUIDs when rebranding; otherwise your product and "official" WinFsp releases may interfere with each other. From the Visual Studio main menu use Tools > Create GUID and select option "3. static const struct GUID" to produce GUIDs in the correct format.

=== Versioning

The properties that control versioning are the following:

* `MyCanonicalVersion`: This is the "canonical" (i.e. non-marketing) version of the product. WinFsp uses a `major.minor.build` versioning scheme. The `major.minor` portion of the version comes from this property; build numbers are computed automatically from the current date.

** Some WinFsp components check that canonical versions of different components match. For example, the WinFsp .NET implementation checks that its major version matches the one from the WinFsp DLL.

* `MyProductVersion`: This is the product (i.e. marketing) version of the product. WinFsp uses the release year as the product version; it also adds a point release for subsequent releases (thus 2021 is the first release in 2021, and 2021.1 is the second release, etc). This property may be an arbitrary string.

* `MyProductStage`: This specifies the kind of the build. Allowed values are `Beta`, `RC` (Release Candidate) and `Gold` (Final).

== Limitations

Currently WinFsp supports rebranding of the core WinFsp components:

* The WinFsp FSD (File System Driver).

* The WinFsp DLL (user mode DLL). This includes the DLL import libraries.

* The WinFsp Launcher (Windows service that allows for easy launching of file systems).

Currently WinFsp does not support rebranding of the following components:

* Development files such as header files, samples, etc. These are not end-user visible and therefore are not necessary to be rebranded.

* WinFsp test suites.

* FUSE for Cygwin.

* Chocolatey builds.

Additional limitations:

* The default installer (in file `build\VStudio\installer\Product.wxs`) contains a number of GUIDs. These MUST be changed if the default installer is used by a rebranded product; otherwise installation of your product and "official" WinFsp releases may interfere with each other. There is a Python script at `tools\gensrc\wixguid.py` that can help with this.