C# 本地NuGet服务器包的版本控制问题

一些背景：
在我的公司，过去几个月我一直致力于将我们的C#库转换为.dll引用上的函数，而不是项目到项目的引用。为此，我们创建了一个本地NuGet服务器，其中包含所有库项目的NuGet包。我们为每个项目设置了Jenkins作业，这些项目构建新的NuGet包，并在每次更改其中一个包时将其添加到服务器

对于单个项目，该系统非常有效。您只需担心通过VisualStudio的NuGet manager更新您的packages文件夹，然后剩下的就是编写代码和构建

问题：
添加新引用或通过NuGet更新包时，NuGet会自动指定在NuGet中选择的项目的特定版本。在我设置的当前系统中，在本地重建项目将替换packages文件夹中的.dll，以便所有引用它的项目都可以看到您正在测试的这些新更改。然而，问题在于本地构建的项目与我们的Jenkins构建的包有不同的版本。我们的本地版本使用与Jenkins版本不同的版本控制系统，因此您可以很容易地判断某些内容是使用Jenkins构建的，还是某些.dll来自开发人员的版本。由于这种不同的版本控制方案，项目对项目的引用中断，因为本地生成的新.dll的版本与从NuGet服务器检索的.dll的版本不同

当前解决方案：
目前，我已经通过添加预构建步骤解决了这个问题。在每个项目生成之前，该项目都会调用我的一个PowerShell脚本，该脚本将执行并向正在生成的项目的.csproj文件中的每个项目引用添加

False

。这就解决了这个问题，但只是在上面贴上绷带的意义上。我不想处理系统的后果，而是想提前预防它们，这样就不需要每次构建项目时都这样做。我已经试着研究了很多关于NuGet软件包特定版本控制的问题，但在网上找不到任何与我要求的内容相近的东西。这让我觉得我做错了

问题：

---

我能做些什么来解决这个问题？还是我做了一些非常错误和愚蠢的事情，而这些可以通过使用另一个系统轻松避免？任何建议或提示都将不胜感激

IMO软件包应只有一个版本流。要么在Jenkins中构建所有内容，要么在本地构建，但不要在这两个地方都构建包。在我最后的位置上，这是一场永无止境的噩梦，因为开发人员有时会推送与Jenkins生成的版本无关的版本的包，导致由于引用了错误的包而难以解决问题。在沙地上画一条硬线；这将使每个人的生活更轻松。对于在本地更改其项目的开发人员，我还会使用相同的系统来替换packages文件夹中的.dll吗？一个版本控制流可以解决版本控制问题，但会使本地构建仍然有些混乱工作流应该是：1）提交库代码，2）从Jenkins生成、打包和推送，3）在Visual Studio中更新NuGet引用，4）在本地生成。让Visual Studio通过NuGet管理器管理包目录。