Closed rozmansi closed 4 years ago
@rozmansi looks good afaics but did not test this yet. A couple of questions...
Was the removed of devcon build instructions intentional? I believe it should not be removed as we will have to keep maintaining NSIS installer process for 2.4.x[*] for some time and building devcon.exe (or using a pre-build binary) is still necessary there.
Also - now that we have this MSM - do we want to "rock the boat" by merging the NSIS installer changes you made earlier:
I'd say no, because the OpenVPN NSIS + tap-windows6 installers are working fine now for OpenVPN 2.4.x for all platforms (Win7/10 i386/amd64/arm64). That said, I may have forgotten some details by now. Based on the GitHub comments I don't think I ever got into testing the above PRs on my Windows 10 ARM64 laptop. I can do that if we decide merging them is worth it.
Btw. I noticed that the ARM64 issue you mentioned has been fixed and the fix is included in WiX v3.14.0.3910.
[*] Based on the lengthy discussion in PR https://github.com/OpenVPN/openvpn-build/pull/141 it seems like the MSI could handle upgrades from NSIS cleanly, even from ancient OpenVPN versions, but for a stable 2.4.x release changing the packaging system seems excessive.
Was the removed of devcon build instructions intentional? I believe it should not be removed as we will have to keep maintaining NSIS installer process for 2.4.x[*] for some time and building devcon.exe (or using a pre-build binary) is still necessary there.
I didn't realize you plan to keep using NSIS TAP-Windows6 installer. As I mentioned in the readme, all 3rd party vendors should switch to MSM/MSI if they are deploying the original unmodified "tap0901" driver - because of the reference counting. Otherwise, applications will interfere, each believing it holds the exclusive ownership of the installed resource: namely tap0901 driver.
Also - now that we have this MSM - do we want to "rock the boat" by merging the NSIS installer changes you made earlier:
* [installer: Refine the WoW64 decision logic](https://github.com/OpenVPN/tap-windows6/pull/98)
This one should make more appropriate arch detection (for the ARM64 platform). Should be tested on ARM64 to confirm it works.
* [installer: Select Win7/8/8.1 vs. Win10 driver at runtime](https://github.com/OpenVPN/tap-windows6/pull/99)
This patch makes things more convenient: it makes the TAP-Windows6 NSIS installer one-EXE-file-for-all-Windows-releases once again. Merge at your discretion.
* [installer: Add code signing certificate before installing the driver](https://github.com/OpenVPN/tap-windows6/pull/100)
This patch makes things more convenient too: it suppresses the trust prompt in Windows 7-8.1, Server 2008R2-2012R2. Merge at your discretion.
I'd say no, because the OpenVPN NSIS + tap-windows6 installers are working fine now for OpenVPN 2.4.x for all platforms (Win7/10 i386/amd64/arm64). That said, I may have forgotten some details by now. Based on the GitHub comments I don't think I ever got into testing the above PRs on my Windows 10 ARM64 laptop. I can do that if we decide merging them is worth it.
Your call.
Btw. I noticed that the ARM64 issue you mentioned has been fixed and the fix is included in WiX v3.14.0.3910.
True. However, I cannot give you an exact time when I will be able to look into it.
[*] Based on the lengthy discussion in PR OpenVPN/openvpn-build#141 it seems like the MSI could handle upgrades from NSIS cleanly, even from ancient OpenVPN versions, but for a stable 2.4.x release changing the packaging system seems excessive.
I've used 2.4.x versions in 2018 for MSI testing. As the file, folder and registry names are the same for 2.4 and 2.5, there is no change required to the MSI structure. In other words: MSI version is just a number - just make sure it matches the OpenVPN you are packaging.
Was the removed of devcon build instructions intentional? I believe it should not be removed as we will have to keep maintaining NSIS installer process for 2.4.x[*] for some time and building devcon.exe (or using a pre-build binary) is still necessary there.
I have removed the commit that did this.
MSM packaging works well with MSI. There may or may not be an issue with how Windows 10 ARM64 platform is handled, but I have not yet verified if it is a packaging problem or a genuine bug. Nevertheless, that can be fixed in a separate PR.
This PR introduces MSM (Microsoft Installer Merge Module) packaging of the TAP-Windows6 driver.
MSM produced is a clone of the Wintun installer adapted for TAP-Windows6.
Features:
The ARM64 platform is not supported at the time being. The source code and build process are mostly ARM64-ready, but the official WiX Toolset does not support it yet. Fortunately, they are working on it.
Note, this PR updates the README.rst file with the proposed new release workflow. As described in the updated documentation, we should no longer release the driver as an inf+cat+sys bundle or using the NSIS EXE installer. Those means do not have any reference counting and 3rd party vendors should not redistribute them.