我们有两个Visual Studio解决方案,F和C.F是一个框架。 C是使用由F.
生成的dll:s的客户端我们不想创建包含F和C的单个解决方案。相反,我们希望F生成由C使用的NuGet包。
我们当前的解决方案是手动运行一个脚本,将F生成的DLL复制到C中的特定文件夹中。复制的DLL:s被C引用为文件。二进制DLL文件签入版本控制。它不优雅,但速度非常快。副本只需要几分之一秒。
我们的经验是,当在F和C本地进行开发时,NuGet成为一个障碍。让我们说开发人员正在开发F的接口以及C如何使用它。然后,这个开发人员必须在F和C中工作,经常来回切换。
在那种情况下,每次更新F时复制DLL:s非常快。如果我们介绍NuGet,那么这个过程会大大减慢:
每次修改F时,都需要在TeamCity上构建一个适当的NuGet包。然后,C必须使用NuGet包对所有项目进行NuGet更新以获取新版本。等待TeamCity构建和更新所有引用都很慢。第一个需要一分钟,第二个也需要一分钟。
或者,可以在本地编译F以生成到本地NuGet存储库的NuGet。这比TeamCity构建要快。但是C中的NuGet引用仍然需要更新,这仍然很慢。 C的package.config现在将包含对中央NuGet存储库中不存在的NuGet版本的引用,因此这容易出错。此外,我们必须将C配置为从本地存储库读取,这是不应该检入的内容。当您完成本地开发时,必须清理本地存储库。
如果我们可以在本地轻松规避NuGet,那么更好的是,我们不必在F的每次更改时都更新NuGet引用。有没有明智的方法来做到这一点?我们的方案对我来说似乎是一个标准要求。我现在已经在两个主要项目中看到了这个问题。
我们尝试使用Reference Paths in Visual Studio,希望我们可以通过这种方式覆盖二进制文件的路径(然后仍然使用复制脚本将DLL带到一个单独的文件夹中)。但HintPath似乎优先于参考路径。