我们有两个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似乎优先于参考路径。