Currently I'm trying to update Gradle 2.0 to 2.11. In the getting-started.html file of my gradle distribution (2.11) is described how to install a newer Gradle version. I unpacked the .zip to the desired location and unpacked it. I set the environment variable GRADLE_HOME accordingly and it is included in the PATH.
However gradle -v will print:
------------------------------------------------------------
Gradle 2.0
------------------------------------------------------------
Build time: 2014-07-01 07:45:34 UTC
Build number: none
Revision: b6ead6fa452dfdadec484059191eb641d817226c
I checked my environment variable by using Get-Childitem env:GRADLE_HOME, which does print:
Name Value
---- -----
GRADLE_HOME C:\dev\programs\gradle-2.11
Restarting PowerShell or even the computer didn't help. I've also set a variable pointing to GRADLE_USER (which is to a .gradle folder) is there a known issue with that? Or did I just miss something in the Installation process?
PowerShell will run executables without a path only if they're located in one of the folders listed in the PATH environment variable ($env:Path in PowerShell). Most likely you still have the path to the old installation listed there (something like ...;C:\dev\programs\gradle-2.0\bin;...). Depending on where it's defined you need to change it in the system or your user environment.
You can avoid the need to update the PATH environment variable with every Gradle update by using the GRADLE_HOME environment variable in it. However, for this to work you must make the respective registry value a REG_EXPAND_SZ value (default is REG_SZ). The system environment is stored in this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
The user environment is stored in this key:
HKEY_CURRENT_USER\Environment
You can change the type of the PATH value to REG_EXPAND_SZ with something like this:
$key = 'HKEY_CURRENT_USER\Environment'
$path = [Microsoft.Win32.Registry]::GetValue($key, 'PATH', $null)
$path += ';%GRADLE_HOME%\bin'
[Microsoft.Win32.Registry]::SetValue($key, 'PATH', $path, 'ExpandString')
or (a little more elaborate) like this:
$key = 'HKEY_CURRENT_USER\Environment'
$path = [Microsoft.Win32.Registry]::GetValue($key, 'PATH', $null) -split ';' |
Where-Object { $_ -notlike '*gradle*' }
$path = (#($path) + '%GRADLE_HOME%\bin') -join ';'
[Microsoft.Win32.Registry]::SetValue($key, 'PATH', $path, 'ExpandString')
The latter will remove an existing Gradle path from the environment variable before adding the GRADLE_HOME-based path.
Change $key to the system environement key to modify the system instead of your user environment (requires admin privileges).
By putting %GRADLE_HOME%\bin in the PATH (and have the operating system expand the variable by making the registry value a REG_EXPAND_SZ) PowerShell will always use the gradle.exe from the bin directory in your $env:GRADLE_HOME.
Related
I'm trying to set up a local Git server on Windows the way it is described on this website: https://github.com/PowerShell/Win32-OpenSSH/wiki/Setting-up-a-Git-server-on-Windows-using-Git-for-Windows-and-Win32_OpenSSH. When I try to set the variable $machinePath ($machinePath = ${C:\Program Files\Git\mingw64\bin}::GetEnvironmentVariable('Path', 'MACHINE')) I get an error message telling me that accessing the path C:\Program Files\Git\mingw64\bin was denied. I do run PowerShell as Administrator. Can anyone tell me how to fix that?
The first step of your linked guide says to run these commands to add git to your PATH globally. There's no reason to change them unless you installed git somewhere else:
$gitPath = Join-Path -Path $env:ProgramFiles -ChildPath "git\mingw64\bin"
$machinePath = [Environment]::GetEnvironmentVariable('Path', 'MACHINE')
[Environment]::SetEnvironmentVariable('Path', "$gitPath;$machinePath", 'Machine')
Note that setting machine-level environment variables does require running-as-administrator.
As for powershell syntax:
# accessing a class's member method/property is done via
[ClassName]::Method('parameter1','p2')
# curly brackets are usually script blocks or hash tables
$sciptblock = { ping localhost }
$hashtable = #{ key1 = 'value1'; key2 = 'value2'}
# they can also be used to set a variable name with spaces:
${a b c} = 'abc'
# BUT if you have a file path, powershell will GET/SET the data of the file:
${c:\temp\test.txt} = 'test file'
I'm using TFS 2017.1 Builds and Release feature.
In my release definition, I have a couple of release variables which I need to refer in my PowerShell task (execute on remote machine). So far, I've tried the following options but couldn't get it to work.
Added an Execute PowerShell task to store release variables into Environment variables:
$releaseVaraiables = Get-ChildItem Env: | Where-Object { $_.Name -like "ACL_*" }
Write-Host "##vso[task.setvariable variable=aclVariables]$releaseVaraiables"
Added an Execute PowerShell on remote machine task:
Here I can't read the Environment variables (maybe because this is remote machine task?)
Write-Verbose "problem reading $env:aclVariables" -Verbose
Then I tried passing the environment variable as an argument, but that didn't work either
param
(
$RbacAccessTokenParams
)
$RbacAccessTokenParams.GetEnumerator() | % {$_.Name}
$RbacAccessTokenParams | % {
Write-Verbose "variable is $_" -Verbose
Write-Verbose "name is $_.Name" -Verbose
Write-Verbose "value is $_.Value" -Verbose
}
This is how I passed as argument
-RbacAccessTokenParams $(aclVariables)
What I'm missing here?
I've tested your scenario on my side with TFS 2017.3.1, and it works when pass the environment variable as an argument. You can upgrade your TFS first and try again. Attach my steps for your reference:
1.
2.
3.
4.
Non-secret variables are already stored as environment variables; you do not need to do anything special to access them. You can access them with $ENV:VariableName. Periods are replaced with underscores. So Foo.Bar would be $env:FOO_BAR.
Secret variables should be passed in to the script that requires them.
However, this only applies on the agent. If you're using the PowerShell On Target Machines task to run a script, you need to pass the variables as arguments to the script. There is no way around this, unless you choose to use deployment groups.
Or, better yet, follow a configuration-as-code convention and store application-specific values in source controlled configuration files that your scripts read, so that you are not tightly coupled to your deployment orchestration platform.
I have a powershell script that looks at a list of VS installations, and determines the highest version installed. It then uses the InstallDir for that version, and uses it to access various commands.
It still uses the lower versions, however.
As of VS2017, it appears that the Registry keys are no longer saved in the same way. I need to update the script to be able to figure out the 2017 settings.
#Add New Versions to this list when new versions of VS are released
$VsVersionsToDisable = "10.0", "11.0", "12.0", "14.0"
[System.Collections.ArrayList]$VsVersions = $VsVersionsToDisable
#Find the Highest installed VS Version, and use it for the TFS.exe Command.
foreach ($version in $VsVersions | Sort-Object -Descending)
{
$keyPath = "HKCU:\Software\Microsoft\VisualStudio\$version`_Config"
If (Test-Path $keyPath)
{
$aliasPath = Get-ItemProperty -Path $keyPath | Select-Object `
-ExpandProperty InstallDir
$proxyPath = Join-Path $aliasPath "tf.exe"
set-alias proxyTF $proxyPath
}
}
To avoid an XY question: We use this script to configure the TFS Proxy settings for a user. It determines the highest installed version, uses it to find the proxy, then iterates through the lower versions configuring their proxy settings with the same value.
What is the best way to determine the installation directory (and also the tf.exe location) for VS2017?
From what I can see, use the SxS\VS7 option:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7
It should give you the root paths to Visual Studio:
That should get you going.
The tf.exe location is then stored using a symlink under:
.\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe
Since you're using PowerShell, check out https://github.com/microsoft/vssetup.powershell, which is a PS module for detecting installations of VS2017+.
Otherwise, you could need to rely on the Nuget package which is the supported means of detecting VS.
See also this answer on a related question, which predates the PS module I listed above but contains some unsupported methods for finding VS.
I did use this as a reference and came to a solution in another way.
I'm not sure how resilient it is with regards to other versions, but it did the trick for me. It get's the directory of devenv and then I add the extra on the end for TFS. Obviously if the structure is different, then we are screwed.
Hope it helps.
$regKey = "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\devenv.exe"
$visualStudioDir = Get-ItemPropertyValue -Path $regKey -Name "(Default)"
$visualStudioDir = ($visualStudioDir.Replace("devenv.exe","")).replace("`"","")
$tfsPath = 'CommonExtensions\Microsoft\TeamFoundation\Team Explorer\tf.exe'
Set-Alias tf $visualStudioDir$tfsPath
tf workspaces
Sorry if this has been answered before, I have tirelessly searched and cannot find the exact answer I am a Mac user and have not ventured into Windows registry before.
I am creating an installer for audio plugins and have a separate demo version of the titles. In the registry for the demo version, I have the entry
Demo=1
and also have paths set for various components of the plugins, which are optionally installed, these are stored in the registry as the user may install these into different directories depending on their host software
VST3=C:\Somepath\VST3
VST32=C\AnotherPath\VSTPlugins
VST64=C\AnotherPathAgain\VSTPlugins
I have found how to search the registry to check if Demo=1
$val = Get-ItemProperty -Path hklm:software\Audio Vitamins\Structure -Name “Demo”
if($val.Demo -eq 1)
{
**** This is where I need help *****
}
How do I set Powershell to remove a particular file 'structure.vst3' from the path set in VST3 or or 'structure.dll' from the paths set in VST32 and VST64. Note these can all be present or only 1 of them depending on the original install.
You have a couple of different paths (pun intended) you can take here.
You can organize your "demo = 1" files into one folder and the others in another and reference the demo folder location in the registry. Then you get the file location and use del to remove them. Much easier and doesn't require you to track which ones are there with unnecessary registry entries.
$demofolder = gp -path HKLM:\path\to\registry\key -Name "demofolder"
dir $demofolder -file|%{del $_ -force}
Is there a way to get the path of a script that imported a module from within that module?
The script module I'm writing is meant to load settings from files relative to the importing script. I plan on reusing the module for a number of projects, so I would prefer if the module could make no assumptions about where its being imported from.
This is a nice to have, it would be great the module could be as implicit as possible. If all else fails though, I can just have the caller pass in its location.
Unfortunately everything I've attempted so far returns the path to the module (not what imported it). Here's a simple demonstration:
Test-RelativeModule.ps1, Stored at: c:\test\
import-module "$PSScriptRoot\mod\Test.psm1"
Test.psm1, Stored at: c:\test\mod\
# returns 'c:\test\mod'
write-host "`$PSScriptRoot: $PSScriptRoot"
# returns 'c:\test\mod'
# The value of $MyInvocation.MyCommand.Path is 'c:\test\mod\Test.psm1'
write-host "Split Invoation: $(Split-Path $MyInvocation.MyCommand.Path)"
# returns whatever path the console is currently residing
write-host "Resolve Path: $((resolve-path '.\').path)"
# what I'm looking for is something to return 'c:\test' from within the module
# without making any assumptions about the folder structure
Try this:
Write-Host "My invoker's PSScriptRoot: $($MyInvocation.PSScriptRoot)"