PathTooLongException with _GenerateBindingRedirectsIntermediateAppConfig

We just hit a PathTooLongException on EF because this variable was producing the following path.

C:\Projects\EntityFramework\test\Microsoft.EntityFrameworkCore.SqlServer.Design.FunctionalTests\obj\Debug\netcoreapp1.1\Microsoft.EntityFrameworkCore.SqlServer.Design.FunctionalTests.csproj.Microsoft.EntityFrameworkCore.SqlServer.Design.FunctionalTests.dll.config

That filename seems rather excessive. Does it really need both $(MSBuildProjectFile) and $(TargetFileName) in there?

[tmat]

If the .exe/.dll name wasn’t unique the assembly would collide in the shared obj directory.

Workaround:

<Target Name="WorkaroundAppConfigPathTooLong"
          BeforeTargets="GenerateBindingRedirects">
    <PropertyGroup>
      <_GenerateBindingRedirectsIntermediateAppConfig>$(IntermediateOutputPath)$(TargetFileName).config</_GenerateBindingRedirectsIntermediateAppConfig>
    </PropertyGroup>
  </Target>

produces:

[rainersigwald]

It doesn’t seem like it at first glance.

I’ve been spelunking through history trying to figure out why it’s this way, and it seems to have been introduced in dev12 with GenerateBindingRedirects. I suspect it was named this way as a compromise between

• The standard $(IntermediateOutputPath)$(MSBuildProjectFile).{filename} pattern for project-singleton caches and
• The standard app-config naming convention of $(TargetFileName).config

This does cause duplication in the standard case, and having a very long project name that’s the same as the assembly name is not uncommon.

I think we could change this variable to $(IntermediateOutputPath)$(MSBuildProjectFile).app.config. Anyone have an idea why not?

(Obligatory “the real problem is #53 and then don’t worry about this”. Obligatory “but we live in the current world”.)