Sdk: Could not read the incremental cache file

[serdna27]

Steps to reproduce

Was working with Aspnet core rc2 with the new tooling. Made some changes to controllers, models among others changes using dotnet watch. After i finished editing an error was thrown in the console: "Could not read the incremental cache file". I stopped the watch re-run the project but the error keep showing.

Environment data

Product Information:
Version: 1.0.0-preview1-002702
Commit Sha: 6cde21225e

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.11
OS Platform: Darwin
RID: osx.10.11-x64

[peterblazejewicz]

@serdna27
I'm getting the same. Have you used dotnet watch tool by chance? I don't remember similar problem with dotnet run

[peterblazejewicz]

@serdna27
try: rm -rf obj/ && dotnet watch from the project root

[serdna27]

Thanks your solution works.

[TheRealPiotrP]

@victorhurdugaci can you take a look? we shouldn't require deleting obj before running dotnet watch

[victorhurdugaci]

Some people reported that on dotnet watch too: https://github.com/aspnet/dotnet-watch/issues/97

I'm not sure if this is a watcher issue. The watcher kills the process and then calls dotnet run (or dotnet <whatever command you pass>).

@serdna27 if you see that error again, can you please what dotnet processes are running and what arguments were used to start them?

[nbarbettini]

I received this error, although I wasn't using dotnet watch. I started a build, then canceled it before it finished. When I tried to build again, dotnet build threw this error.

[shanselman]

I'm seeing this regularly when using dotnet watch.

[mclark1129]

I'm writing a script to build and run all the projects and services needed in my current app. I am able to reproduce this issue 100% of the time in my WebAPI project

dotnet restore
dotnet build **/project.json

start cmd /k "cd MyApp.Api && dotnet run"
start cmd /K "cd MyApp.Services.EventHandlerService && dotnet run"

Both .NET projects were generated using the ASP.NET core yeoman generator (WebAPI and ConsoleApplication, respectively)

They are both targeting net461, although they are built exclusively using dotnet CLI tooling.

My console app starts perfectly every time, the API project fails with the incremental cache error every time. If I run dotnet run in the API window that was spawned, it works fine as well. This only occurs for me when I try to launch the API project as a part of this script.

If I only spawn the API project in the script, then it seems to launch fine. Only attempting to launch more than one project at a time seems to cause it. It does not matter what order I launch the projects, the API project is the one that fails.

[julielerman]

Also getting it after dotnet watch has been run. It prevents me from buildling afterwards. Is there a workaround for now (deleting obj or debug folder does work but is ugly) and will it be fixed by RTM? (My current concern is some upcoming conference demos and running them as efficiently as possible). I followed through the referenced issues and am not finding something that looks like a resolution on the way. Thanks

[victorhurdugaci]

@piotrpMSFT this is a CLI issue. People are able to reproduce it without the watcher. It seems to happen when you run build multiple times (the watcher does that). Can you assign someone to investigate?

cc @cdmihai because he seems to be the author of the file from where the message comes from https://github.com/dotnet/cli/blob/18c8a2724ad066a6999540f5015e1a0ed89b94fc/src/dotnet/commands/dotnet-build/IncrementalCache.cs

[cdmihai]

The cache file is written with FileShare.None and read with FileShare.Read to prevent reading it when it's in a bad state. If you call build on the same output directory in parallel, you might get a race. Does dotnet watch run builds in parallel, or does it try to serialize them?

@victorhurdugaci Do you know the repro steps without dotnet watch?

[victorhurdugaci]

I don't have a repro without the watcher but I have an idea: you run the watcher at the same time as VS; both call build; you end up with a race. You might try build from console instead of the watcher with VS open but simply running build from console will not trigger the race. You probably have to change a file so VS build is triggered too.

dotnet watch waits for the child dotnet process to end before restarting.

[cdmihai]

If dotnet watch waits for the child to exit, I am curious what causes the race. Does dotnet watch respect project dependencies when it triggers builds? If not, it could race when it watches both a project and its dependent projects. If A depends on B, and you have A and B under watch, triggering a parallel dotnet build call on A and B will result in trying to build B twice.

Related to dotnet/sdk#5828

[victorhurdugaci]

dotnet watch calls dotnet run on the project being watched. It only calls it on one project (the top one being watched). My guess it that on the system there might be another dotnet running (like the one from VS) that causes the race.

@shanselman @julielerman @serdna27 @peterblazejewicz was VS/VSCode running while you hit this issues?

[julielerman]

yes vscode was running for sure. I'm doing this while coding/debugging and most often using either the new built in terminal or popping out to a terminal window. This was not something that I triggered via VSCode's debug feature.

[peterblazejewicz]

@shanselman @julielerman @serdna27 @peterblazejewicz was VS/VSCode running while you hit this issues?

@victorhurdugaci OS X console (first class citizen, the next one is via VSCode - but it requires tasks). Thanks!

[shanselman]

@victorhurdugaci Yes, I was running VS code and running within its terminal

[victorhurdugaci]

@cdmihai were you able to reproduce this?

[cdmihai]

I haven't tried, but it is a known issue with build: dotnet/sdk#5828
And it will be a known issue with MSBuild as well.

If we want to fix this, I'd vote for fixing it for MSBuild.

[sifeij]

rm -rf obj/ && dotnet watch from the project root worked for me. Thank you.

[0xdeafcafe]

Was there any further updates on this? It's still happening, and it's incredibly frustrating - especially while developing many services simultaneously. Having to run rm -r ./obj every 15 minutes or so isn't really acceptable.

[TheRealPiotrP]

As @cdmihai mentioned, this will be fixed as Microsoft/MSBuild#2616. As of preview3, the CLI's incremental cache is gone.

[mcintyre321]

I got this while using R#s continuous testing feature

[joelharkes]

We are still running on the project.json version of the dotnet cli, and here we also constantly have the same issue.

[joelharkes]

I even run into this if I manually create dependency tree with a nodjs app. And build dependencies in parallel with dotnet build --no-dependency I wonder if the dotnet build process quits before fileshare flags are set properly?
I'll try adding some hard delays inside my node script/cli tool, and see if this prevents it.

(Had to build it because I want to build and run multiple startup projects)

It would be nice if dotnet run could be forced not to rebuild/check builds (with a CLI flag).