is there a close ticket option. ? If so feel free to close. I just couldnt see it.

Not too sure where to write this, but I had a very similar error (NCrunch was unable to restore Nuget packages required to build a test environment for this solution) in Ncrunch for Rider v5.9.0.1. The solution that worked for me was to exit Rider, delete the `C:\Users\<UserName\AppData\Local\NCrunch\<SomeInt>` folder and restart Rider.

I'm not sure entirely which issue you've been hit with under the hood, but the above warning is quite narrow in its scope and I don't see a way for it to relate to false positives from the build system.

When NCrunch first starts, it has a list of packages that it needs to have installed on your machine for NCrunch to work correctly. This list of packages is actually hard-coded into NCrunch (or at least, it's derived by the NCrunch build system when the installers are built). It's basically a list of a number of platform dependencies that NCrunch and its adapters need internally to be able to run without errors. In theory, it would be possible to just roll these dependencies into the NCrunch installer and install them with the rest of the proprietary binaries. We don't do this because it bloats the installer, and in almost all cases these dependencies are already installed on the user's machine.

The error is a warning because at the point the package restore fails, we don't actually know 100% whether the package is required by NCrunch's internal code. This is because platform resolution logic is extremely complex and changes between versions of the platform, and there's a high chance that the likely older binary being referenced by NCrunch has a newer version already installed on the machine which can resolve without problems. Some of the packages are also used by niche adapters that might not be needed to crunch your code (i.e. they might be for a test framework or toolset you're not using).

If you see this warning and your code runs fine under NCrunch, then there's actually no action required unless you want to get rid of the warning. If the warning shows and something fails, then restoring the packages is the first thing you should do.

I suspect the issue you've encountered with transient dependencies is unrelated to the above. Most likely this is caused by NCrunch's runtime resolution overrides that are needed to allow dependencies to be properly found by code running in its workspaces, in which case it will sadly be hard for us to replicate the exact behaviour you're experiencing inside the IDE. We try to keep the build results consistent between NCrunch and the IDE, but there are fundamental differences that can't be designed around.

Thanks for sharing the sample solution.

On my side, both of these solutions build in the IDE and NCrunch does a full pass on them without errors or the resolution warning. This seems to be the same for both VS and Rider.

Right now it's not clear to me why you see the NCrunch error on one solution and not the other, but other than circumstance I don't see a way that it is connected to the transient dependency issue you've described. I do expect, however, that if you manually restore the missing package mentioned in the error, it will disappear while the false positive will likely continue to show.

Something I'll flag up is that your project does contain a build customisation in the form of your additional build target (GetDependencyTargetPaths) which injects dependencies into the build. Right now I have no specific issue with this customisation, but you should be aware that we can't test NCrunch to cater for customisations like this as they can have a significant effect on the build system and we have no way to plan for them up front. In this case everything seems to be fine, but if weird stuff starts happening in the build, there won't be much I can do to help.

Appreciating that you haven't had a good experience here with a build issue that NCrunch should have caught for you, but right now I don't see a way to reasonably modify the product in a way that will catch this kind of problem without risking introducing much bigger ones (i.e. causing it to not work at all). Every time we break abstractions to reach down into the build system to change something, we introduce further risks of breaking things unintentionally for configuration sets or environments that we aren't aware of. There needs to be a very good reason to rewire things down there. If NCrunch can build your solution and run tests, I am reluctant to mess with things.

You were right, it seems to be a coincidence, I can't reproduce that error anymore. Sorry for hijacking this thread :)