Constant restores?

[tobz]

Heyo!

Firstly, thank you for writing this. I'm enjoying the whole ASP.NET 5/MVC 6/DNX ecosystem, and being able to use it with Xamarin Studio, on OS X, no less!

So, using the DNX 0.1 addin + Xamarin Studio 5.10.2 functions correctly, BUT, it murders my computer in terms of CPU usage, and, ocassionally, kills Xamarin Studio itself.

What I've noticed is, out of the blue, there seems to be a lot of "restore" operations being triggered i.e.:

mono .../.dnx/runtimes/dnx-mono.1.0.0-rc1-final/bin/Microsoft.Dnx.Host.Mono.dll .../.dnx/runtimes/dnx-mono.1.0.0-rc1-final/bin/lib/Microsoft.Dnx.Tooling/Microsoft.Dnx.Tooling.dll restore

These processes max out a full CPU, and it spawns a bunch of them. I've watched it go through a whole pocket of this spiked CPU usage and it goes through at least 10 - 12 execs (i.e. new PID) of the aforementioned command.

This happens literally out of the blue. Solution open, no dependency changes, start typing.... and bam.

Any thoughts? This essentially makes any DNX development impossible if it's just through Xamarin Studio.

[tobz]

More information after realizing there's a DNX Output window:

it seems like the freezes happen specifically when it goes to write lock files. Also, it seems that doing any DNX action -- build, test, etc -- triggers these restores/lock file writes.

At this point, it might be unrelated to the addin, but any insight?

[nathanielcook]

Try unchecking "Automatically Restore Dependencies" in the Add-in Settings. If you don't have that setting then use v0.1.1. More info here: #10

[tobz]

Success! That seemed to do the trick. :D

[mrward]

The restore logic is taken pretty much unchanged from OmniSharp.

A restore will be triggered when:

1. DNX host tells the addin that there are unresolved dependencies.
2. File watcher detects the project.json file has changed.
3. File watcher detects the project.lock.json file has changed.

So I would not expect a restore to be started when typing into any file in the text editor. It should happen if a project.json or project.lock.json file is saved.

If there are dependent projects then a restore will be started for each dependent project if the main project.json or project.lock.json file is changed.

I suspect this restore logic will have to be reviewed and modified to reduce the number of times a restore is started.

I have also added a Restore menu option which can be used, along with the option in Preferences to disable automatic restore, to run the restore manually instead of automatically.

[mrward]

Looking at the latest OmniSharp code they no longer run a restore when the lock file has been changed. So a quick way to improve this may be to do the same.

[tobz]

Yeah, I'm not sure how it would be triggering either. Something about adding imports (right-click on an un-imported namespace, click Resolve, etc) maybe?

I'm not entirely privy to how things are broken up now in the brave new DNX world, but I'm writing a lot of new code: new files, new classes, etc. The import thing is definitely something I was/am doing a lot, and that's the only thing that strikes me as somehow being able to trigger a restore.

[mrward]

I am unable to reproduce a restore when adding an import or editing other files. If I edit and save the project.json then there are several file watcher events that fire, mostly for the project.lock.json file.

I do not see 10 to 12 restore processes started when I save the project.json file, although my solution only contains one project. When I save the project.json I see a lot of file watcher events fired for the project.lock.json and in total the addin runs 2 or 3 restores. Ideally it would run the restore only once. The second and third restore are triggered by the project.lock.json file being changed. When changes to the lock file are ignored then the restore seems to only happens once.

When the project.json file is saved in the text editor I see:

• 4 file watcher events for project.json
• 2 unresolved dependencies messages back from the DNX host (even if nothing has changed in the project.json file)
• 40+ file watcher events for project.lock.json

If the lock file changes are ignored, for a single project.json save there are 6 attempts to start a restore, but if a restore is currently running those other events are ignored, so the restore only runs the once if the lock file watcher events are ignored. When the lock file changes are not ignored we have 46+ attempts to trigger a restore which can often trigger multiple restores for a single save of the project.json file.

So ignoring the lock file changes may improve things. However there might be another bug lurking if the restore is somehow being triggered by editing other C# files.