-
Notifications
You must be signed in to change notification settings - Fork 385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding existing cs files or empty code files doesn't trigger FastUpdate #2347
Comments
This also works with the default new xml file, which should stop build anyways as it doesn't have a root element. |
@mattscheffer can you try adding that existing cs file explicitly in the project by editing the csproj? i.e add a |
A couple of things on that.
|
I think the issue here is globbing. If you add a file, we don't touch the project file. If that new file has a timestamp that's older than the last build, the up to date check will think everything is up to date. Similarly, if you delete a file, the fast up to date check won't notice it because the project file is no longer modified. |
But shouldn't the new file show up as a new source input? |
Yes, but we don't track whether the input list has changed, we just check timestamps. In the non-glob world, that's fine since we track the project file as well, but in the glob world, we need to track if the list changes, that's the fix. |
Oh you are saying it shows up as an input that it has an older timestamp? @rainersigwald doesn't msbuild have a cache for this case - basically a file listing the previous state or something like that? |
Yes, MSBuild hashes the You could probably add that as an input to FUTD. |
Never mind, that won't be updated when FUTD runs. CPS watches the directory and knows to reevaluate if a file is added. Maybe you can hook that somehow? @lifengl? |
Since we're subscribed to the dataflow, we'll get update notifications for items. We just need to invalidate when we receive notification that the item list has changed. It does mean that the first build after you open the project will always fail the fast up to date check. (If we really want to not do that, I guess we could try and do the same hashing and check MSBuild's file, but that seems like a further step.) |
I believe the policy from MSBuild is "don't depend on the hash algorithm being stable in any way across releases" so I'd advise against reimplementing in that way. Right @AndyGerlicher? |
Using PR Build: https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_git/VS/pullrequest/70878?_a=files
Expected
FastUpdate triggers the rebuild
Actual
FastUpdate thinks everything is up to date.
Log below is from adding an existing Class2.cs file from another project. Log is similar if a empty codefile is added instead.
The text was updated successfully, but these errors were encountered: