search

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.66k stars 1.06k forks source link

Could not read the incremental cache file #6215

Closed serdna27 closed 4 years ago

serdna27 commented 8 years ago

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 commented 8 years ago

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

peterblazejewicz commented 8 years ago

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

serdna27 commented 8 years ago

Thanks your solution works.

TheRealPiotrP commented 8 years ago

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

victorhurdugaci commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

I'm seeing this regularly when using dotnet watch.

mclark1129 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

victorhurdugaci commented 8 years ago

@cdmihai were you able to reproduce this?

cdmihai commented 8 years ago

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.

sophie-eihpos commented 8 years ago

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

0xdeafcafe commented 7 years ago

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 commented 7 years ago

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

mcintyre321 commented 7 years ago

I got this while using R#s continuous testing feature

joelharkes commented 7 years ago

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

joelharkes commented 7 years ago

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).