rainersigwald commented on Mar 4, 2017

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".)

pranavkm commented on Mar 24, 2017

Noticed another variant of this - the CLI happily creates the intermediate file with a path too long, but doesn't copy it to the output directory. Desktop .NET returns false for file existence, maybe that has something to do with it.

tmat commented on Jun 29, 2017

Why not $(IntermediateOutputPath)$(TargetFileName).config?

rainersigwald commented on Jun 29, 2017

That seems like a reasonable option, too. I don't know whether exe-name or project-name is a "more unique" key for those who take the painful road of sharing an obj directory.

tmat commented on Jun 29, 2017

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:

pranavkm commented on Jun 29, 2017

@tmat for the time being, we've resorted to shortening our project names. Seems less hacky than changing an internal property.

I'm currently facing the same problem, and blogged about it here - mostly in terms of how I diagnosed it.

This does seem pretty unnecessarily long at the moment.

nguerrera commented on Aug 30, 2017

Tomas' rationale is right. If TargetFileName weren't unique in obj then you'd already be hosed. Can we go with it and get this fixed in 15.5?