My installation of TeamCity 3.1 (yeah, it is old!) (installed on a Windows XP box) holds its temporary files under C:/TCBWork. How can I move that root? I would like to move it to another disk for better space management.
Thanks.
If you're talking about build agent working directory, it is set in buildAgent/conf/buildAgent.properties file (local TeamCity agent is under TeamCity/buildAgent directory).
And given that you have non-standard location for it, you'd already changed it previously :)
This might be a stupid answer, but assuming you're using NTFS you could mount an entirely different drive to the folder location of TCBWork.
Related
Yes, I know vb6 ancient and all that. It's still an interesting question. and the issue might not even be with vb6....
Background: We have a server running a vb6 application for our users who access this via Citrix. This installed application accesses its DLLs (also written in vb6) from a "shared folders" location.
What I want to do is have the previous version of this same app on the same server, accessing it's own set of (previous versions) DLLs. I am half way successful. the renamed app in another directory runs. But it crashes immediately upon using any feature that draws from the DLL's code.
Apparently the registered DLLs of the current version are being called upon. I dont want that. I want the DLLs found in the same directory as the renamed older app to be called upon.
Can that happen in a windows server? is this an installer's settings issue? Have you ever had this situation before? were you successful?
thanks in advance.
Harry
Post Script:
The bosses decided that experimenting with the DLLs and system settings was a waste of my time and not worth the risk. So they're throwing money at it and another server will come online for the sole reason of providing the previous version to the citrix users who want it. Thank you to all of you who pitched in with great tips and leads to other posts. (yeah I'm sort of disappointed too. Kind of wanted to know what the solution was to this.....)
The OS should be looking for the dll’s in the following places and order
The directories listed in the App Path registry key (HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp
Paths) if any
The directory where the executable module for the current process is located
The current directory
The Windows system directory
The Windows directory
The directories listed in the PATH environment variable
Given that you are using a shared folder for your dll’s, I would suppose that the app is setting the current directory to your shared folder OR is using the PATH environmental variable to specify where to look. I don’t think it is using the app path registry key path because that is version specific and you said you are using a different version.
I would suggest your try setting the path via HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionApp Paths
I have uninstalled Xampp in my system. I have taken a backup of databases, but I missed to take folders inside htdocs. Is there any way to retrieve my folders.
Probably not; if the folders are gone then I would say your only hope is restoring from backup or an undelete utility.
Sorry for the bad news.
download shadowexplorer. Its is a system restore software that will find shadow copies on the system or specified folder through selected restore date. It is really easy to use.
Windows File Recovery CLI undelete utility. Currently available for Windows 10 2004 and above.
https://www.microsoft.com/en-za/p/windows-file-recovery/9n26s50ln705
I once accidently deleted my htdocs folder along with xampp, i immediately downloaded shadowexplorer and ran it, found all my files.
I just discovered why Maven doesn't work properly on my machine. For some reason it reads the user configuration from the completely wrong location. And I don't understand why. When I run maven with the -X switch I get the following output in the beginning:
[DEBUG] Reading global settings from D:\dev\maven\active\conf\settings.xml
[DEBUG] Reading user settings from D:\.m2\settings.xml
[DEBUG] Using local repository at D:\dev\maven_repo
Why is it reading user settings from D:\.m2 and not my actual user directory like it normally should? It worked fine on my old computer. Does it have something to do with me having installed maven on a different drive this time? On my old computer it was installed on the C drive.
Where does it get this D:\.m2 from? How can I make it read the user settings file from the actual default location, %userprofile%\.m2?
Finally figured it out. Found the solution in this blog post. To find the home directory in Java you do this:
System.getProperty("user.home");
Problem is, for some dumb reason, Java isn't using Windows environment variables or anything like that to find this path. It actually uses the parent directory of the Desktop directory. Since I like to keep certain main folders in my user directory on a separate drive (documents, downloads, music, desktop, etc) I had moved the desktop directory to D:\Desktop. Java then takes that directory, goes one level up and makes Maven and other java applications think D:\ is my home directory.
Gotta say the more I use Java the more i hate it... anyways, hopefully this might help save some hours of head scratching for someone else too.
Update
The original blog post is gone, but found on the WaybackMachine (the URL has been updated), but here's the gist from that post in case that goes too...
The issue: So how does Java play into all of this? Well, Java
developers sometimes want to store settings for their applications in
a folder within the user’s profile directory. It’s the Linux way, and
Java tends to do things the Linux way. (As mentioned earlier, Windows’
“AppData” folder servers the same purpose, with some extra separation
for data dependent on whether or not it should roam with the user’s
profile.) For some reason, Java does not use the Windows environment
variable to determine the location of the user’s profile, but instead
access a registry key that references the user’s desktop folder. It
then takes the parent directory of the desktop and assumes that is the
user’s profile folder (assuming the user makes use of the default
setup Windows chooses).
Essentially, when a programmer calls the Java command:
System.getProperty("user.home");
Java uses the following idea to determine where my user profile folder
is:
PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"
This breaks down when the desktop folder has been modified.
So, with my setup, instead of saving settings at:
c:\users\tim\
Java apps tend to save data to:
t:\tim\
In reality, Java apps should save settings to:
c:\users\tim\AppData\Roaming\
or something like that.
To add insult to injury, the Java apps continue to follow the Linux
way and use a period at the beginning of the folder name in an attempt
to “hide” the folder (as is done on Linux). For Windows users, this
simply ensures these folders are listed first in directory listings.
(Hiding a folder on Windows is achieved through setting the hidden
attribute for the file.)
It looks like NetBeans has addressed the issue for their application,
but the root issue remains an unresolved, low priority bug. Somehow
I’d bet it would get fixed a lot faster if the mechanism for
determining the user’s home path on Linux was wrong.
I have been trying to publish my service to windows azure. The service consists of a single webRole, however I have added remote login functionality published it and built it a few times, and now all the sudden it will not build. The reason it gives is that
Details below:
"Error 56 The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. C:\Program Files (x86)\MSBuild\Microsoft\Cloud Service\1.0\Visual Studio 10.0\Microsoft.CloudService.targets 202 5 FileSystemCreator"
I have gone on all the forums, I have used CSPack command line for packaging the service which is fine but I'm having a really hard time configuring the certificate for remote desktop connect and I would like to take advantage of this feature as I am creating some websites in the onStart event and I would like to peek into IIS. Some microsoft employees do agree that this is a bug and the have promised a fix this issue, refer to post . I am using VS2010 and I do not know how to fix this bug.
Can anyone please help, or point me to a place where I can get any help.
I ran into the same problem with a new solution.
Note that, unlike Eugenio Pace's response suggests, the error occurs only when deploying to Azure (and not when running the project in the Azure Compute Emulator).
Try adding the following line to the first property group of your Windows Azure Visual Studio Project file (*.ccproj):
<ServiceOutputDirectory>C:\Azure\</ServiceOutputDirectory>
The trailing slash (for whatever path you select) appears to be required. This folder will be deleted each time you create a package if it exists.
This setting seems to redirect the working folder for the package to a shorter base path, preventing the path too long error.
Credit goes to: http://govada.blogspot.com/2011/12/windows-azure-package-build-error.html
Perhaps the local folder used to store temporary development fabric is too long. See Windows Azure - Resolving "The Path is too long after being fully qualified" Error Message.
I was having this problem as well when deploying a Node.js project to Azure.
To fix it, I had to change my "TEMP" and "TMP" user environment variables to something shorter than their default values.
In my case, they were pointing by default to %USERPROFILE%\AppData\Local\Temp, changing them to C:\Temp solved it.
Make sure you restart Windows after.
The better solution may be to create a symbolic link to your project folder. This doesn't require moving files or changing system variables. Open up the command prompt as an administrator and run this:
mklink /D C:\Dev C:\Users\danzo\Source\Workspaces
Obviously you can change "C:\Dev" to whatever you want it to be and you'll need to change the longer path above to the root directory of your soltions/projects folder.
Same problem happened to me when I try Packaging an Umbraco project for Azure (https://github.com/WindowsAzure-Accelerators/wa-accelerator-umbraco/wiki/Deployment), I found the solution is to: Copy and rename the long-name path and folder to "C:\someshortname".
(solution was suggested by this: link)
I tried all the above 2 approaches:
-change TEMP and TMP enviromental variables
-<ServiceOutputDirectory> path
and didn't work.
In my case, I had to move the whole project to a shorter path C:\ and worked.
I'm using W7 and VS12.
When you run a cloud service on the development fabric, the development fabric uses a temporary folder to store a number of files including local storage locations, cached binaries, configuration, diagnostics information and cached compiled web site content.
By default this location is: C:\Users\\AppData\Local\dftmp
Credit goes to Jim Nakashima of Microsoft :
https://blogs.msdn.microsoft.com/jnak/2010/01/14/windows-azure-resolving-the-path-is-too-long-after-being-fully-qualified-error-message/
In order to change the temporary folder, a user environment variable has to be created :
It is named _CSRUN_STATE_DIRECTORY
Give it a value of short named directory like :
c:\AzureTemp
Don't forget to restart Visual Studio in order to have the environmennt variables to be read again
It fixed many compilations problem !
Over the years I have vacillated between having my project/source folders in a directory one level removed from the root (e.g. D:\Projects) and keeping them in the default location for Visual Studio.
In the past, I resisted storing anything in the various "My Documents" folders established by Win 95, Win 98, and XP. I finally switched to storing them in the Documents folder since Vista shortened the path and I got tired of changing default directories for my dev tools. However, now I find myself leaning toward creating a folder off root again since I am setting up a new machine.
I get tired of the long paths you have to navigate to when stuff is stored in the documents folders. Also, I don't backup source code and database files like I do with my other documents since I use a VCS for source code. However, it seems you are always fighting to maintain a "non-standard" source location since every dev tool generally wants to store stuff in a subfolder of documents.
I would like to hear other's opinions on this subject.
I think it depends on your use... I prefer to have my development projects on a separate drive/partition, so will usually use the following convention D:\projects\{company-name}\({client-name}|internal)\{project-name} Where the client-name comes into play is when the work is by a given company, but for another. I keep my projects under D:\projects\personal\... This allows for a better structure.
As to backup strategies, imho this is what source control is for. I prefer subversion, and have a backup strategy for the svn server. Although I didn't much care for ankh 1.x, the 2.x version, along with TortoiseSVN have worked pretty well for me. As a matter of practice, I tend to checkin often, and try to only checkin code in a runnable state (though new features/code may not work).
In clear violation of my Unix past I use c:\dev (for development) or whatever other drive I use for development. Note: It is advisable NOT to use the system partition for development as software development really fragments the disk.
I never had any reason to use another directory - except for some projects where "company standards" forced everybody to have the development directory on the root of the C: drive. (really! They had hardcoded paths to c:\whatever)
During development I sometimes check out multiple versions of the source to different directoies - if only to find out that the version committed into the version control system of the day really has every file checked in. (Sometimes I add a file to the development directory but forget to check it in.)
So I think it is rather irrelevant where your development directory is, as long as the path is typable for you (I prefer short paths) and does not contain white space for the usual reasons on windows (if you want to do some scripting).
I preferred location at another partition. Because projects have many and many small files and if you use SVN or other revision control system this files have very high fragmentation and slowing system if are storing at OS partition.
I haven’t tried it myself, but I guess you can put your projects in My Documents and use a symbolic link to the directory in your root folder. By doing that you can access your files both ways and solve problems like changing directory for tools. Info about symbolic links in Vista
If you’re the only one using your computer I don’t really see why you should put your code in the profile directory, backup should be done using a version control system anyway.
I store "active" projects on a secondary drive, one level from the root. It's much more easy to get quickly to that folder (even if VS2008 has this nice "Open Folder in windows explorer" now). It's also convenient for backups, format/reinstall, etc. The "less active" projects are stored on a NAS for quick reference. All are also stored on a remote SVN server that is backuped. (I'd also recommend not using # in folder for web application as it (sometimes) create strange errors from the development web server)
I use SUBST (run on startup) to map some random folder to a high-lettered drive. Then I can put my stuff anywhere, and move it around, and yet I always get to refer to it by Y: or Q: or whatever.
This is one of those extra layers of indirection that are said to solve every problem.
For personal projects I just put them on the desktop (although I do move the desktop to D:\Desktop). They are archived off to my documents when they become inactive.
For work I have all the projects in a C:\Sourcecode folder inside a dedicated development virtual machine.
Just one question, do your primarily develop desktop apps or web apps?
If you are constantly writing web apps, here's what works for me:
Create a folder: c:\dev or c:\sites (keep it simple)
Register the folder as a virtual directory in IIS
Create a different folder for each of your projects and create a web application in IIS for each of them
One advantage this setup might have is that, its easier for you to navigate your site in the browser, i.e less typing, easier to remember, standardization for all your other apps.
my 2cents.
it is better to keep your project in the other partition else than window and i think as i do
d:\projects\"some grouping of project own your own choice"\projectname
e.g.
d:\projects\UNIversty\admission
d:\projects\universry\examination
d:\projects\planners\ipp