-
-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Installers overhaul #2519
Comments
Sure you don't want to stay @sanzoghenzo 🙏😨 |
WIX it's a simple tool and it's quite possible to make an installer on it |
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).
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 |
It might be simple, but the documentation is horrible 😟
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. |
It looks fine.
Do it, if you feel like it! |
yep, I use WIXSharp |
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 Already wasted half of my sunday, I give up. |
In @dosymep example it is here |
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:
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.The text was updated successfully, but these errors were encountered: