Is there a way to run a [Code] procedure or PowerShell script in the Inno Setup compiler before the installation executable is generated?
You may get better answers, if you explain what you need to run the code for. Anyway...
One way is to compile the script on command-line from a batch file:
powershell -file precompile.ps1
ISCC.exe setup.iss
powershell -file postcompile.ps1
(or you can call ISCC.exe from the PowerShell script itself)
Another way to run some script before compilation is using Exec preprocessor function.
#expr Exec("precompile.bat")
or
#expr Exec("powershell -file precompile.ps1")
See also Is it possible to call a batch file while compiling an Inno Setup script?
If you need a GUI solution, there's ISTool, an Inno Setup extension, that has direct support for Pre Compilation and Post Compilation "Steps". But this project is unfortunately no longer maintained. You might be able to update it to the latest Inno Setup version, as it is open source.
Related
My company has a .NET Powershell module, written in C# to allow advanced users to automate tasks in our product. Currently it targets Powershell 5 using .NET 4.6.1. We would like to allow customers using other operating systems to use it as well, and as it has no OS-specific code, porting it was straightforward.
However, I cannot find documentation on a debugging workflow that should be followed. In standard .NET Powershell, this was quite simple and required a one-time setup procedure:
Configure the debug executable to be the Powershell path
Set debug arguments to be a short script that loads the module and if appropriate, executes the function that is being tested.
Hit F5
However, this doesn't work for Powershell Core. Because the project depends on NuGet packages, the module registration fails with a dependency error. I was able to figure out another workflow but it's a bit more obtuse:
Navigate to the project directory
Execute dotnet publish -f netstandard2.0 -c debug
Execute Import-Module ./bin/Debug/netstandard2.0/publish/MyModule.dll
Execute $pid to find the PID
Attach to the PID via Attach to Process in Visual Studio
This works and I have debugged a few issues with this method, but it's not the most pleasant or efficient way to do it. I believe that there must be a better way that is just not well documented.
I originally came up with a script based approach that you can see in this post's history, but what I didn't know at the time was the CopyLocalLockFileAssemblies property which makes the debug directory look like how it used to look when working on .NET Framework. You just need to add this to your .csproj in a <PropertyGroup>:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Then, the debugging setup is just the same as any other .NET module loaded into a third party application:
Right click on your Powershell module project and click properties
Select Debug
Set Launch to Executable
Executable: C:\Program Files\PowerShell\6\pwsh.exe
Arguments: -NoExit -Command "Import-Module C:\dev\my-module\bin\Debug\netstandard2.0\my-module.dll"
Set your module as the startup project
Hit F5 to begin debugging.
I have a Xamarin.Forms project wherein the Android project is built in VSTS using a hosted build agent which runs a powershell script at run-time.
I need to run the same powershell script against the Xamarin.iOS which uses an On Premise Mac Build Agent. But how?
I found this answer and a comment under the answer also had the same question regarding parameters, so I am posting the solution here since the issue is slightly different and that question has an accepted answer.
First off, I installed powershell on the mac using these instructions and I modified the shell script task to include the Visual Studio Team Services (VSTS) environmental variables that I wanted to pass to the powershell script.
Next, I pass the arguments through to the called powershell script by slightly modifying the shell script mentioned by the referenced answer.
#!/bin/bash
powershell ./Version.ps1 $1 $2
Finally, in the powershell script, I catch the arguments that have been passed through using using param like this:
param([string]$version, [string]$path)
Wherein I can now use the variables $version and $path which contain the original arguments entered in VSTS to the needs of my powershell script.
We have a TFS build process using a custom template. The build works fine with the crm solution files successfully being created. We are then attempting to run a powershell script on the post build. This script imports a module. But the commands in the module are not being exposed. Whenever we attempt to invoke a command, we get an error. Along the lines of
The term 'Get-XrmSolution' is not recognized as the name of a cmdlet,
function, script file, or operable program.
It doesn't matter which command we use in that module, we get the same kind of error.
To troubleshoot, we have logged onto the build server under the identity of the build account and can successfully run the script we are attempting to run.
Putting some more output into the script to troubleshoot...
Get-Module lists Xrm.Framework.CI.PowerShell. - Good.
Get-Command -Module "Xrm.Framework.CI.PowerShell" returns nothing. From the console, a number of commands are listed.
Is there something we need to do with the running of powershell post build scripts to enable the contents of an imported module to be seen?
Watch out for the bitness of PowerShell invoked by MSBuild and likewise, the bitness of MSBuild launched by Visual Studio. Certain modules only run in either 32-bit or 64-bit PowerShell and not both. You want to make sure the correct version of PowerShell is getting launched.
IIRC you have to explicitly import the module with no assumption of being loaded on user profile, nor on the script path.
Suppose Module1.psm1 is in the same folder as your script, use something like
Import-Module (Join-Path (Split-Path -Parent $MyInvocation.MyCommand.Definition) 'Module1.psm1')
I had the same problem.
The module was loaded in the 'C:\Program Files\WindowsPowerShell\Modules' folder (64 bits).
It all seemed fine when I logged on as the user, but it failed during TFS build.
Solution: I had to uninstall the module in PowerShell 64 bit and re-install in PowerShell 32 bit.
The module was then installed in 'C:\Program Files (x86)\WindowsPowerShell\Modules' folder.
Wow do we include a batch file in a msi installer which should run every time the msi is installed?
I'm not sure but it might work if you create a custom action to execute cmd.exe and have the path and name of the batch file as a parameter.
Otherwise you can create a custom action that contains a vbscript file that executes the .bat file (or possibly you can use a vbscript instead of a bat file).
Just be aware that I've heard that some antivirus programs can get a bit nervous if you include scripts in your msi and might make the install fail.
What is the most cross platform way to execute a pPerl script from ant?
Windows does not like the Perl script as the executable. Is there any way other than just running Perl using an OS specific executable and passing the Perl script in as an argument?
Have you considered the ant <exec> command? You can use the os attribute to specify which operating system to use.
The catch would be that you would need a specific call for each known operating system the Perl script will be used on. Its probably safer to do an os check anyway.
Have you tried creating a custom Ant target for calling Perl (let's call it call-perl-script), and the implementation of that task switches to another subtask based on the OS (like call-perl-script-windows, call-perl-script-osx, etc.)?
Something based on this previous question, or this or this?
Windows does not like the Perl script as the executable.
Either you configure windows to execute .pl files (help ftype, help assoc)
ftype PerlScript=perl.exe %1 %*
assoc .pl=PerlScript
or you run the script through pl2bat (happens automatically if you use ExtUtils::MakeMaker to install script). If you use pl2bat, please examine the resulting file and make sure you're satisfied with the results.
you could also use PAR/pp to create an .exe