在Windows 7中存储Delphi代码的位置？

Question

我刚刚注意到我的一些新的Delphi控件安装在Windows 7的Public Documents文件夹中（TMS Smooth控件和Virtual Treeview）。是否有这样的原因，这是一种约定或一些操作系统或事物的方式。

是否有一个地方可以设置我的Source控件的根目录，以便它与RAD studio和windows 7更容易集成？

Answer 1

编译PAS文件时，编译器会将同名的DCU文件放在同一目录中。您可以更改此设置，但默认设置是使用相同的目录。在Windows 7中，可以虚拟化对非提升用户的“程序”文件夹（及其子文件夹）的写入。这意味着当程序（如Delphi）尝试写入其中一个文件夹时，该文件实际上将写入其他位置，并且可能在下次运行程序时不可用。

因此，由于您经常编译源文件，因此将它们安装在默认可写的位置（如公共文档）是有意义的。

但是，大多数组件安装程序都允许您选择其他安装位置。只要您选择的文件夹不是程序的子文件夹，您就可以了。

Answer 2

至于你的“源代码控制之源”，Windows 7并不要求你把它放在任何特定的地方，虽然有些人可能更喜欢将他们的源代码保存在他们的用户主文件夹中（C：\ Users [你的用户]名称]），我个人更喜欢使用简短的东西，比如C：\ DEV，这对我很有用。

Answer 3

这真的是一个品味问题...只是要小心在你的用户目录中存储大量数据...特别是如果你使用漫游配置文件，因为这些数据将被运送到你登录的每台机器上（并维护）网络上的副本）。适用于备份，不适合登录/注销时间。

由于您使用源代码控制，对于您的项目，最好从根目录创建一个新目录，并将源放在那里。它不受UAC保护（除了第一个目录的初始目录创建）。我倾向于在我的机器上创建一个C：\ DEV目录，然后创建子目录C：\ DEV \ 3RDPARTY和C：\ DEV \ SANDBOX，我的所有第三方组件都进入C：\ DEV \ 3RDPARTY中的子目录和我的子目录Delphi的“default”目录指向沙箱，在那里我创建了“测试”项目。

如果您开发第三方图书馆供公众使用，那么您将希望使用类似公共文档的内容，但是让用户能够更改目录以符合他们的偏好。

Answer 4

您指定的文件夹可能是Windows 7上SHGetFolderLocation（CSIDL_COMMON_APPDATA）结果的一部分。它曾经是Windows XP上的C：\ Documents and Settings \ All Users \ Application Data，并且是正确的位置（根据MS），适用于适用于计算机所有用户的应用程序相关文件。

由于我不与其他人共享我的开发机器，我通常在其他地方安装组件（例如，我的家用机器和笔记本电脑上有一个辅助硬盘驱动器，我用于那种东西）。这可以防止在编译文件或创建包时在Vista和Win7上出现UAC问题，因为我可以安全地对该目录树上的每个人进行读/写访问。

我在我的工作机器上使用一个单独的文件夹，离开C：\的根目录，称为Comps。我将所有第三方和内部组件安装在该组件的子文件夹中，这样可以将它们保存在一个位置。

Answer 5

现在是时候库编写者默认停止写了。他们可以选择公共文档，因为Delphi本身会将编译的软件包放在那里，因为这是唯一一个肯定可用的可写目录，它不是用户特定的。 我已经使用多年了：\ Dev \ Lib目录有适当的权限设置存储库的位置，以及：\ Dev \ Src用于我的项目源（我喜欢短路径）。您没有告诉您正在使用哪个VCS - 许多实际上并不需要单个根，您可以在源代码管理下拥有多个目录树，每个目录树都有自己的根。无论如何都有明确的目录结构有帮助。

我通常将BPL保存在Delphi使用的同一个共享目录中，因为它已经在路径中并且避免了“乱丢”system32文件夹。 不幸的是，许多组件编写者仍然没有遵循适当的库部署规则，我经常发现的最烦人的问题是：   - 没有单独的dcus文件夹（即\ dcu \ D11），dcus保留在源目录中，在不同的Delphi版本共享库时没有用   - 包不使用$ LibrarySuffix来设置包版本，但仍将它放在包源名称中   - BPL保留在包目录中，而不是路径中的目录。