New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PathTooLongException with _GenerateBindingRedirectsIntermediateAppConfig #1786

Closed
bricelam opened this Issue Mar 2, 2017 · 8 comments

Comments

Projects
None yet
7 participants
@bricelam

bricelam commented Mar 2, 2017

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?

@rainersigwald

This comment has been minimized.

Show comment
Hide comment
@rainersigwald

rainersigwald Mar 3, 2017

Contributor

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

Contributor

rainersigwald commented Mar 3, 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

This comment has been minimized.

Show comment
Hide comment
@pranavkm

pranavkm Mar 23, 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.

pranavkm commented Mar 23, 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

This comment has been minimized.

Show comment
Hide comment
@tmat

tmat Jun 29, 2017

Member

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

Member

tmat commented Jun 29, 2017

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

@rainersigwald

This comment has been minimized.

Show comment
Hide comment
@rainersigwald

rainersigwald Jun 29, 2017

Contributor

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.

Contributor

rainersigwald commented 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

This comment has been minimized.

Show comment
Hide comment
@tmat

tmat Jun 29, 2017

Member

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:

image

Member

tmat commented 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:

image

@pranavkm

This comment has been minimized.

Show comment
Hide comment
@pranavkm

pranavkm Jun 29, 2017

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

pranavkm commented Jun 29, 2017

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

@jskeet

This comment has been minimized.

Show comment
Hide comment
@jskeet

jskeet Aug 30, 2017

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.

jskeet commented Aug 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Aug 30, 2017

Member

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?

Member

nguerrera commented 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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment