App.config in up-to-date check causes rebuilds

[KevinRansom]

Opened by: rojepp

When building, the file app.config gets copied to the output directory with a new name, programname.exe.config.

The up-to-date checker regards app.config as an output, causing needless rebuilds, here's what gets logged after enabling up-to-date check logging:

Output: 12/9/2014 9:44:03 AM C:\DEV\VGR\VUF\VUFCONSOLE\OBJ\X86\RELEASE\VUFCONSOLE.EXE
Output: 11/15/2013 1:48:33 PM C:\DEV\VGR\VUF\VUFCONSOLE\APP.CONFIG
Output: 12/9/2014 9:44:03 AM C:\DEV\VGR\VUF\VUFCONSOLE\BIN\RELEASE\NIBBLERCONSOLE.XML
Output: 12/9/2014 9:44:03 AM C:\DEV\VGR\VUF\VUFCONSOLE\OBJ\X86\RELEASE\VUFCONSOLE.PDB
Output: 12/9/2014 9:44:03 AM C:\DEV\VGR\VUF\VUFCONSOLE\BIN\RELEASE\VUFCONSOLE.EXE
Input: 12/9/2014 9:44:02 AM C:\DEV\VGR\VUF\VUFCONSOLE\VUFCONSOLE.FSPROJ
Input: 5/20/2014 8:54:02 PM C:\DEV\VGR\VUF\VUFCONSOLE\VUFCONSOLE.FS
Input: 6/2/2014 8:17:24 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FSHARP.NETFRAMEWORK\V4.0\4.3.0.0\FSHARP.CORE.DLL
Input: 3/18/2010 7:31:26 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FRAMEWORK.NETFRAMEWORK\V4.0\MSCORLIB.DLL
Input: 3/18/2010 7:31:26 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FRAMEWORK.NETFRAMEWORK\V4.0\SYSTEM.DLL
Input: 3/18/2010 7:31:26 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FRAMEWORK.NETFRAMEWORK\V4.0\SYSTEM.DATA.DLL
Input: 3/18/2010 7:31:26 PM C:\PROGRAM FILES (X86)\REFERENCE ASSEMBLIES\MICROSOFT\FRAMEWORK.NETFRAMEWORK\V4.0\SYSTEM.NUMERICS.DLL
Input: 12/9/2014 9:39:42 AM C:\DEV\VGR\VUF\VUF\BIN\RELEASE\VUF.DLL
Freshest input: 12/9/2014 9:44:02 AM
Stalest output: 11/15/2013 1:48:33 PM
Up to date: False

Note that app.config is listed as an output, when really it should be an input, and VufConsole.exe.config should be regarded an output. This means this console app rebuilds every time after app.config hasn't been touched in a while.

comments
latkin wrote Dec 9, 2014 at 10:22 AM [x]

Fixed with cb97ccb
BTW this is the same as #184

latkin wrote Dec 9, 2014 at 10:23 AM [x]
** Closed by latkin 12/09/2014 10:23AM

rojepp wrote Dec 9, 2014 at 11:37 PM [x]
I built the latest bits, and the fix seems to work. Thanks!

rojepp wrote Dec 9, 2014 at 11:41 PM [x]
ProgramName.exe.config should be counted as an output when checking for staleness.
This means a rebuild won't be triggered by manually editing the built config. To be fair, it works the same in C#, but I'd say it is a bug there as well.

latkin wrote Dec 17, 2014 at 4:39 PM [x]
This looks like an easy fix, item type is "AppConfigFileDestination", should be able to just add to the list of input item types.

latkin wrote Dec 17, 2014 at 4:40 PM [x]
Err, sorry. Need to include as an outpu

[enricosada]

I am debugging this , it's very annoying on the solution FSharp

I'll try to fix it, assign it to me

[latkin]

@enricosada thanks for taking this. You just need to update here with well-known item capability similar to here.

[latkin]

It's yours, assigning to myself until we have the ability to assign outside of Microsoft org.

[enricosada]

i cannot repro.

tried with latest ( master branch ) with ad hoc solution and fsharp.sln .
The up-to-date is correct.

I was trying to fix fsharp solution useless rebuild, but this seem ok.

i tried to:

• change generated app.config -> up-to-date
• change original app.config -> up-to-date
• use a Content "file.txt" (with CopyNever, CopyIfNewer, CopyAlways) -> ok

[rojepp]

@enricosada What do you mean when you say 'up-to-date'?

Expected behavior:

• Original app.config changed -> causes rebuild of project
• Generated app.config changed -> no rebuild
• "file.txt" changed -> Rebuild for CopyIfNewer, CopyAlways

[enricosada]

thx @rojepp i'll try your test case

[enricosada]

ok i can repro now, thx

• open solution
• build -> build success
• build -> up to date
• change original app.config
• build -> build success
• build -> build success ( ❗ expected up to date )

[rojepp]

@latkin contributed a fix for that, and I verified it in 3.1.2, so I'm surprised by that.
The remainder of the issue was that generated app.config wasn't considered an output of the build, meaning if generated app.config is older than original app.config it wouldn't cause a rebuild.

If you're going to be working on this, I have to say this registry tip is invaluable: What causes a rebuild in MSBuild

[rojepp]

@enricosada That tip will show files in input and output buckets with their modified times. AFAIR generated app.config is in the wrong bucket (input instead of output) causing strange rebuilds.

[rojepp]

The issue from codeplex above is truncated, and the original issue is gone.

[enricosada]

really thx @rojepp i'll add the registry tip to the wiki, is very nice to know

[latkin]

Yes, F# impl looks at reg key @rojepp mentioned, and logs info to the output window about the files it's looking at and their timestamps. This is the first step to debugging.

Behavior today should be as follows (and I added tests for this, so if it's not working, it needs to be investigated). Assuming everything is built fresh and up-to-date:

• ✅ Modifying app.config source does trigger dirty state and causes rebuild.
  • This was originally not working, and that's what this bug was opened for. I fixed it.
• ❌ Modifying myapp.exe.config output file does not trigger dirty state, will still report "up-to-date"
  • @rojepp noticed this was still not working, so we are looking at it now

Note: C# proj sys has same behavior as us for No. 2 (and always has), so it's not a big deal if we don't fix this.

Thinking about it, it might be tricky. Even if we declare the project dirty and MSBuild runs, I'm not sure that MSBuild is smart enough to re-create the myapp.exe.config file. @enricosada you will have to poke around a bit.

[latkin]

AFAIR generated app.config is in the wrong bucket (input instead of output) causing strange rebuilds.

Generated myapp.exe.config is not in any bucket, it's not tracked at all right now, that's the problem. Source app.config is (now) in proper Input bucket.