Hesham/wintun
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
51a4f299c3
wintun/wintun.props

53 lines
2.5 KiB
Plaintext
Raw Normal View History

Rewrite installer logic in C Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2019-07-22 09:36:21 +02:00
<?xml version="1.0" encoding="utf-8"?>
Switch from NMake to MSBuild This allows common version and other configuration in wintun.props. - MSM packaging migrated to WiX MSBuild project and extended to support digital signing - Building supports single Platform|Configuration per run - again :( - wintun.vcxproj cleanup Signed-off-by: Simon Rozman <simon@rozman.si>
2019-04-19 15:24:39 +02:00
<!--
Rewrite installer logic in C Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2019-07-22 09:36:21 +02:00
SPDX-License-Identifier: GPL-2.0
Switch from NMake to MSBuild This allows common version and other configuration in wintun.props. - MSM packaging migrated to WiX MSBuild project and extended to support digital signing - Building supports single Platform|Configuration per run - again :( - wintun.vcxproj cleanup Signed-off-by: Simon Rozman <simon@rozman.si>
2019-04-19 15:24:39 +02:00
Copyright (C) 2019 WireGuard LLC. All Rights Reserved.
-->
<Project DefaultTargets="Build" ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WintunVersionMaj>0</WintunVersionMaj>
version: bump Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2020-12-15 21:39:30 +01:00
<WintunVersionMin>10</WintunVersionMin>
project: add support for intermediate versioning While the Wintun driver is typically released only at <major>.<minor> milestones, the wintun.dll did see some intermediate releases. To make MSI logic correctly decide to upgrade local wintun.dll file, the version inscribed in wintun.dll file resources should increment in those intermediate releases. MSI ignores file timestamps. One could use REINSTALLMODE=emus Installer property to force copying wintun.dll when its version doesn't change. But REINSTALLMODE applies to all files in the MSI session and would be an additional requirement when authoring MSI packages with wintun.dll. Bumping only the final ZIP filename version is not sufficient. Therefore, a <major>.<minor> or <major>.<minor>.<build> versioning is introduced. Furthermore, we no longer distinguish between WintunVersion and WintunVersionStr. All our releases used strictly numeric <major>.<minor> notation, making WintunVersion and WintunVersionStr always the same. When the driver didn't change, just bump the version in wintun.proj and run `msbuild wintun.proj /t:Zip` to rebuild the wintun.dll and make the new ZIP file. Signed-off-by: Simon Rozman <simon@rozman.si>
2021-03-19 11:52:11 +01:00
<WintunVersionRel>2</WintunVersionRel>
<!-- Used for versioning, must be n.n[.n[.n]]. -->
<WintunVersion>$(WintunVersionMaj).$(WintunVersionMin)</WintunVersion>
<WintunVersion Condition="'$(WintunVersionRel)'!='0'">$(WintunVersion).$(WintunVersionRel)</WintunVersion>
Switch from NMake to MSBuild This allows common version and other configuration in wintun.props. - MSM packaging migrated to WiX MSBuild project and extended to support digital signing - Building supports single Platform|Configuration per run - again :( - wintun.vcxproj cleanup Signed-off-by: Simon Rozman <simon@rozman.si>
2019-04-19 15:24:39 +02:00
Use WiX directly rather than via WiX's MSBuild Signed-off-by: Simon Rozman <simon@rozman.si>
2019-08-05 13:32:03 +02:00
<!-- .vcxproj are using different platform names. -->
api: add support for WoW64 Some functions of SetupAPI only work when invoked from a native process. Registry and filesystem reflection makes them fail on WoW64. For WoW64 processes, a minimum set of rundll32 functions are provided. Signed-off-by: Simon Rozman <simon@rozman.si>
2020-07-24 09:39:02 +02:00
<WintunPlatform Condition="'$(Platform)'=='ARM'">arm</WintunPlatform>
<WintunPlatform Condition="'$(Platform)'=='ARM64'">arm64</WintunPlatform>
Switch from NMake to MSBuild This allows common version and other configuration in wintun.props. - MSM packaging migrated to WiX MSBuild project and extended to support digital signing - Building supports single Platform|Configuration per run - again :( - wintun.vcxproj cleanup Signed-off-by: Simon Rozman <simon@rozman.si>
2019-04-19 15:24:39 +02:00
<WintunPlatform Condition="'$(Platform)'=='Win32'">x86</WintunPlatform>
<WintunPlatform Condition="'$(Platform)'=='x64'">amd64</WintunPlatform>
</PropertyGroup>
Rewrite installer logic in C Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2019-07-22 09:36:21 +02:00
<ItemDefinitionGroup>
<ClCompile>
project: add support for intermediate versioning While the Wintun driver is typically released only at <major>.<minor> milestones, the wintun.dll did see some intermediate releases. To make MSI logic correctly decide to upgrade local wintun.dll file, the version inscribed in wintun.dll file resources should increment in those intermediate releases. MSI ignores file timestamps. One could use REINSTALLMODE=emus Installer property to force copying wintun.dll when its version doesn't change. But REINSTALLMODE applies to all files in the MSI session and would be an additional requirement when authoring MSI packages with wintun.dll. Bumping only the final ZIP filename version is not sufficient. Therefore, a <major>.<minor> or <major>.<minor>.<build> versioning is introduced. Furthermore, we no longer distinguish between WintunVersion and WintunVersionStr. All our releases used strictly numeric <major>.<minor> notation, making WintunVersion and WintunVersionStr always the same. When the driver didn't change, just bump the version in wintun.proj and run `msbuild wintun.proj /t:Zip` to rebuild the wintun.dll and make the new ZIP file. Signed-off-by: Simon Rozman <simon@rozman.si>
2021-03-19 11:52:11 +01:00
<PreprocessorDefinitions>WINTUN_VERSION_MAJ=$(WintunVersionMaj);WINTUN_VERSION_MIN=$(WintunVersionMin);WINTUN_VERSION_REL=$(WintunVersionRel);WINTUN_VERSION="$(WintunVersion)";%(PreprocessorDefinitions)</PreprocessorDefinitions>
Rewrite installer logic in C Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2019-07-22 09:36:21 +02:00
<WarningLevel>Level4</WarningLevel>
</ClCompile>
<ResourceCompile>
project: add support for intermediate versioning While the Wintun driver is typically released only at <major>.<minor> milestones, the wintun.dll did see some intermediate releases. To make MSI logic correctly decide to upgrade local wintun.dll file, the version inscribed in wintun.dll file resources should increment in those intermediate releases. MSI ignores file timestamps. One could use REINSTALLMODE=emus Installer property to force copying wintun.dll when its version doesn't change. But REINSTALLMODE applies to all files in the MSI session and would be an additional requirement when authoring MSI packages with wintun.dll. Bumping only the final ZIP filename version is not sufficient. Therefore, a <major>.<minor> or <major>.<minor>.<build> versioning is introduced. Furthermore, we no longer distinguish between WintunVersion and WintunVersionStr. All our releases used strictly numeric <major>.<minor> notation, making WintunVersion and WintunVersionStr always the same. When the driver didn't change, just bump the version in wintun.proj and run `msbuild wintun.proj /t:Zip` to rebuild the wintun.dll and make the new ZIP file. Signed-off-by: Simon Rozman <simon@rozman.si>
2021-03-19 11:52:11 +01:00
<PreprocessorDefinitions>WINTUN_VERSION_MAJ=$(WintunVersionMaj);WINTUN_VERSION_MIN=$(WintunVersionMin);WINTUN_VERSION_REL=$(WintunVersionRel);WINTUN_VERSION="$(WintunVersion)";%(PreprocessorDefinitions)</PreprocessorDefinitions>
Rewrite installer logic in C Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2019-07-22 09:36:21 +02:00
</ResourceCompile>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)'=='Release'">
<ClCompile>
<Optimization>MaxSpeed</Optimization>
<IntrinsicFunctions>true</IntrinsicFunctions>
<FavorSizeOrSpeed>Speed</FavorSizeOrSpeed>
</ClCompile>
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)'=='Debug'">
<ClCompile>
<Optimization>Disabled</Optimization>
</ClCompile>
vs: put .pdb files in the intermediate folders Wondering, why WinDbg is refusing to load symbols for wintun.sys recently... By default, building puts .pdb files to the output folder. Next to the final binaries: wintun.sys, wintun.dll, example.exe... Wait?! But the wintun.pdb from wintun.dll overwrites the wintun.pdb from wintun.sys then. Signed-off-by: Simon Rozman <simon@rozman.si>
2021-04-13 12:50:13 +02:00
<Link>
<ProgramDatabaseFile>$(IntDir)$(TargetName).pdb</ProgramDatabaseFile>
</Link>
Rewrite installer logic in C Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2019-07-22 09:36:21 +02:00
</ItemDefinitionGroup>
Dynamically gather signtool full path Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2019-08-05 13:25:32 +02:00
<PropertyGroup>
<WindowsSdkToolchainPlatform>$(PROCESSOR_ARCHITECTURE)</WindowsSdkToolchainPlatform>
<WindowsSdkToolchainPlatform Condition="'$(PROCESSOR_ARCHITECTURE)'=='AMD64'">x64</WindowsSdkToolchainPlatform>
<SignToolPath>$(WindowsSdkDir)bin\$(TargetPlatformVersion)\$(WindowsSdkToolchainPlatform)\signtool.exe</SignToolPath>
</PropertyGroup>
Version bump Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2019-06-07 12:46:48 +02:00
</Project>
Reference in New Issue Copy Permalink