Need configuration information added to .CONFIG file at MSIX install time.

[harlin000]

I have a .NET application that has a client and a server component.  The client component needs to know where the server component is located, i.e. machine name and port.  This information varies according to the customers that have purchased this application.  My current client installer is a .MSI file.  This installer will prompt the user for the server machine name and port, edit the .CONFIG file, and install the updated .CONFIG file.  If a silent install is used, then the information is passed in as properties.

Is there a way to create a MSIX package that allows the user to input this configuration information and update the .CONFIG file when the MSIX package is installed?

[#2 · Accepted solution]

Hi,

It’s not possible during install to achieve this. However, using the PSF, you can add a custom script (powershell) to run before opening the application.

Take the desired input from the script and change the file. If the file is present in the installation directory, you must also create a redirect for it in the appdata of the app.

In Advanced Installer we have a special section for the PSF called AppCompat where you can achieve this.

[#3]

@harlin000 

If the app is also under active development we recommend moving to a first launch action as opposed to a script.

John.

[#4]

I am in active development. Thanks.

[#5]

@harlin000

A first run option is not always equivalent to an install option in the enterprise.  In that environment an IT Admin performs/prepares the install and end-users perform that first run.

For the first run option, since you are in development you can just implement that in your code if you want.  Otherwise, using PsfLauncher and a first run script option to prompt will do.

For something the end-user never sees in that enterprise environment, the MSIX way to do that will be for the Enterprise Admin to create a Modification package containing the answers. If you store the answers in a file, the modification package would just contain a copy of the file (however the file must be located in a VFS path in your package).  If you store answers in the registry, then they just put those reg settings in their modification package.  The package is deployed and the modification package is also deployed to the end-user.  When you update the primary application, as long as the info/locations don't change, the same modification package should work for the customer without having to touch it.

Even if you choose the first-run method, you should consider if the Enterprise scenario can be used.  Any first-run method usually places a turd in the registry/filesystem to indicate it has already run.  In that case, you can implement the first-run, and if the Enterprise IT creates the modification package they can include the turd.  You just have to document this to them and they have to RTFM.