If you have a commercial WinFsp license and wish to produce a rebranded version of WinFsp, you can follow the instructions in this document.
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.
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
MyProductFileName: This is the file name that will be used for the primary WinFsp components. For example: if you use
mycompanyfspthe FSD will be named
mycompanyfsp-x86.sys, the DLL will be named
mycompanyfsp-x86.dll, etc. The default value is
winfsp. (Note that due to a limitation the WinFsp .NET implementation assumes that
MyProductFileNameis the lowercase version of
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.
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.
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.buildversioning scheme. The
major.minorportion 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
RC(Release Candidate) and
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.
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.pythat can help with this.