The script on our server bumps the build number for every new version + commit combination.
Each combination is associated to a unique build number and vice versa.
There's a separate counter for each version.
The reason why we cannot just use "git describe --tags --dirty" is because it relies on the last tag's name and generates a string like "5.01.9674-212-g54280853".
What we want, instead, is the last part of the version to be increased for every build.
Then, once we consider the branch stable enough, we create a tag like "5.01" and bump the version immediately after the new release.
Please note that for pull requests the build number will always be 0, because the secret token is only available in the Nightly pipeline.
The BUILD_NUMBER option controls the last part of the version, allowing us to increase it for each build.
This commit also adds version.py, which simply prints the version (e.g. "5.01") specified in CMakeLists.txt.
The script will be used to determine the build number.
Since 35200a29ea we build complete installers using CMake, meaning that there's no need for BuildUtil anymore.
MSBuild projects that are not migrated to CMake yet are kept for reference.
This commit also updates BUILD_WINDOWS.md so that it mentions Visual Studio 2019 instead of 2017.
To solve the problem that the escape condition of the loop that tries name resolution in UDP mode was reversed in the keep-alive function of the Internet connection, so the name resolution retry is set to 250 msec interval instead of the normal 60 second interval.
This works for all VPN protocols.
In SessionMain(): for DHCPDISCOVER and DHCPREQUEST frames, write the static IP address (which is retrieved from the user notes) in the SIADDR field of DHCPHEADER.
In VirtualDhcpServer(): for DHCPDISCOVER and DHCPREQUEST frames, read the static IP address from the SIADDR field of DHCPHEADER and assign it to the client.
- When building on Windows XP using Visual Studio 2008, I encountered the following issue.
- I did a fresh install of Windows XP SP3 32-bit, then applied updates including .NET 3.5. Next I installed MS Visual Studio 2008, then updated with sp1. All of this according to the documentation in your readme for building on Windows.
- In file src/BuildUtils/VpnBuilder.cs, there are two "if" statements testing the same thing, which is to determine if it is a 32-bit or 64-bit machine/compiler. But the then and else clauses are reversed, so clearly, one of them is wrong. The result I saw is that the SDK path being used to run RC.exe is left as the NULL string and so it fails to run the RC.exe program.
- This happens early in the build process, building the build utils. The two "if" statements are used to set paths for the Visual Studio VC and SDK directories. Depending on the integer pointer size, it uses different paths in the registry.
- When I looked in the registry on my Windows XP machine, there is no key HKLM\SOFTWARE\Wow6432Node, I have only seen that on 64-bit machines.
- For the fix, I consolidated the two "if" statements into one, the existing statement on line 380 would only set a value for Paths.VisualStudioVCDir (which got set correctly). Now I moved the code for also setting Paths.MicrosoftSDKDir, while reversing the values from the incorrectly coded "if" statement.
- I can understand that under certain circumstances, this issue would not be encountered, but should be easily reproducible when installing a clean system.
