[Windows] Compare installation toolsets

[AenBleidd]

There are 3 possible candidates to be used to create new Windows Installer:

• InnoSetup: https://jrsoftware.org/isinfo.php
• NSIS: https://sourceforge.net/projects/nsis/
• WiX Toolset: https://wixtoolset.org/

It's required to compare these 3 solutions and choose one that will fit best for BOINC.

Comparation matrix

Requirement	InnoSetup	NSIS	WiX Toolset
Free of charge	✔️	✔️	✔️
In active development and has at least 1 release per year	✔️ 2023-12-15	❌ 2021-09-25	✔️ 2023-04-06
Has no major security issues	❌	❌	❌
Is able to create native x64 and native arm64 installers without emulation	❌	❌	✔️
Is able to call functions from the custom dll during installation	✔️	✔️	✔️
Is able to generate MSI	❌	❌	✔️
Is able to run embedded installer (VirtualBox in our case) during installation	✔️	✔️	✔️
Supports installation parameters via cli	✔️	✔️	✔️

Legend

Sign	Meaning
✔️	Passed
❌	Failed

[talregev]

What is missing for this task?

[AenBleidd]

What is missing for this task?

Toolsets comparation and final decision which one to use

[Frigyes06]

InnoSetup: Pretty easy and straightforward for simple stuff. Doesn't appear to have command line interface to compile installer with script. Seems to be Pascal oriented?
NSIS: Widely used and supported, has a straightforward scripting language. Can compile installer from a windows command prompt.
WiX Toolset: Integrates very well with the .NET framework, especially MSBuild SDK. Can be run from the command line. Linux support exists, but is experiencing some issues. See: wixtoolset/issues#4381

All three tools have great documentation, although I found NSIS and WiX documentation easier to navigate and understand than InnoSetup.

In my opinion WiX Toolset would be the best for BOINC, as we use Visual Studio, and WiX is supported trough HeatWave extension.

[talregev]

InnoSetup: Pretty easy and straightforward for simple stuff. Doesn't appear to have command line interface to compile installer with script. Seems to be Pascal oriented? NSIS: Widely used and supported, has a straightforward scripting language. Can compile installer from a windows command prompt. WiX Toolset: Integrates very well with the .NET framework, especially MSBuild SDK. Can be run from the command line. Linux support exists, but is experiencing some issues. See: wixtoolset/issues#4381

All three tools have great documentation, although I found NSIS and WiX documentation easier to navigate and understand than InnoSetup.

In my opinion WiX Toolset would be the best for BOINC, as we use Visual Studio, and WiX is supported trough HeatWave extension.

Preferable tool that can compile and create on the ci.
If you have some examples, that will be great.

[Frigyes06]

I can try to craft up examples. Not today though. Would you like one for each or just for WiX? I'm not sure if InnoSetup is CI compatible at all :)
Also @AenBleidd mentioned having a working demo of NSIS? (#3194)

[AenBleidd]

@Frigyes06, thank you for the input.
Please hold on with this ticket.
There are some more requirements that should be met to choose any particular toolset.

Yes, I have a simple sample of NSIS but I doubt we will use it.

@talregev, all three toolsets could be built on ci.

[talregev]

There are some more requirements that should be met to choose any particular toolset.

Can you specify all the requirements for the toolset?
It should be along with this ticket, specify them on the first comment.

[AenBleidd]

Can you specify all the requirements for the toolset?

I don't have a complete list of requirements for now, so when I have it - I update this ticket.
I have no time yet to research and have a clear understanding which requirements are important and which are not.

[AenBleidd]

Ok, requirements are there. I hope I didn't forget anything important.
If someone decides to work on this ticket, please don't forget to put a link that proofs every ✔️ and/or ❌. In the best case this should be a link to the documentation section (or a quote from it with the link to the page if it's not possible to put a direct link to the documentation section).

[talregev]

@AenBleidd Thank you. Please also put issues that we want to solve that the new installer should hold.
For example, this issue: #5118

@Frigyes06 Are you interesting to do this research?

[AenBleidd]

@AenBleidd Thank you. Please also put issues that we want to solve that the new installer should hold. For example, this issue: #5118

Please check #5066

[talregev]

@AenBleidd Thank you. Please also put issues that we want to solve that the new installer should hold. For example, this issue: #5118

Please check #5066

I see you include #5118 as almost the last in this long list. This issue need to investigated in the research part, and not in the end. Also we need more issues like it that are important to boinc. Please make that list. Thank you.

[AenBleidd]

I see you include #5118 as almost the last in this long list.

These issues are not ordered. This is just a list. Last doesn't mean has less importance.

This issue need to investigated in the research part, and not in the end.

