Page 1 of 1

MSI Installer Module issues

Posted: Thu May 17, 2018 1:19 am
by CermakPOI
Product, version and build: PowerShell Studio 2018 v5.5.152
32 or 64 bit version of product: 64
Operating system: 64
32 or 64 bit OS: 64

When we build a PowerShell Module MSI the files are not in the correct Version Folder but in the base path:

Bad:
C:\Program Files\WindowsPowerShell\Modules\MyModule\
Good:
C:\Program Files\WindowsPowerShell\Modules\MyModule\1.1.4.19\

Of course we use the correct Version in all available fields.

If the installer cannot elevate, it should install into the users Module Path:
$env:HOMESHARE\..\WindowsPowerShell\Modules\\MyModule\1.1.4.19\

Could you please correct this behaviour - Thank you!
mod1.png
mod1.png (32.42 KiB) Viewed 1042 times
mod2.png
mod2.png (30.19 KiB) Viewed 1042 times
mod-fs.png
mod-fs.png (27.44 KiB) Viewed 1042 times

Re: MSI Installer Module issues

Posted: Thu May 17, 2018 6:58 am
by mxtrinidad
In my experience, you will only see the code folder version (which is not required if using source control) on a project folder and not part of an application folder, nor a module folder. This can cause confusion to a user on which version to use. It need to be kept in the project folder where you tell the packager and msi from where to build the new version.

Look into our Source control tool SAPIEN's VersionRecall, which simplifies the process of creating backups and maintaining multiple versions of your files.

In my opinion the MSI is working as expected.

Re: MSI Installer Module issues

Posted: Thu May 17, 2018 7:20 am
by CermakPOI
Well, it's standard for Powershell Modules so support multiple Versions! Get-Module will not work correctly otherwise!
I found a solution, by adding this to the WixModuleTemplate.txt and it works as it should!

Code: Select all

<Directory Id="INSTALLDIR" Name="%PRODUCT%">
	<Directory Id="VERSIONDIR" Name="%VERSION%">
%HEATCOMPONENTS%			
	</Directory>
</Directory>
Another question:
i would like to execute a powershell script inside the newly installed application. I tried a custom Action like:

Code: Select all

powershell.exe
-NonInteractive -WindowStyle Hidden -ExecutionPolicy ByPass -File [VERSIONDIR]\install-PODIS.ps1
My problem: i need to know how to specify the [VERSIONDIR] in this dialog!!

Re: MSI Installer Module issues

Posted: Thu May 17, 2018 7:44 am
by mxtrinidad
Yes! PowerShell will support multiple version of the same module. I want to keep things simple or you ended up using module namespace.

I have a lot of issues with different versions of the same modules (AzureRM, SQLPS..). One thing in common, their installed module path is included in the $env:PSModulePath. But, still you'll need to use the module namespace to use the correct cmdlet.

Now, a good example of what you want to accomplished is "AzureRM". I'm thinking that the way the project was created may need to be rethink.

In AzureRM, I see the folder structure been:

.../module/AzureRM/5.2.0

Then, under the version number you'll see both the *psd1 and *psm1 files. Then, try do the packager and msi to see if it will give the proper installation.

:)

Re: MSI Installer Module issues

Posted: Thu May 17, 2018 9:04 am
by davidc
Please file a Feature Request:

https://www.sapien.com/requests

Thank you,

Re: MSI Installer Module issues

Posted: Fri May 18, 2018 12:18 am
by CermakPOI
Well, i solved it myself, so i won't waste your time with a feature request.

For people having the same requirement i post the solution:
Add this to the C:\Program Files\SAPIEN Technologies, Inc\PowerShell Studio 2018\MSIBuilder\WixModuleTemplate.txt

Code: Select all

<Directory Id="INSTALLDIR" Name="%PRODUCT%">
	<Directory Id="VERSIONDIR" Name="%VERSION%">
%HEATCOMPONENTS%			
	</Directory>
</Directory>
In MSI Settings - Custom Actions - Properties
File: powershell.exe
Folder: VERSIONDIR
Arguments:

Code: Select all

-NonInteractive -WindowStyle Hidden -ExecutionPolicy ByPass -Command .\MyPostInstallScript.ps1
This may not jet handle correct result code of yout script - wix doesn't like $, so this does NOT work:

Code: Select all

...ps1 ; exit $LASTEXITCODE