我希望这是一个已经回答的问题的愚蠢重复。
我有一个 asp.net 网站，它依赖于其他一些项目（复制到 bin 的 dll）。现在，我想要的是每次更新这些项目时，我都会在我的网站/bin 中获得最新的 dll。我不希望我的 CI 服务器签入更新的 dll。
我已经为我的项目提供了一个私有 NuGet 提要，并且只希望它在每次成功的 CI 构建后提供最新的 dll。现在，我的问题是
有没有办法直接提供 dll 而无需创建 nupkg？并且可能从构建输出文件夹中选择它们？（由于某些原因，每天为所有 dll 创建包作为后期构建任务并不方便）如果可能的话，太棒了！
如果没有，我们是否可以避免每次增加 dll 的版本号，仍然对新的 dll 进行 nuget 更新？诸如基于最新发布日期的更新之类的东西？（有大量的 dll，还有很多依赖项）
有没有办法在不构建解决方案的情况下获取最新的 dll？是的，我可以执行 nuget update 命令，但是还有其他方法吗？
有人建议镜像我当前的代码库并使用 MyGet 或 ProGet 之类的东西。由于几个原因，目前这是不可行的。
在任何 NuGet 依赖项之后触发 Visual Studio 构建可能并不是您真正需要的——这是 CI 的工作。但是，您可以在 packages.config 文件中设置版本范围，以使 VS（通过 nuget）在可用时拉取更新的 NuGet 包。
要回答您的具体观点：
为什么要为您无法确定其来源的“随机”松散 DLL 提供服务？NuGet 提供了一种机制来跟踪您自己的代码所依赖的代码的来源，这使得跟踪错误更容易:) 如果您依赖包含“一天数百次”更改的 DLL 的 NuGet 包，那么您可能应该只构建那些 DLL直接与您的应用程序。
请参阅 #1 - 如果您经常重新构建 NuGet 包，那么您的包边界可能是错误的。考虑一下你的包是多么独立，看看将一些 DLL 放在一起是否有意义，或者甚至分离出（fork）在多个单独的应用程序之间共享的代码是否有意义。如果创建 NuGet 包的新版本，则应增加版本号 - 这是语义版本控制的基本前提，如果不遵循此模式，您将陷入混乱。
要关闭最新的 NuGet 依赖项，nuget update是你的朋友 :)
使用 MyGet 或 ProGet可能是解决方案的一部分，但它与您上面提到的模式没有直接关系。