I am trying to setup my TFS2010 Build and I want to access the files that are downloaded via the "Version control path to custom assemblies".
From what I can tell those files are downloaded to:
C:\User\<Build User>\AppData\Local\BuildAgent\<Built Agent Number>
I can directly access that folder via the above path, but it would be nice if there was an environment variable (or something I can use in the build) to access that folder indirectly.
Or... Is there a better way to get at these files? (I am putting a version file in there to be downloaded every time the build is run).
You can use %LOCALAPPDATA% environment variable. It expands to
RootDrive:\User\LoggedInUser\AppData\Local
Example: %LOCALAPPDATA%\BuildAgent
Note that %APPDATA% will expand to
RootDrive:\User\LoggedInUser\AppData\Roaming
Related
trunk: failed at 11/26/2019 9:50AM
Could not create parent directory for lock file C:\Program Files\gradle-5.6.4\wrapper\dists\gradle-5.6.3-bin\82hbcx3fecbatlnap0jtj8ysr\gradle-5.6.3-bin.zip.lck
The folder C:\Program Files in Windows is by default protected and can only be changed if you do it with administrator rights. For the same reason, it is not supposed to be used as a work area for temporary or downloaded files. But this is what you are attempting to do.
When you run the Gradle wrapper scripts (through gradlew), it will download a Gradle distribution to your Gradle user home. The user home can be set by the environment variable GRADLE_USER_HOME, and if not set it will default to $USER_HOME/.gradle.
To me, it looks like you have downloaded a distribution manually (version 5.6.4) and then set GRADLE_USER_HOME to that folder. You shouldn't do that - just leave it to the default, or if you don't like that, another folder that doesn't require administrator rights to modify. Otherwise, Gradle will attempt to download the required distribution for your project (in your case version 5.6.3) to that folder and after that, create lock files and fill the cache with dependencies and more.
Some people also set a variable GRADLE_HOME to point to a default Gradle distribution. You can set this to the folder where you have manually downloaded it if you like, and then add %GRADLE_HOME%\bin to your PATH. But this is optional.
Is there a way to tell SBT which (locally) installed JDK to use?
I am quite certain I could change PATH and JAVA_HOME but I'd rather not change those settings since they apply for the whole system (Windows in that case).
I am more looking for a command line parameter of some sort.
If you're looking to specify a JDK for running SBT (rather than a JDK to use for running your code and/or tests from within SBT), you can make use of the JAVA_HOMES environment variable, plus a .java-version file in your project.
This is described in SBT's sbt.bat file (typically installed to C:\Program Files (x86)\sbt\bin) as a "poor man's jenv", which isn't currently available on Windows.
(If you're looking for a similar solution for Linux or MacOS, you can either use jEnv, or specify the Java home directory via the -java-home SBT command line option—which also, sadly, isn't currently implemented on Windows.)
The JAVA_HOMES environment variable (not to be confused with JAVA_HOME) is used by SBT to identify a directory that contains one or more JDK installations. For example, if you're using AdoptOpenJDK's JDK distributions (recommended on Windows, if Oracle's new licensing restrictions are a problem for you), then this would typically be defined as C:\Program Files\AdoptOpenJDK.
Let's say that you have two such JDK installations in the JAVA_HOMES directory: one in a subdirectory named jdk-8.0.212.03-hotspot; another in the jdk-11.0.3.7-hotspot subdirectory. You can select which JDK you want to use, on a project-by-project basis, by creating a file called .java-version in the root directory of each SBT project. To use the JDK in the jdk-8.0.212.03-hotspot subdirectory, this file should then contain:
jdk-8.0.212.03-hotspot
When you run the sbt command, if you have JAVA_HOMES defined, SBT will look for a .java-version file in the project's root directory. If it finds it, it creates a local version of JAVA_HOME that is defined as JAVA_HOMES plus the last line of .java-version. It also adds this JAVA_HOME's bin directory to the path. (It also creates a JDK_HOME process-local environment variable with the same value.)
This should do what you want. Although it's not a command line-based solution, it doesn't adversely affect other users, and allows each SBT project to be configured individually. If you do not have permission to create a system-wide environment variable, you should still be able to create a user-specific JAVA_HOMES environment variable. Note that when using this solution, the JDK that SBT uses is then not necessarily the one identified by your system-wide (or user-specific) JAVA_HOME environment variable. (If you have not defined JAVA_HOMES, then SBT will expect you to have defined a valid JAVA_HOME variable.)
One word of caution: if you commit .java-version to source control, you must ensure that everyone defines a valid JAVA_HOMES environment variable, and has a JDK with the exact same name installed in that directory.
I have a Lua program (written in Lua 5.1). I'm on Windows 7, trying to use srlua to convert a lua file into an executable. finally i have create an executable used
glue.exe srlua.exe myscript.lua gd.exe
when i click exe/bat to execute. it crashed . tips : no find lua51.dll in computer.
when i used cmd to execute . it work. even i only move gd.exe to other dir.
so, why ?
doesnot srlua create standalone exe without lua environment?
dir ls
error tips
You are mixing Lua environments: your directory structure shows Lua51.dll, but your error message references Lua5.1.dll, which you don't have (and those are two different files). Somehow you depend on a module that was compiled against Lua5.1.dll. You can figure out the dependency chain by using a dependency walker as it will show what DLLs are being loaded and from what locations. You can also run it in the "profile" mode, which will show where the error you see happens in the dependency chain, so you'll know what DLL or executable is at fault.
In Windows, an executable will only look in a few places for the .dll (in order):
1) Any dependency paths will be searched first. These you can set when you are creating the project (generally through the IDE).
2) The current directory that the executable is running from. For example, if gd.exe was in the folder myexe in C: drive, the directory C:\myexe would be checked.
3) The system directory. For Windows, it's something along the lines of C:\Windows\System32.
4) Anything additional paths, specified by the PATH environment variable.
So, if you moved your executable gd.exe from C:\myexe to C:\myexe2, you would either need to point to the .dll via dependencies/the PATH environment variable, or move all of the .dll files that you need to the new directory.
If command line works to run the program, but not the .exe itself, your command line has the PATH environment variable set. You can set it in the command line using setx path "%path%;c:\newpath" or use the the Control Panel -> System and Security -> System then clicking on Advance System Settings -> Environment Variables and under System Variables, look for the PATH key word.
Keeping the .dll files and executable in the directory (c:\myexe for example) and running the executable is a good way to make sure they work together and that all required .dll files are seen by your executable.
Source (even though it doesn't mention the PATH environment variable): https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx
Is it possible to output/deploy a .nupkg file that is downloaded from a teamcity server. Currently it extracts the .nupkg that is downloaded from the teamcity server. The file that is extracted into the Applications folder is stored in the Octopus\Applications.Tentacle\Packages folder but it has an internal name which is not very user friendly.
My only option at this point is to run a custom powershell script that copies the file and renames it, but this seems like a rather crude hack.
Use the system variables to access the internal values set within Octopus to find what the name and path of the nuget package you want. This list of system variables on the Octopus Deploy site is where'd I'd start to look first. I don't know how complete the list is but there are a consider number of variables you have access to in Octopus Deploy.
I'm using Maven and IzPack. I'm looking for a way to put a file into the directory of the installer file. In the install.xml I've got a file tag set with a targetdir of "." but that will only work if the installer is executed from that directory. If executed from a different directory, the file is put in the current working directory of the user instead.
Having checked IzPack documentation, there's a built-in variable for $INSTALL_PATH, but I need the path of the installer. There's no way to predict where this installer will be when executed so specifying a pre-set directory won't work. Trying to specify the local directory via Maven just gives the path to the POM.
Is there an undocumented variable that would do the job or something else I've overlooked?