I am building a windows installer which installs ElasticSearch as a windows service. To do that I need to set JAVA_HOME environment variable as SYSTEM vairable to JRE folder inside ElasticSearch using the following component in wix:
<Component Id="JAVAHOME" Guid="">
<CreateFolder />
<Environment Id="JAVA_HOME"
Action="set"
Part="all"
Name="JAVA_HOME"
Permanent="no"
System="yes"
Value="[ELASTICSEARCH]jre"/>
</Component>
However, this variable might have been set to a different path prior to installation. To avoid the conflict, one solution which I could think of is to set this environment variable to a different user. I found this link Adding user in wix which potentially enables me to create a user (e.g. ElasticUser). Utimately I would like to install ElasticSearch service under this user account. I am wondering how could I add JAVA_HOME to this user? Any solution including writing C# program as a custom action is appreciated or running a specific command is appreciated?
Related
I am trying to set the PATH environment variable for a web app I am building in Azure in python. I tried to use something like os.environ.setdefault('PATH', 'pandoc-2.14.1-1-amd64.deb') locally, however this does not seem to work once uploaded. I have also tried setting the path in the configuration section on the azure portal, but get the following error:
I have seen posts like
setting the webapp %PATH% environment variable in azure.
The post recommends adding a file called applicationHost.xdt to the home/site directory, which should set the PATH variable automatically. However, I am unable to upload applicationHost.xdt to the files in the directory. This is either because the file UI interface no longer exists, or I am unable to access it. Has the ability to upload via the UI been discontinued?
The only other workaround I can think of is to use echo/cat in the Kudu bash shell to create the applicationHost.xdt manually. This is very tricky. Are there any online tools that, given an input of the contents of a file, create the bash script to generate that file from scratch?
You could add a App settings to you web app, like below:
Then, restart your web app, in Kudu console, you could check it.
Note: App setting names must be unique, so when you use PATH as key it is already configured while deploy so while using in App setting from portal use a different Key name.
As a workaround, you can achieve that through an XDT Transform (XML Document Transform).
Yes, you can use echo to create the same. Simple copy paste the content of the file to be inside single quote ' and stream it into the file already created using echo command.
/home>echo '<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<system.webServer>
<runtime xdt:Transform="InsertIfMissing">
<environmentVariables xdt:Transform="InsertIfMissing">
<add name="FOO" value="BAR" xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
<add name="PATH" value="%PATH%;%HOME%\BAR" xdt:Locator="Match(name)" xdt:Transform="InsertIfMissing" />
</environmentVariables>
</runtime>
</system.webServer>
</configuration>' > applicationHost.xdt
Verify the contents using cat command
I want to deploy my app with an wix based installer and also want it to be available in the Command line, so that I can call my app after installation just like this:
C:\> myApp "Some parameters"
I know that I can achive this by adding my installation directory to PATH, but I need a bit more.
I would like to call my app by another name, for example my app is named like
MyApp.Cli.exe
and for a few reasons I would like to keep that naming scheme in the install folder. But on the command line I would like to call my App like
C:\> MyApp
instead of
C:\> MyApp.Cli.exe
Any ideas how to achive this? Thank you a lot for any help.
App Paths: I suppose you can try App Paths? It is an alternative to updating the PATH variable. I don't think it works via the command line, but it works in the Windows Shell - or in other words when you do Windows Key + R and type in "YourAppName" (without the quotes), then you run the right application without updating the systems PATH variable.
Reminder: Remember to test on all OS versions you intend to support!
Note on WiX:
Sidenote: The WiX toolkit does something interesting. It adds its own environment variable WIX and sets it to the path of the
toolkit's installation folder. Hence you can do this in scripts and
the cmd.exe window: "%WIX%bin\candle.exe" in order to launch the binary in question (candle.exe, light.exe, etc...).
App Paths, Registry: In the registry your App Path would look something like this:
[HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\MyApp.exe]
"(Standard)\Your Path Here\Your Path Here\MyApplicationFullName.exe"
Actual reg-file:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\DaTool.exe]
#="C:\\Program Files\\My Tools\\DaFullNameOfDaTool.exe"
WiX Markup: Running heat.exe reg MyRegExport.reg -out MyWiXFile.wxs -sfrag -suid to convert the exported *.reg file to WiX markup yields something like this (not tested, please adjust as appropriate - just a generalized idea of how to do this):
<Component>
<RegistryKey Key="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\DaTool.exe" Root="HKLM">
<RegistryValue Value="[ProgramFilesFolder]DaFullNameOfDaTool.exe" Type="string" />
</RegistryKey>
</Component>
Command Line: It seems it works to use the "start" command from a command line window:
start datool
But it does not work to just go datool. Didn't test much, have a play with it?
Links:
How the App Paths Registry Key Makes Windows Both Faster and Safer (Helge Klein)
Application Registration
Modify user and system variables in Visual Studio 2017 installer
"Register" an .exe so you can run it from any command line in Windows
I've inherited a project that uses WIX Toolset (3.10.3) to build the installation package. The application downloads and stores shared data in c:\ProgramData\Vendor\ApplicationName. This path is however not created during the installation, but rather during the execution of the application itself, whenever the path is requested for the first time.
I've now discovered a permissions related problem that occurs when multiple Windows users uses the application. Whenever the application downloads new data files from back-end, it's the current windows user that gets "Full control" permissions for those files. When someone else logs in with another Windows account, they only have read permissions to those files. And these mixed permissions causes problems when the application tries to keep the local files synchronized with back-end.
Since the application doesn't require elevated priviliges, I have to correct this during the installation. As a first step, I've now made sure that the c:\ProgramData\Vendor\ folder is created during installation, and that it gets correct permissions with <util:PermissionEx User="Everyone" GenericAll="yes" />. Since these permissions are inherited, it will solve the problem for all users doing a fresh install.
The problem is that the permissions are only inherited by folders/files created after the installation. This means that users who upgrades from a previous version will still have data files left with mixed permissions. I therefore need to make sure that all existing folders and files gets the new permissions during installation. How do I accomplish this?
Ok, this is how I solved it. Hope it can help someone else in the future.
First, I added the following things to the wxs file for the MSI:
<Directory Id="CommonAppDataFolder">
<Directory Id="ProgramDataVendorFolder" Name="MyVendor">
<!--This will create the \ProgramData\MyVendor\MyProductName\ folder. -->
<Directory Id="ProgramDataAppFolder" Name="MyProductName" />
</Directory>
</Directory>
<DirectoryRef Id="ProgramDataAppFolder">
<Component Id="CmpCreateCommonAppDataFolderWithPermissions" Guid="13ae94b7-9ef5-4181-bfa9-933844a13418" Permanent="yes">
<CreateFolder>
<!--This will ensure that everyone gets full permissions to the folder that we create in the ProgramData folder. -->
<util:PermissionEx User="Everyone" GenericAll="yes" />
</CreateFolder>
</Component>
</DirectoryRef>
And then included it:
<Feature Id="ProductFeature" Title="$(var.ProductName)" Level="1">
<!--Add folder -->
<ComponentRef Id="CmpCreateCommonAppDataFolderWithPermissions" />
</Feature>
These three things made sure that all users had full access to the folder in ProgramData, even if the folder already exists.
But changing the permissions will not be enough, if file virtualisation is already active due to previous permissions problems. To turn off file virtualisation, I added an app.manifest to my executable with:
<requestedExecutionLevel level="asInvoker" uiAccess="false" />
Keep in mind that if the previously used VirtualStore contains files that are important, they will not automatically appear in the ProgramData folder.
More info regarding file/registry virtualization can be found here: https://blogs.technet.microsoft.com/mrsnrub/2010/08/11/uac-virtualization-allowing-standard-users-to-update-a-system-protected-area/
How to change Jenkins default folder on Windows where Jenkins runs as Windows service.
I want to change C:\Users\Coola\.jenkins folder to d:\Jenkins due to lack of space on C: partition (Every build takes ~10MB of free space). I don't want to reinstall Jenkins as Windows service. I just want to change folder of existing Jenkins instance. In case of lack of global solution I could focus only on relocating jobs folder.
Thanks in advance for your help.
Stop Jenkins service
Move C:\Users\Coola\.jenkins folder to d:\Jenkins
Using regedit, change HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Jenkins\ImagePath to "d:\Jenkins\jenkins.exe"
Start service
Apparently, grams' answer works but is not preferred. In Windows software and data/configuration files are supposed to reside in different places. This should be well known to Unix guys, it is basically like having a home directory. However, the wording with regard to JENKINS_HOME is broken anyways as setting an environment variable does not help despite what is being said in the help text.
I used the procedure that is described here: http://tech.nitoyon.com/en/blog/2014/02/25/jenkins-home-win/
Basically:
Stop Jenkins service
Edit entry <env name="JENKINS_HOME" value="%BASE%"/> in jenkins.xml in the Jenkins installation directory. This will be something like C:\Program Files (x86)\Jenkins. In your case value has to be set to d:\Jenkins
Move Files from the installation directory to the new destination, d:\Jenkins, all except (some of them may not exist in a fresh installation)
jre folder
jenkins.err.log
jenkins.exe
jenkins.exe.config
jenkins.out.log
jenkins.war
jenkins.war.bak
jenkins.war.tmp
jenkins.wrapper.log
jenkins.xml
Restart the service again.
When you read Administering Jenkins you can read all options how to modify the JENKINS_HOME environment variable.
On this website you can read how to configure you Tomcat container to override the JENKINS_HOME environment variable, they advise to create the file $CATALINA_BASE/conf/localhost/jenkins.xml, with the following content:
<Context docBase="../jenkins.war">
<Environment name="JENKINS_HOME" type="java.lang.String" value="/data/jenkins" override="true"/>
</Context>
Here is the answer that worked for me: Jenkins: How to change JENKINS_HOME on Windows
And in addition to grams answer, the most important part is creating an environment variable named JENKINS_HOME with value "D:\Jenkins". Without that, on starting Jenkins it would again create the .jenkins folder in your user home folder.
I was able to change the JENKINS_HOME variable following this http://tech.nitoyon.com/en/blog/2014/02/25/jenkins-home-win/
Setting JUST %JENKINS_HOME% as windows system wide environment variable didn't have any effect!
We installed by dropping the .war into Tomcat, and could set home by just setting the environment variable JENKINS_HOME (with a service restart).
I hope this hasn't already been answered, but I feel like I have read every related article on the entire internet...
I need to have the DefaultLocation property of the Installer default to C:\ or D:\ (ideally there would be logic here but I have already learned that can't be done because Custom Actions are executed after the files are installed).
The issues I am seeing is that if I use the property for [TARGETDIR] or [ROOTDRIVE] which generally defaults to C:\ or D:\, that if a user selects a different install location, the installer ignores the location they selected.
For example on my machine [ROOTDRIVE] resolves to C:. If I tell the installer to D:\, it installs to C:\ anyway. This happens with both the [TARGETDIR] and the [ROOTDRIVE] property.
Has anyone seen this or know why this is happening?
Thanks,
Steve
You don't want to be setting TARGETDIR as this defaults to the drive with the largest amount of free space, generally you'd use something like INSTALLDIR or APPLICATIONFOLDER and have the user customize that property instead. The WiX sample below defaults to C:\Program Files\ACME Xyz\My Program but if the user changes the location of APPLICATIONFOLDER to say D:\blahblahblah then the files will be installed there.
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="MyCo" Name="ACME Xyz">
<Directory Id="APPLICATIONFOLDER" Name="My Program" DiskId="1">
</Directory>
</Directory>
</Directory>
</Directory>
EDIT:: In that case, just use an immediate custom action. e.g.
<CustomAction Id="SetInstallFolder" Property="APPLICATIONFOLDER" Value="D:\" Execute="immediate" />
<InstallExecuteSequence>
<Custom Action="SetInstallFolder" Before="CostFinalize">ACTION="INSTALL" AND APPLICATIONFOLDER="" AND (ALLUSERS=1 OR (ALLUSERS=2 AND Privileged))</Custom>
</InstallExecuteSequence>
<InstallUISequence>
<Custom Action="SetInstallFolder" Before="CostFinalize">ACTION="INSTALL" AND APPLICATIONFOLDER="" AND (ALLUSERS=1 OR (ALLUSERS=2 AND Privileged))</Custom>
</InstallUISequence>
I just figured out WHY this was happening with the Visual Studio installer and more importantly how to rectify it.
There is a property called "PackageAs", which can be accessed within Visual Studio on each file that is used in the setup file. By default this property is set to "vsdpaDefault" which based on the little bit of information I was able to uncover causes the file to be compressed, which in turn changes the file and subsequently the LastModifiedDate.
This can be resolved by changing the file you wish to maintain the LastModifiedDate on to PackageAs "vsdpaLoose". This causes the file to NOT be compressed and maintain its properties.
Hopefully someone else will have the same issue and find this useful.