In any case this is not a top priority issue. Also, it's actually not related to the installer script itself but to the custom dll that is run from the installer. And since it's currently not known whether we will keep existing dll or completely replace it (in case the new installation toolset won't be able to call functions from the dll during installation and this is the only disadvantage of it).

Also we need more issues like it that are important to boinc. Please make that list. Thank you.

This list is already in #5066. Everything else could be added later while working on the new installer.
We try to stick to the agile, not to the waterfall, so we don't require all tickets to be created and discussed before start working on the topic.

As you understand, the prio one task is to convert existing installation script to the new toolset keeping all or almost all existing functionality. We have no outdated settings there, so we need to preserve them all for smooth user experience: in the best case user should not mention that they are running a new installer.

[talregev]

I see you include #5118 as almost the last in this long list.

These issues are not ordered. This is just a list. Last doesn't mean has less importance.

This issue need to investigated in the research part, and not in the end.

In any case this is not a top priority issue. Also, it's actually not related to the installer script itself but to the custom dll that is run from the installer. And since it's currently not known whether we will keep existing dll or completely replace it (in case the new installation toolset won't be able to call functions from the dll during installation and this is the only disadvantage of it).

Also we need more issues like it that are important to boinc. Please make that list. Thank you.

This list is already in #5066. Everything else could be added later while working on the new installer. We try to stick to the agile, not to the waterfall, so we don't require all tickets to be created and discussed before start working on the topic.

As you understand, the prio one task is to convert existing installation script to the new toolset keeping all or almost all existing functionality. We have no outdated settings there, so we need to preserve them all for smooth user experience: in the best case user should not mention that they are running a new installer.

You didn't explain why we don't need to make an effort and invest time in research to see if new installer will solve the known bugs.
Even if this task is low priority it doesn't mean that we don't need to do it in professional way.

Everything else could be added later while working on the new installer.

Try to fix know bug after you choose a installer it much harder. This is not connected to agile or waterfall. In both system you need invest time to choose the right tool for the job. Known issues is a great starting point.

[AenBleidd]

You didn't explain why we don't need to make an effort and invest time in research to see if new installer will solve the known bug. Even if this task is low priority it doesn't mean that we don't need to do it in professional way.

Try to fix know bug after you choose a installer it much harder. This is not connected to agile or waterfall. In both system you need invest time to choose the right tool for the job. Known issues is a great starting point.

Because this issue is not related to the installer. And while choosing the proper toolset you should not consider existing bugs in existing installer but rather stick to the general requirements that are listed in the first comment.
This existing bug could be solved even in the old installer, but since we plan to move to the new one, I see no reason to invest any time trying top fixing it now.
And it will take exactly the same time to fix it in the new installer (maybe even during the development phase and not as a separate ticket) as in the old one.
You want to investigate existing issues - go ahead.
But when you develop something new to replace something existing - you should forget about existing issues and focus on the new functionality / new architecture / new UI/UX / etc.
This is a basic principle of software designing.

[talregev]

Because this issue is not related to the installer.

I am talking to add similar known bugs that important for the research , not this issue itself.

You want to investigate existing issues - go ahead

You are the maintainer of this repo. You are know better than me what is important to boinc. Also you are the one that go all over the issues and categorize it. You know better then anyone whats issues are good to investigated to this research and you should add them.

Also known issues is just part of the research. Also needed the requirement as you specify.

[AenBleidd]

I am talking to add similar known bugs that important for the research , not this issue itself.

All these issues are listed in #5066.
Yes, it's possible that I missed some related tickets, and I'll recheck this once, but currently while doing research for the new installation toolset you should consider only requirements, and not existing issues. Reasons are already explained above.

[talregev]

I am talking to add similar known bugs that important for the research , not this issue itself.

All these issues are listed in #5066. Yes, it's possible that I missed some related tickets, and I'll recheck this once, but currently while doing research for the new installation toolset you should consider only requirements, and not existing issues. Reasons are already explained above.

This is mixed from task that need to do with some known issue. I recognize only one. That why we should only the known issue to this issue.
If all of them are in #5006, you should add them to here to be more clear.

[AenBleidd]

If all of them are in #5006, you should add them to here to be more clear.

Ok, I'll repeat this the third time: while doing research to choose new installation toolset you should stick to the requirements only and forget about existing issues of the current installer. Is that clear?

[talregev]

If all of them are in #5006, you should add them to here to be more clear.

Ok, I'll repeat this the third time: while doing research to choose new installation toolset you should stick to the requirements only and forget about existing issues of the current installer. Is that clear?

I already explain why is it important to have also the known issues in the research for the new installer. You are proposing non professional way.

[Frigyes06]

@AenBleidd Thank you. Please also put issues that we want to solve that the new installer should hold.
For example, this issue: #5118

@Frigyes06 Are you interesting to do this research?

Yeah, I can do this. I estimate it will be done by wednesday.

[AenBleidd]

I already explain why is it important to have also research the known issues for the new installer.

If you want - you're free to do that.

You are proposing non professional way.

This is your personal opinion. If you want to do this task your way - I can't stop you from doing that.

For me to make a decision about the next toolset we will use for BOINC - is to met requirements I listed in the first message.
All other issues will be solved during the development because they are not related to the chosen toolkit but just a bugs in the existing implementation. And even more: these are just bugs in our code, not something that exists in the toolset itself.

[talregev]

@AenBleidd Thank you. Please also put issues that we want to solve that the new installer should hold.
For example, this issue: #5118
@Frigyes06 Are you interesting to do this research?

Yeah, I can do this. I estimate it will be done by wednesday.

Thank you!

[AenBleidd]

Yeah, I can do this. I estimate it will be done by wednesday.

Take your time: sometimes it's better to spend more time to make the best decision

[tristanolive]

It might not be a hard requirement, but InstallShield is set up to digitally sign the executables included in the installer (boinc.exe, boincmgr.exe, etc). Worst case, this could probably be scripted independently, but it would be nice if the toolset included some level of integration.

Otherwise, I think the list of requirements looks pretty good. I'll be glad to take part in some testing of toolsets once we get there. I build some custom installers for account managers, but generally they don't stray too far from following the standard BOINC process.

[AenBleidd]

Executables inside installer are already signed with Visual Studio.
That is why this is not a part of the requirements list.

@tristanolive, I'll let you know when we have something to test. Thank you for your help.

[tristanolive]

Right you are, InstallShield only signs the additional files that it is producing. I'm not sure what the purpose would be of some of that; files such as "D.tmp" or "certificate.msi". The final step of signing the installer itself would still be significant, but that is easy to do manually. Thanks for setting the details straight!

[AenBleidd]

According to the comparation table, the best tool to use is WiX Toolset: https://wixtoolset.org/