-
Notifications
You must be signed in to change notification settings - Fork 8
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
Incremental build is slowed by timestamps of generated source file #17
Comments
Hey, thanks for the report and the detailed reproduction guide! I’m a bit busy right now, but I‘ll gladly look into it when I find the time. I’m on the phone right now, so I cannot load your example project and play around with the issue, but two remarks just based on the issue text:
|
|
Alright, thanks for the clarification on (1)! That helps with understanding the issue. Regarding (2): I cannot tell whether that is a bug with NuGet. What I can say is that I’m not doing anything but including the attribute files as content files from within the nuspec. While I would expect NuGet to cache the files, they may be overwritten with the same content during every build. Perhaps that happens to prevent manual modification? Not sure. What I’ll take away from this is that I should migrate away from including the files via the nuspec and instead do it via a targets file. I guess that this is a very reasonable approach without any drawbacks (which I should potentially have used long ago anyway). Thanks again for opening the issue and for providing the details and help! |
Hi. Regarding switching to new SDK format I have created a topic at the discussions tab. I think the approach to use the "content"-/"contentFiles"-feature of NuGet and therefore <file ... /> in .nuspec-file is the right one. When using the "via a targets file"-approach you have to include the .cs-files into a custom folder (package), copy these .cs-files manually to the obj-folder of consuming project and add them manually via <Compile ...>...false dependent on framework. Not pretty to be honest. |
Hi, I also played around and tried switching from NuGet's features to a As to the updated timestamps: I have another suspicion which could cause the updates. I am including the CS files as @teroneko Thanks a lot for your input and your project! As written above, I agree with you that, at the moment, using NuGets features seem better. |
I'm sure I could help make it work.
Agreed. It's much simpler that way.
That's a very good hypothesis. We can file a bug against nuget as they should run the transform in an isolated directory and only copy the result if its content changed.
So you use the pp extension to alter how the file appears in Solution Explorer? And you specifically do not want the file to appear under a virtual folder? |
Hello @AArnott. I tried to reproduce your problem, but I am honest, I cannot reproduce it. My steps done so far after cloned Library.Template once before:
Inspect msbuild.binlog by searching for $task csc => I tested it several times and also with my package; same result. |
Well, I just tried it fresh @teroneko and it still repros for me. I don't know why it wouldn't for you. |
Well, the only change I can see is the obvious change from SDK version 5.0.103 to 5.0.201. Please check this, |
I agree, and I tried the SDK version change locally as well, but the problem still repros. |
I use Cygwin and did the following
It still remains the same and we don't get any further. |
At your prompting, I've tried with WSL Ubuntu 20 as well, and I still see the same problem of 4 CSC tasks running. Even if the behavior isn't consistent across machines, it should be. I plan to file a bug against nuget tomorrow. |
Hey, sorry for not replying for that long! Following your comments, I also tried it out again and I'm getting yet another result: This was the result after:
If I then run the exact same flow again without deleting Here are the full logs: |
What I can also say is that the Take that with a grain of salt though, things might fluctuate in different environments. |
Particularly when setting:
We expect that when A references B and B changes in a way that does not impact its public API, then A does not need to be recompiled. But when A has a package reference to Nullable, it recompiles anyway for no good reason, making incremental builds slower.
Can you fix this by ensuring the timestamp is not updated on this file unnecessarily?
You can test this for yourself, and verify the effectiveness of your fix, using my template repo as follows:
Then make a change to Calculator.cs that does not impact the public API. Perhaps this:
Then run:
Open up the msbuild.binlog (in the https://msbuildlog.com viewer) and search for
$task csc
to see how many times the compiler actually ran. We want to see it just once. WhenNullable
is not referenced, this happens. But when it is referenced, we see 4.The text was updated successfully, but these errors were encountered: