0

Latest:

This is definitely a bug in msbuild. Other than that there cannot be any other explanation. This could only be happening on Linux or possibly on a wider range.

So i decided to just build one single project with absolutely no dependencies on others in the solution.

Looking at the captured diagnostics, I see these lines which are very promising:

 Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files.
                   Input files: Annotations.cs;Auth.cs;AuthorizationConfig.cs;Backend.cs;Billing.cs;Code.cs;...
                   Output files: .obj/TheAgent.dll;.obj/TheAgent.pdb
                   Set Property: NoWarn=;1701;1702
15:23:27.396     1>Done building target "CoreCompile" in project "TheAgent.csproj".: (TargetId:40)

It looks like my dll and my pdb weren't built which is what I expected. However, something must be happening before or after causing the timestamp to change (be that of this build time and not the last).

The timestamp of the dll is updated both in the intermediate object folder (.obj/) and also in the output folder.

Is there a known way of stopping msbuild right after its CoreCompile task?

Update:

I decided to search for is newer this time and found instances of these. I don't know how they have got to the solution/project files though:

Input file ".obj/Common.csproj.CoreCompileInputs.cache" is newer than output file ".obj/Common.pdb".

Further to the above, I came across this: https://github.com/dotnet/project-system/issues/4736

Thinking that this was the issue, I upgraded to dotnet sdk version 2.2.402. The end result is still the same :(

Original:

I need some pointers on how to troubleshoot this issue. I am using /t:build to build a solution file. The resulting executable keeps getting refreshed each time.

First i thought the package restore was causing this. I have removed that step however it didn't make a difference.

Then I looked at this: https://oz-code.com/blog/visual-studio-keeps-rebuilding-projects-no-good-reason/

I'm basically looking for some text in the diagnostics output which tells me if a target or a file is out of date and needs to be rebuilt. The above link talks about "project 'B' is not up to date". I don't have a not up to date in my msbuild output.

I already had two resources with CopyAlways which I changed to CopyIfNewer.

The above article also talks about circular dependencies. I am checking everything manually. And yes the references to dependent project are actually references to the project outputs (dll's /exe's). So Finding a circular dependency by just checking for that pattern seems a little odd.

Community
  • 1
  • 1
Jeff Saremi
  • 2,674
  • 3
  • 33
  • 57
  • Do you have a [Minimal, Reproducible Example](https://stackoverflow.com/help/minimal-reproducible-example)? without that, the question is impossible to answer without knowing your setup. – Martin Ullrich Sep 13 '19 at 20:24
  • No I don't. And I'm not going down that path. The amount of effort to try to recreate what is have is very likely to be larger than the effort needed to figure out what is wrong – Jeff Saremi Sep 13 '19 at 20:31
  • Maybe some of the suggestions [here](https://stackoverflow.com/questions/14916729/visual-studio-rebuilds-unmodified-projects) or [here](https://michaelscodingspot.com/visual-studio-keeps-rebuilding-projects-no-good-reason/) will help. If I recall correctly, files which are copied to the output directory with "copy always" are problematic and it can help to use "Copy if newer" instead. – Phil Jollans Sep 14 '19 at 07:30
  • Good suggestions. I have tried the ones that apply to my case already. Msbuild is broken period. I have simplified the problem to one standalone project and it fails. I have a link to the github issue in the main post – Jeff Saremi Sep 14 '19 at 22:30

1 Answers1

0

There was one more problems in the dotnet platform and/or msbuild causing this to fail. One of those was this https://github.com/dotnet/project-system/issues/4736

Installing SDK 3.0.100-preview7-012821 or better solved the problem

Jeff Saremi
  • 2,674
  • 3
  • 33
  • 57