Where to store Delphi code in windows 7?

I just noticed that some of my new Delphi controls get installed in the Public Documents folder in windows 7 (TMS Smooth controls and Virtual Treeview). Is there a reason for this, is this a convention o开发者_JAVA技巧r a few way of doing things or something that the operating system does.

Is there a place where I can set the root of my Source control to so that it integrates with RAD studio and windows 7 easier?

When you compile a PAS file, the compiler will put a DCU file with the same name in the same directory. You can change this, but the default is to use the same directory. In Windows 7, writes to the Programs folder (and its subfolders) for non-elevated users can be virtualized. This means that when a program, like Delphi, attempts to write to one of these folders, the file will actually be written elsewhere, and may not be available the next time the program is run.

Therefore, since compiling the source files is something you do routinely, it makes sense to install them in a location which is writable by default, like Public Documents.

However, most component installers will allow you to choose a different install location. As long as you choose a folder which is not a subfolder of Programs, you should be OK.

As for your "root of source control", Windows 7 does not require that you put it in any particular place, although some people may prefer to hold their source code in their user home folder (C:\Users[Your User Name]), I personally prefer to use something SHORT, like C:\DEV and this works great for me.

Its really a matter of taste...just be wary of storing lots of data in your user directory... especially if your using roaming profiles, as this data will get shipped around to each machine you login to (and maintain a copy on the network). Good for backups, bad for login/logout times.

Since your using source control, for your projects, your better off creating a new directory off the root, and placing the source there. It won't be protected by UAC (other than initial directory creation of the first directory). I tend to create a C:\DEV directory on my machines, and then create subdirectories C:\DEV\3RDPARTY and C:\DEV\SANDBOX, all of my 3rd party components go into subdirectorys in C:\DEV\3RDPARTY and my "default" directory for Delphi points to the sandbox, where I create my "test" projects.

If your developing a 3rd party library for public consumption, then your going to want to use something like public documents, but give the user the ability to change the directory to match their preferences.

The folder you specified is probably part of the result of SHGetFolderLocation(CSIDL_COMMON_APPDATA) on Windows 7. It's what used to be the C:\Documents and Settings\All Users\Application Data on Windows XP, and is the proper location (according to MS) for application-related files that are applicable to all users of the computer.

Since I don't share my development machines with others, I usually install the components elsewhere (I have a secondary hard drive on my home machine and laptop, for instance, that I use for that kind of stuff). This prevents UAC issues on Vista and Win7 when the files are compiled or packages created, as I can safely give read/write access to everyone on that directory tree.

I use a separate folder on my work machine, off the root of C:\, called Comps. I install all of my third-party and inhouse components in subfolders of that one, which keeps them all in one place.

It was time that library writers stopped to write by default to . They prpbably choose public documents because Delphi itself puts compiled packages there, and because that's the only surely available writable directory which is not user-specific. I've being using for years a :\Dev\Lib directory with proper permission set where to store libraries, and :\Dev\Src for my projects sources (I like short paths). You don't tell which VCS you're using - many do not really need a single root, you can have multiple directory trees under source control, each with its own root. Anyway having a clear directory structure helps.

I usually keep BPLs in the same shared directory Delphi uses, because it is already in the path and avoids to "litter" the system32 folder. Unlucky many component writers still do not follow proper rules for library deployment, the most annoying issues I usually find are: - No separate folders for dcus (i.e. \dcu\D11), dcus are left in the source dir, no good when sharing a library across differend Delphi versions - Packages not using $LibrarySuffix to set the package version, but still putting it in the package source name - BPL left in the package directory and not in a directory in the path.