NuGet 2.7 included a new Automatic Package Restore feature to replace the package restore process that depends on MSBuild integration. A comparison of how the two approaches differ is summarized here. After migrating a solution to the new automatic package restore, NCrunch was no longer to build my projects because it could no longer locate the binaries in my NuGet packages.
I attempted to set "Copy referenced assemblies to workspace" to true, and even instructed NCrunch to copy the entire packages folder to my workspace, without success.
Reverting my projects to use the MSBuild-integrated package restore fixed the issue.
Build/Test Issues
NCrunch fails to build solutions using Automatic Package Restore
Started by distilled on 5,039 views
Remco NCrunch Developer
#5657
10 Apr 2014 21:35 UTC
Hi, thanks for sharing this issue.
Since V1, NCrunch has deliberately disabled Nuget package restore for its own builds. Because Nuget was previously performing this via a custom build target, the approach taken here was simply to remove the build target. This was done because the auto package restore was kicking in for each individual workspace, causing the references to be downloaded again and again, which is very inefficient. This means that you would need to perform a Visual Studio build against a solution before you could run NCrunch on it, to make sure that all the packages were restored before NCrunch would begin processing.
If I understand the new package restore method correctly, the same situation applies. NCrunch won't restore the packages automatically so it is dependent on you performing a manual build in Visual Studio first. One point of difference that may now exist is around NCrunch's synchronisation with these references. Previously, Nuget was probably touching the project file triggering NCrunch to reload projects after the references were restored. It's likely that this is no longer the case, so you'll need to reset the NCrunch engine after the packages have been restored. This will cause the engine to resync and detect the newly restored references.
Does this match your experience with package restore?
Since V1, NCrunch has deliberately disabled Nuget package restore for its own builds. Because Nuget was previously performing this via a custom build target, the approach taken here was simply to remove the build target. This was done because the auto package restore was kicking in for each individual workspace, causing the references to be downloaded again and again, which is very inefficient. This means that you would need to perform a Visual Studio build against a solution before you could run NCrunch on it, to make sure that all the packages were restored before NCrunch would begin processing.
If I understand the new package restore method correctly, the same situation applies. NCrunch won't restore the packages automatically so it is dependent on you performing a manual build in Visual Studio first. One point of difference that may now exist is around NCrunch's synchronisation with these references. Previously, Nuget was probably touching the project file triggering NCrunch to reload projects after the references were restored. It's likely that this is no longer the case, so you'll need to reset the NCrunch engine after the packages have been restored. This will cause the engine to resync and detect the newly restored references.
Does this match your experience with package restore?
Post a reply
Log in to reply.