RFC: Installers overhaul

[sanzoghenzo]

After long thinking and research for possible solutions, I would like to propose a cleanup of the installers situation.
What I would like to see:

• A single installer with all users/current user selection, so that there's no confusion on what installer to download
• potentially a single installer for both cli and full version with component selection - IT admins uses the CLI because is the only documented thing, but they usually don't go through the process of customizing the clones, so the time gained by downloading a smaller installer is totally lost by cloning the repo.

We could get rid of the .MSI and .nuget packages since the Inno Setup exe has CLI options to personalize the installation and the ability to run with or without admin
Obviously we need to document the aforementioned inno setup options and the valid /components values on the wiki, and put a link of that page in the release message.

Alternatively, we can drop inno setup and use WiX Toolkit to create only the MSI package.
This could solve the problems in some corporate environment where the execution of .exe outside specific folders is prohibited.
But for this I/we have to learn how to use WiX and see if has all the feature we need.

Do you see any problem in any of this scenarios?
ccin @jmcouffin @dosymep and @eirannejad , but anyone is welcome to bring insight to the issue!

As a side note, I believe there's an error in the CI/pyrevit set products command: installers GUID must stay the same in order to detect versions of the same app.

[jmcouffin]

• single installer ... ,💯
• having the cli packaged with pyrevit itself. While I understand and agree, I am a bit worried we lose some people in the process
• exe have been asked in the past, but this was far less than MSI, just because of the lock on exe installers in some environments like you mentioned. All in for MSI and WIX... It would be better if we all learn and document in the process
• 'set products' I don't know if this is by design: to be able to install multiple versions of pyrevit (4.8 and 5.0 for example). Day dreaming here, If the WIX installer could offer an option to install wip and release and also take care of a proper cleanup when uninstalled...

Sure you don't want to stay @sanzoghenzo 🙏😨

[dosymep]

WIX it's a simple tool and it's quite possible to make an installer on it
I think it would be a better solution to abandon the old installer and make a single installer in C#

[sanzoghenzo]

Alright then, wix it is... and it makes sense to use a tool that uses dotnet build, so that we need one less thing in the ci toolchain (this also applies to nuke as discussed before!)

Since there's already a wix project for the cli msi I'll leave it as its, but I won't put much effort in maintaining it for all the reason I talk about in the past (to sum up: it is a powerful tool that is overengineered for the day to day work if we make the resolution to limit the flexibility we can't afford to maintain).

to be able to install multiple versions of pyrevit (4.8 and 5.0 for example

I might be wrong, but with the current full installer it is not possible because you can't choose the install dir, and the target directory is always the same. Should we use the "pyrevit " folder from now on? But then again, the CLI and all the clones/attachments logic would become another "hell" to manage

[sanzoghenzo]

WIX it's a simple tool

It might be simple, but the documentation is horrible 😟

• The official documentation is a collection of advanced-level documents that take the basics for granted; developers are passive agressive when faced with this truth
• The tutorial on FireGiant stops at the very basic functions (add a file to the package, check the environment and display error messages if not compatible)
• The wix cookbook is not free and it is outdated (covers v3, we're now at v5)

Anyway, I see that both RevitLookup and RevitAddinManager use WixSharp (they also use nuke for CI!) that lets you create the installer using a c# script instead of declarative XML files.
At first sight, documentation looks good and they have a lot of examples.
Should I go through that rabbit hole?

[jmcouffin]

Should I go through that rabbit hole?

It looks fine.

• I am seeing it is supporting WIX4+ at best I guess this is fine for us.
• It does not look terribly complicated at first sight (but obviously, never trust your first sight!)

Do it, if you feel like it!

[dosymep]

Should I go through that rabbit hole?

yep, I use WIXSharp
https://github.com/Bim4Everyone/Bim4EveryoneSetup

[sanzoghenzo]

Tried WixSharp, stumbled on errors right from the start using the templates.

Runing the example, I got a NullReferenceException because it cannot find the "program.cs" file. I understand this is a simple directory path problem, but for the life of me I cannot find any info on how should I specify the paths when using new File if I want to keep them relative (absolute paths are a no go for obvious reasons).

Already wasted half of my sunday, I give up.

[jmcouffin]

program.cs

In @dosymep example it is here
https://github.com/Bim4Everyone/Bim4EveryoneSetup/blob/master/src/BIM4EveryoneSetup/Program.cs

[thumDer]

Roman's template has a nice example of WixSharp config, but that is not the simplest one. Our internal addin also uses wixsharp so I could help with the transition.

[sanzoghenzo]

We are in need of this overhaul ASAP!

We don't check if .net 6+ is installed, but pyrevit cli, that is called at the end of the installation process, needs that. #2730

The CLI can error out in other ways, but no error comes up in the installer.
Today my colleague had a spurious pyrevit_config.ini in the ProgramData folder (from an administrative install that nobody remembered), and the CLI (from the regular user installer) could not access that file.
The result was a successful installation with no clones and no attachments, which led to a panic mode call to yours truly 😅