the on premise repo server quarantined certain packages .since nuget restore was picking dotnet runtime 6.0.18 from the repo, the nuget restore failed consistently due to a quarantine of that package ...., i tried to point runtime version towards a lower version like 6.10 to avoid that failure. I HAD no idea where it was picking the runtime version from to select the dotnet runtime package.... it was repeatedly picking up 6.18 almost adamantly.the culprit i thought was nuget.dgspec.json under obj . but they seem to be temp files created in a temp folder when restore runs...no point editing a transitory entry.....which is the best way to point to he desiredt runtime version for nuget restore?
It's a file that NuGet writes on restore, that represents all of NuGet's project inputs for that project. Therefore whatever values you see in there are because something else is telling NuGet that's what the project wants.
It's read if you use solution filters in Visual Studio, or otherwise have "unloaded" projects. It enables NuGet to restore loaded projects that have <ProjectReference to an unloaded project. There's a chance that NuGet also reads it on CLI restores that use -p:RestoreRecursive=false, but I'm not confident about that. I think on CLI restores, even when recursive is disabled, I think it still recursively gets the project inputs via MSBuild, it just won't restore (generate all NuGet's obj/* files) for those other projects. If you're not using unloaded projects in VS, then the dgspec file is never read.
Anyway, your question would have been much more clear if you gave an example of what package(s) you're referring to. Especially since "quarantine" is a generic English word, and not some commonly used term within .NET software development. I'm guessing you have some security tool that scans for packages with known vulnerabilities.
Anyway, given you mentioned runtime and, and a version number that sounds a lot like a .NET runtime version number, I assume it's packages that the .NET SDK automatically (implicitly) add. Probably the .NET host package. Therefore, you need to upgrade the version of the .NET SDK on the host machine to the latest version, and then the .NET SDK will know to use the latest version of the package, at the time that the SDK was published.
Another option is to install the .NET SDK that matches the same major version of the target framework your project targets. Your mentioned version 6.0.something, so your project must have <TargetFramework>net6.0, but your CI agent must have the .NET 7 SDK installed (or a .NET 8 preview/RC).
The .NET SDK contains the runtime host for the same (major) runtime version that the SDK is (so the .NET 7 SDK has the .NET 7 runtime host packages preinstalled). You might also need to use global.json to pin your repo to that version of the .NET SDK, because if you have an old .NET 7 SDK installed, with a newer version of the .NET 6 SDK, then the runtime host that the .NET 6 SDK has might be different to the version of the .NET 6 runtime host that the older .NET 7 SDK expects, and therefore still tells NuGet to download the packages.
If you want to improve your MSBuild debugging skills, there's just one tool to learn: Run any MSBuild command on the command line, and add the -bl argument. It'll write a file msbuild.binlog to the current directory, and then you can open it with https://msbuildlog.com. There's a Windows app you can download, or view the binlog directly on the website.
It shows a trace of everything MSBuild did, and you can look through to figure out what's happening. You can also right click projects and select "Preprocess" to see the project file with all <Imports expanded. Like anything new, it takes some time to understand, but then you'll be able to debug almost any build issue. Just be sure not to start writing complex MSBuild script that nobody else can understand unless they also become an MSBuild expert