Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Disable auto restoring nuget packages
Options
Previous Topic Next Topic
michaellogutov
#1 Posted : Monday, June 5, 2017 8:46:15 AM(UTC)
Rank: Member

Groups: Registered
Joined: 2/2/2015(UTC)
Posts: 24
Location: Russia

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
Hello.
We're using nCrunch console tool in our CI flow and trying to optimize it's speed.
I see that initialization queue tasks took a long time (we have a solution with over 100 projects) - and I see those "auto restoring NuGet packages" steps for every project.
Now, restoring nuget packages for our solution take couple of seconds which is a lot faster than what ncrunch do and I thought that it would be great to have option to disable ncrunch package restore and force it to use packages from "/packages" directory.
Back to top
 |  Edit by user
Remco
#2 Posted : Monday, June 5, 2017 11:30:58 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
The console tool is programmed to always run "msbuild /t:Restore" for each project at load time. This is because the newer MS CLS project system and .NET Core projects require 'restore' to be run to initialise the project.assets.json file inside the /obj directory for each project. VS does this automatically when you load the project inside the IDE, and if the console tool doesn't do this, the projects can fail to load correctly.

If you're already running this task inside your CI system, probably it's redundant that the console tool does this too. Disabling it as a feature request would make sense, and you are most welcome to formally request it if you like.

It might be possible to skip the 'restore' step by changing the MSBuild target files installed on your CI server, so that the network based action of the Restore target has a condition such as "'$(NCrunch)' != '1'". This is a bit hacky but would prevent MSBuild from making network requests when it's being called by the NCrunch console tool.
Back to top
michaellogutov
#4 Posted : Monday, June 5, 2017 11:34:27 AM(UTC)
Rank: Member

Groups: Registered
Joined: 2/2/2015(UTC)
Posts: 24
Location: Russia

Thanks: 1 times
Was thanked: 4 time(s) in 4 post(s)
Thanks. Probably changing msbuild is a way to go for us.
Back to top
Grendil
#3 Posted : Monday, September 11, 2017 11:43:02 PM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 3/18/2017(UTC)
Posts: 54
Location: United States of America

Thanks: 22 times
Was thanked: 11 time(s) in 10 post(s)
Remco;10517 wrote:
The console tool is programmed to always run "msbuild /t:Restore" for each project at load time. This is because the newer MS CLS project system and .NET Core projects require 'restore' to be run to initialise the project.assets.json file inside the /obj directory for each project. VS does this automatically when you load the project inside the IDE, and if the console tool doesn't do this, the projects can fail to load correctly.

If you're already running this task inside your CI system, probably it's redundant that the console tool does this too. Disabling it as a feature request would make sense, and you are most welcome to formally request it if you like.

It might be possible to skip the 'restore' step by changing the MSBuild target files installed on your CI server, so that the network based action of the Restore target has a condition such as "'$(NCrunch)' != '1'". This is a bit hacky but would prevent MSBuild from making network requests when it's being called by the NCrunch console tool.


We're dealing with the same issue. We have 150 projects and the NCrunch console spends 12 minutes restoring nuget packages, which has noticeable impact on our CI test runs. I'm not clear on why this is taking so long, or how to work around it. There's only about a dozen nuget packages in use, but most of that set is used by all of the projects. I haven't been aware of this long lag happening when building in Visual Studio.

We use this console run to farm the tests out on the grid nodes...do the grid nodes also then replicate this long restore process?

The total build time from staring the NCrunch command line until test tasks first start being sent to nodes is a full 30 minutes, so we're eager to find ways to shorten this up.
Back to top
Remco
#5 Posted : Tuesday, September 12, 2017 12:39:31 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,161

Thanks: 964 times
Was thanked: 1296 time(s) in 1202 post(s)
My guess would be here that because the console tool does this for each individual project, it's less efficient than doing it for the solution as a whole. Probably if you have many projects using many nuget packages, 12 minutes might even be achievable in a worst case scenario.

I'm considering deactivating this feature, because most people seem to perform a restore step in their CI before they build anyway, so having NCrunch do it is rather redundant, not to mention slow.

There is no grid involvement in the restore feature. It needs to happen prior to projects being loaded, so it only gets executed on the client.
Back to top
1 user thanked Remco for this useful post.
GreenMoose on 9/12/2017(UTC)
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.041 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download