3

我们的项目有很多外部 DLL，大部分但不是全部都是 3rd 方 DLL。

目前我们的项目中没有这些 DLL。它们包含在 SVN 中，并为我们的构建输出目录提供了路径。因此，在构建我们的项目之后，由于 SVN，必要的文件就在那里，但项目本身并不知道它们。

我的感觉是，我们应该在项目的根目录下有一个文件夹，命名为 Dependancies 或 ThirdParty，其中包含所有 DLL，并将它们的构建事件设置为复制到输出目录。它们也将存在于 SVN 中，但与项目具有相同的结构，而不是在构建输出目录中。

项目本身仅引用这些称为 CommunicationProc.DLL 的 DLL 之一。CommunicationProc.DLL 然后引用所有其他 DLL。我们有许多 DLL 来支持不同类型的无线电。因此，并非所有的 DLL 都会被使用，但根据无线电类型，可以使用其中的任何一个。

至于DLL是否应该包含在项目中，我们内部有不同的意见，一些团队认为它们应该只在SVN中，而不是项目本身的一部分。

值得注意的是，这不是 .NET DLL，大多数是旧的 C DLL。

公认的做法是什么？有人可以以一种或另一种方式为我提供一个令人信服的论点，关于是将它们包含在项目中还是仅包含在 SVN 中？

4

2 回答 2

4

最好将它们放在源代码管理的文件夹中，然后在构建事件时将它们复制到调试文件夹中。这样您就可以管理他们的版本。如果某个 dll 的较新版本出现，那么您可以替换旧版本并在签入时添加一些注释。此外，如果您在一个团队中工作，那么您可以让每个团队都不要将文件从调试文件夹复制到每个团队成员成员使用源代码管理中的同一组 dll。如果您正在开发一些控件并希望您的客户使用该控件，那么您可以更轻松地在某些地方拥有一组依赖 dll，以便您可以将这些与您的 .Net dll 一起提供给您的客户。
我对一些非托管的 dll 有同样的问题，最终将它们放在一个文件夹中，以便所有团队成员都拥有相同版本的 dll。希望这可以帮助。

于 2012-05-02T18:18:27.443 回答
1

我包含一个没有代码但包含一个文件夹，其中保存了所有外部程序集及其依赖项的项目。对于每个文件，将 Build Action 设置为 None 并将 Copy to Output 设置为 Do Not Copyp。然后，该项目从该位置引用二进制文件。在您的其他项目中，请参考此特殊项目。构建时，因为引用了特殊项目并且它引用了所有需要的依赖项，所以会根据需要复制二进制文件。

如果你不想要一个特殊的项目，仍然在你的主项目中创建文件夹，添加程序集，设置它们的属性，然后根据需要引用程序集。

这使您可以完全控制版本和输出，更重要的是，它很简单。

于 2012-05-02T18:36:47.060 回答