CoreResGen should use Inputs in Microsoft.Common.CurrentVersion.targets

[tverboon]

CoreResGen Target in Microsoft.Common.CurrentVersion.targets doesn't use inputs, but the timestamps of references are checked in GenerateResource.cs -> ShouldRebuildResgenOutputFile

Why? Targets like CoreCompile also have a huge list of inputs and outputs.

Because this is part of the task, it makes it harder and to extend / override this part of the build.

[rainersigwald]

The reason is obliquely hidden in the doc comment for that method:

        /// <summary>
        /// Determines if the given output file is up to date with respect to the
        /// the given input file by comparing timestamps of the two files as well as
        /// (if the source is a .resx) the linked files inside the .resx file itself
        /// </summary>
        /// <param name="sourceFilePath"></param>
        /// <param name="outputFilePath"></param>
        /// <returns></returns>
        private bool ShouldRebuildResgenOutputFile(string sourceFilePath, string outputFilePath)

Because the .resx file format allows references to other files (that aren't mentioned in MSBuild anywhwere--you point only to a .resx which may then point to other files), to determine whether an output is up to date requires checking the .resx file itself and anything it references against the output.

Since the linked files are listed in the .resx file but not in MSBuild anywhere, we can't specify them as Inputs to the task. So the task implemented its own incrementality.

@tverboon can you elaborate on what difficulties you're having as a result of this?

[tverboon]

Thank you for response. I realized this when I was trying to customize a target in MSBuild and I was figuring out what the inputs should be.
So, obviously this is not a defect and I agree having this task to manage it is the best solution.

Some background on what I am trying to accomplish. We have a build consisting of hundreds of projects, we can already successfully build these incrementally, but a build of a project that is referenced by other projects will cause a chain reaction in builds, because the referenced assembly has changed. I am trying to prevent this by analyzing the assembly in a custom task after build for the public methods and writing this to a file based on target path. I am using these files in the next build as Input for a custom CoreCompile. Instead of the References, I use my generated files. This works, but then the GenerateResources task is using the References to determine if it should rebuild resgen output file and it should because the reference is updated. Because the Resgen output is updated, this again causes a rebuild of the project because the inputs of the resource is newer.

Obviously this is right, because in my scenario the build won’t be 100% correct in all cases, but a simple rebuild of the referenced project will fix this. We still have to investigate if performance gains are big enough to take the initial penalty and the fact that it won’t be correct with resources.

Thanks again.

On 20 nov. 2015, at 17:53, Rainer Sigwald [email protected] wrote:

The reason is obliquely hidden in the doc comment for that method:

    /// <summary>
    /// Determines if the given output file is up to date with respect to the
    /// the given input file by comparing timestamps of the two files as well as
    /// (if the source is a .resx) the linked files inside the .resx file itself
    /// </summary>
    /// <param name="sourceFilePath"></param>
    /// <param name="outputFilePath"></param>
    /// <returns></returns>
    private bool ShouldRebuildResgenOutputFile(string sourceFilePath, string outputFilePath)

Because the .resx file format allows references to other files (that aren't mentioned in MSBuild anywhwere--you point only to a .resx which may then point to other files), to determine whether an output is up to date requires checking the .resx file itself and anything it references against the output.

Since the linked files are listed in the .resx file but not in MSBuild anywhere, we can't specify them as Inputs to the task. So the task implemented its own incrementality.

@tverboon https://github.com/tverboon can you elaborate on what difficulties you're having as a result of this?

—
Reply to this email directly or view it on GitHub #365 (comment).

[rainersigwald]

@tverboon I'm going to close this since I don't think we can do any better in the core MSBuild engine. However, you may be interested in some work that Roslyn is doing to produce deterministic outputs from the compiler (dotnet/roslyn#372) and explicit reference assemblies from the compiler (dotnet/roslyn#2184). Those changes, with restructured C# targets that use them, will enable stopping the rebuilt-reference cascade.