Don't generate deps or runtimeconfig files when build has failed but _CleanRecordFileWrites is being run

[dsplaisted]

Fixes #1234

The GenerateBuildRuntimeConfigurationFiles runs before _CheckForCompileOutputs, so that the FileWrites items it adds will be picked up by _CleanGetCurrentAndPriorFileWrites, and incremental builds and cleans will work correctly. (See some discussion of this on #381)

However, the CoreBuild target invokes the _CleanRecordFileWrites target when it errors:

  <Target
      Name="CoreBuild"
      DependsOnTargets="$(CoreBuildDependsOn)">

    <OnError ExecuteTargets="_TimeStampAfterCompile;PostBuildEvent" Condition="'$(RunPostBuildEvent)'=='Always' or '$(RunPostBuildEvent)'=='OnOutputUpdated'"/>
    <OnError ExecuteTargets="_CleanRecordFileWrites"/>

  </Target>

This means that even if there is a previous build error, we are trying to generate the runtime config files. In the case of #1234, the output path where we would write them hasn't been created, so the task throws an exception.

This PR adds a condition to only run the task if the folder it's going to write to exists. This feels like a band-aid solution though. Is there a better way to structure this which would add the correct FileWrites items when needed, but not even run the target if GetReferenceAssemblyPaths or some other target before-hand has failed?

@rainersigwald @AndyGerlicher @nguerrera

[nguerrera]

Definitely a band aid. I think we should run earlier by a different mechanism. From an email thread about a related problem, beforetargets=copyfilestooutputdirectory instead of after build should do the trick.

[nguerrera]

We need to find a proper fix

[nguerrera]

Looks good now. Please update the description to match the new change.

[dsplaisted]

@dotnet-bot

test Ubuntu16.04 Release
test Windows_NT Release
test Windows_NT_FullFramework Release

[dsplaisted]

@MattGertz for approval

Customer scenario

Build targeting a version of .NET Framework where the reference assemblies aren't installed. This fixes an issue where an extra (and far more verbose error) would be reported, making it less obvious what the problem was.

Bugs this fixes:

#1234

Workarounds, if any

Read the error spew carefully

Risk

Low

Performance impact

Low to none - This just changes where in the build we do some work.

Is this a regression from a previous update?

No

Root cause analysis:

Some of our targets were running even when the build failed, which caused them to fail (since the output path didn't exist).

How was the bug found?

Dogfooding

[dsplaisted]

@dotnet-bot test Ubuntu16.04 Release

[MattGertz]

(Just for bar context -- note that I would probably have punted on this after next week.)