I am using VisualStudio2005 and a vdproj to create a simple MSI file. I need to pass in the REINSTALLMODE property when I launch it.
I know this can be done via command line, like so:
msiexec.exe /i foo.msi REINSTALLMODE=amus
However, if a user chooses to click the msi directly (launching the wizard), the property is not passed. Is it possible to do this via the VS and vdproj?
Some options I've investigated:
When I build the MSI via VS, it also produces a setup.exe. Is there a way to pass the REINSTALLMODE property through this maybe?
I installed Orca, which allows me to view/edit the Property table of the MSI. I could add it this way, but then I'd have to add it every time I do an MSI build.
Thanks for any advice.
I found a more automated way to do this.
Create a script named add_reinstall_prop.vbs(example) with the folowing:
set objArgs = WScript.Arguments
set o_installer = CreateObject("WindowsInstaller.Installer")
set o_database = o_Installer.OpenDatabase(objArgs(0), 1)
s_SQL = "INSERT INTO Property (Property, Value) Values( 'REINSTALLMODE', 'amus')"
set o_MSIView = o_DataBase.OpenView( s_SQL)
o_MSIView.Execute
o_DataBase.Commit
Add a post-build event to your setup project calling the script with the following:
add_reinstall_prop.vbs $(BuiltOuputPath)
This will automatically add the desired entry to the built MSI.
You can then check it with Orca to see the entry is now added automatically after build.
Sadly, I can't find a way to set other MSI properties right in VStudio.
Nonetheless, one method that should work is this:
Use Orca to create a transform (MST) that only change the property REINSTALLMODE. (In short, you edit the property & save as a new transform, then use the "Generate Transform" command to create the MST.)
This transform can be applied directly to your MSI using the MSITRAN.EXE command (available in the same Windows Installer SDK where you found Orca).
You could either:
(a) find a way to have Visual Studio always run your MSITRAN command immediately after the MSI build, or
(b) just run your MSITRAN manually (from a batch file or such) after building but before testing.
Related
I am trying to configure dymola.mos file, here is an example of changing directory, but when I activate Dymola, it seems the working directory doesn't change at all, even though the log shows Dymola run the script.
My question is:
How could I make the cd command work in the dymola.mos file?
I assume you have activated the option Save startup directory. You can check this with the flag Advanced.StartupDirectory, which will be either 1 or 2. You can simply turn that off or follow the steps below.
From your command log we see that:
Dymola first executes the script <install-path/insert/dymola.mos
Then it restores the settings stored in setup.dymx
Hence the settings in setup.dymx override your working directory.
Instead of using <install-path/insert/dymola.mos you should use a custom .mos script, which is passed as first argument to dymola.exe on startup. This will always be executed last.
Example for Windows
Create the file startup.mos somewhere, e.g. in C:\dymola\startup.mos
Create a shortcut to Dymola.exe, (for Dymola 2021x: C:\Program Files\Dymola 2021x\bin64\Dymola.exe)
Add the .mos script as argument in the Target field in the properties of the shortcut. The result will be:
"C:\Program Files\Dymola 2021x\bin64\Dymola.exe" "C:\dymola\startup.mos"
I have a Jenkins build with one parameter called VERSION.
Based on the length of the variable i am modifying its value in Windows Powershell and then in the next build step, i want to use it.
But the modified value is not being reflected in the next build step execution, it still refer to the intial value entered as a parameter. I tried ENV,script,global none of them seems to work.
Windows powershell build step
input VERSION=1810(via jenkins build)
if ("$ENV:VERSION".length -eq 4)
{
$ENV:VERSION = "$ENV:VERSION",3 -join "" (here it will be 18103)
}
Write-Output "$ENV:VERSION" (18103 here aswell)
later in the Nexus artifact uploader i refer to this variable as ${VERSION} and the above updated value is not being reflected
(here it is 1810 and not 18103)
Please help
This is a general issue with environment variable scope. Every process inherits the environment variables from its parent, but has its own copy, and any modifications you make will only be reflected in the current process and child processes.
I think you will have to find some way to pass the value to a future step that doesn't rely on environment variables.
You can try to use EnvInject Plugin and set additional PROJ_VERSION=$ENV:VERSION variable in your job. In this case it should be working correctly. If it isn't working within Properties Content directly, try to use injection via file as in this example.
I found another option which works in Freestyle project jobs.
the 1st powershell step:
[Environment]::SetEnvironmentVariable('IMAGE_VERSION', $imageVersion, 'Machine')
the 2nd powershell step:
$imageVersion = [Environment]::GetEnvironmentVariable('IMAGE_VERSION', 'Machine')
I am trying to add new Environment variable in my windows 10 system , i am using below powershell command to add System variable
$env:ITH_PYTHON_PATH = 'C:\Python27\Python.exe'
i can see command is successful in adding the new values, and i can get back value when i use command $env:ITH_PYTHON_PATH.
I cannot see updated path when i manually go to the system property Environment variable
After reboot $env:ITH_PYTHON_PATH is also not seen.
Is there any better way to add environment variable permanently?
Would something like this work?
[Environment]::SetEnvironmentVariable("ITH_PYTHON_PATH", "C:\Python27\Python.exe", "Machine")
I am using advanced installer 10.7.1. I am adding the custom action of 'run windows powershell script'. What this script does is to check if the installer is being run on an azure vm or not. if it is, only then does it allow the user to install. The script runs fine on the vm, I've checked it. but now I need to display an error message on the basis of a script's result. which means I have to set some property in the script, on the basis of which I will display the error message.
can anybody tell me how to set advanced installer's property through a powershell script.
This is limitation of Windows Installer, not of Advanced Installer. PowerShell does not have access to the Session object of the installation, so you cannot set/get properties from a powershell script into an MSI, no matter the tool used to build the MSI.
The only custom actions that can be used to set a property (scheduled as immediate of course), are VBS scripts (inline or attached files) or DLLs written in C++ or C#. In C# is much easier as you have access to a lot of .NET API (but you also have the requirement of the .NET Framework to be on the end user machines).
#ravikanth
It takes only script text and there is no associated action based on the return value. Weird!
This is how Windows Installer works, i.e. the technology against which all MSI packages are built. More specifically, custom actions running into an MSI cannot use the return code to communicate "what ever they want" with the main installation progress. Windows Installer accepts only a strictly defined set of return codes, in the case of PowerShell custom actions in Advanced Installer, the return code is controlled in the background by the installer.
The scenario in which PS scripts are used in installations is that users usually need to them to make certain configurations on the machine, to prepare it for the installation. (like installing/activating Windows components, configuring network credentials, etc...) For very well and powerfully integrated custom code in the installers DLLs should be used as custom actions, as they provide a full cycle of communication (can get and set properties) and also can be debugged nicely into an IDE (by attaching to the installation process).
I don't know how Advanced Installer works but you can always return a value from the script and then use that value in the caller. For example,
#Custom Script action
#Get the VM details
If (AzureVM) {
$true
} else {
$false
}
Once you have the result from the script, use that to switch the path of installation or display messages.
For Future Reference:
Setting a property value from a script (for immediate custom actions)
To set a property simply include a line with the following syntax in your script:
AI_SetMsiProperty YOUR_PROP <VALUE>
Where YOUR_PROP is the property and <VALUE> is the value assigned to it.
NOTE: This only works with script that are set to run immediately.
I have an installscript project (non MSI), which is in multi-instance mode.
In most cases, the setup.exe will be launched from command line in silent mode.
Then, new versions of the program will be generated, and we may have to update som instances that are already installed on the machine.
The problem is that i don't know how to select which instance I want to update from cmdline (in silent mode).
Is there a way to do this ?
I've noticed that there is a /ig switch, that enables me to use a specific instance GUID, but it does not seem to let me select an instance by its guid...
I found it.
To update a specific instance you need :
a record file correspondig to update mode (to get it, you have to run the setup.exe with cmdline in record mode : setup.exe /r /f1"/full/path/to/your/recordfile.iss"
The GUID of the instance you want to update : this guid is contained in the installscript "INSTANCE_GUID" variable. You can write it into a file during the installation of your instance.
Then, you can update the instance with the following command line :
setup.exe /r /f1"/full/path/to/your/recordfile.iss" /ig"{your-guid-goes-here}"
this did the trick for me.