Skip to content
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

DSL-extension for MSI installation directory? #58

Open
mithomas opened this issue Jun 11, 2018 · 6 comments
Open

DSL-extension for MSI installation directory? #58

mithomas opened this issue Jun 11, 2018 · 6 comments

Comments

@mithomas
Copy link

When using SetupBuilder for packaging MSIs we almost always have the requirement of specifying the installation directory by directly specifying <Property Id="INSTALLDIR" Value="C:\PathToInstall"/>.

I propose the addition of a parameter installDir for the MSI task to set this directly in build.gradle.

Usage would then be like so:

msi {
  from "bin"
  include "**/*"

  installDir = 'C:\PathToInstall'
}

If this proposal is accepted, I would take care of the implementation.

@mithomas
Copy link
Author

Another viable option would be to generalize this to allow any property:

msi {
  property {
    name = "name"
    value = "value"
  }
}

@Horcrux7
Copy link
Member

Why you want not use the default install path? It is not recommended to install in the disk root.

I think the follow syntax is simpler:

msi {
  property 'name', 'value'
}

or

msi {
  properties = ['name': 'value', 'name2': 'value2']
}

internally its should be saved in a map.

And which problem do you have with the WXS template file? The target of SetupBuilder plugin is to create a simple native installer for different platforms. It was never the target to handle all the features of WIX.

To understand which properties a user can set he must understand WIX. But then he can use the template self. The properties in a Gradle script should be understandable without WIX. If we add it then I prefer a directly property "installDir".

@mithomas
Copy link
Author

I am quite aware of the original mission of the plug-in, and yet it is by far the most sophisticated way of using WIX from Gradle and to my knowledge the only one mapping any of the complexity of WXS files to a Gradle DSL. From various discussions on the net I also notice that a lot of people do not use it to generate installers for cross-platform applications but specifically for building MSIs. Both points led me to make my proposal here, since those folks (including myself) might benefit from it.

I am also aware that this proposal does not benefit the other platforms (then again, neither do the settings for languages, signtool or architecture), so if you choose to reject it for not fitting the overall vision of this plug-in, I completely understand - still I thought I'd ask at the place I deemed most fitting :-). (In this case, factoring out the WIX part to a separate plug-in might not be the worst idea from an architectural point of view - then however the SetupBuilder plugin should probably depend on that to avoid duplication of functionality.)

My driver for getting rid of the WXS file is that we have a rather large number of small projects each one generating an MSI package for a specific embedded system and the only reason to keep a WXS file around for most of them is a custom default installation directory (required due to the nature of said embedded system). Moving that into the build file itself would ease maintenance since all relevant info is in one place and avoid repeating the WXS boilerplate code in each project.

@gamma
Copy link
Member

gamma commented Jul 9, 2018

Can values be maps them selves? If you could provide a PR we'd happily review and merge it. I think it should be as transparent as possible which values are allowed and valid. The drive for the SetupBuilder is to take complexity away.

@tlf30
Copy link

tlf30 commented Nov 24, 2020

Any progress on this?

@Horcrux7
Copy link
Member

There is no progress.

It is currently recommended that you use the WXS template file for all the Wix-specific settings. There are thousands options possible. If this is not possible or not acceptable for you then you can make a pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants