dotnet pack fails with project references and <TargetFramework> #3865

Closed
joelverhagen opened this Issue Nov 3, 2016 · 6 comments

Comments

Projects
None yet
6 participants
@joelverhagen
Member

joelverhagen commented Nov 3, 2016

Steps

  1. dotnet new two .csproj
  2. Add a project reference from one to another (projectA -> projectB)
  3. Make sure both have <TargetFramework> not <TargetFrameworks>
  4. dotnet restore both
  5. dotnet build both
  6. dotnet pack projectA

Expected

projectA should have a .nupkg produced.

Actual

The "PackTask" task failed unexpectedly.
System.IO.FileNotFoundException: File not found: 'C:\Users\jver\Desktop\repro\packpr\obj\Debug\packpr.dll'.
   at NuGet.Packaging.PackageBuilder.AddFiles(String basePath, String source, String destination, String exclude)
   at NuGet.Packaging.PackageBuilder.PopulateFiles(String basePath, IEnumerable`1 files)
   at NuGet.Commands.MSBuildProjectFactory.CreateBuilder(String basePath, NuGetVersion version, String suffix, Boolean buildIfNeeded, PackageBuilder builder)
   at NuGet.Commands.PackCommandRunner.BuildFromProjectFile(String path)
   at NuGet.Commands.PackCommandRunner.BuildPackage(String path)
   at NuGet.Commands.PackCommandRunner.BuildPackage()
   at NuGet.Build.Tasks.Pack.PackTask.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__25.MoveNext()
@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Nov 3, 2016

Member

dotnet --info

.NET Command Line Tools (1.0.0-preview3-004007)

Product Information:
 Version:            1.0.0-preview3-004007
 Commit SHA-1 hash:  80ec02b4da

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
Member

joelverhagen commented Nov 3, 2016

dotnet --info

.NET Command Line Tools (1.0.0-preview3-004007)

Product Information:
 Version:            1.0.0-preview3-004007
 Commit SHA-1 hash:  80ec02b4da

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64

@rrelyea rrelyea added the Priority:1 label Nov 3, 2016

@zhili1208

This comment has been minimized.

Show comment
Hide comment
@zhili1208

zhili1208 Nov 3, 2016

Contributor

Looks like it's not our issue.
the issue only happens when project A reference project B.

Msbuild will pass two paths to nuget pack task in TargetPathsToAssemblies like following:
C:\Users[username]\Documents\test\testproj5\obj\Debug\netstandard1.4\testprojA.dll
C:\Users[username]\Documents\test\testproj5\obj\Debug\testprojA.dll

the first one is right one, the second one doesn't exist, that's why nuget throw.

those two paths are returned by msbuild task Targets="BuiltProjectOutputGroup;DocumentationProjectOutputGroup"

Contributor

zhili1208 commented Nov 3, 2016

Looks like it's not our issue.
the issue only happens when project A reference project B.

Msbuild will pass two paths to nuget pack task in TargetPathsToAssemblies like following:
C:\Users[username]\Documents\test\testproj5\obj\Debug\netstandard1.4\testprojA.dll
C:\Users[username]\Documents\test\testproj5\obj\Debug\testprojA.dll

the first one is right one, the second one doesn't exist, that's why nuget throw.

those two paths are returned by msbuild task Targets="BuiltProjectOutputGroup;DocumentationProjectOutputGroup"

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Nov 4, 2016

See dotnet/sdk#356 (comment). The issue is in the way the msbuild calls in the pack targets are batched and not a problem in the SDK targets.

See dotnet/sdk#356 (comment). The issue is in the way the msbuild calls in the pack targets are batched and not a problem in the SDK targets.

@nguerrera

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera Nov 4, 2016

When I remove all of the seemingly unnecessary usage of %(_MSBuildProjectReferenceExistent) in the local copy of the pack targets in my package cache, then the pack succeeds in this case.

nguerrera commented Nov 4, 2016

When I remove all of the seemingly unnecessary usage of %(_MSBuildProjectReferenceExistent) in the local copy of the pack targets in my package cache, then the pack succeeds in this case.

@rainersigwald

This comment has been minimized.

Show comment
Hide comment
@rainersigwald

rainersigwald Nov 4, 2016

I agree that that usage seems unnecessary--it's creating multiple invocations of the same project for combinations of TargetFrameworks (desired) + various project-reference properties (not needed since they don't apply to the project being built.

I agree that that usage seems unnecessary--it's creating multiple invocations of the same project for combinations of TargetFrameworks (desired) + various project-reference properties (not needed since they don't apply to the project being built.

@rrelyea rrelyea assigned zhili1208 and mishra14 and unassigned zhili1208 Nov 4, 2016

@joelverhagen joelverhagen self-assigned this Nov 4, 2016

joelverhagen added a commit to joelverhagen/NuGet.Client that referenced this issue Nov 4, 2016

Remove unnecessary _MSBuildProjectReferenceExistent references
Pass the parent project's TFM down to the client project as _ParentTargetFramework
Fix NuGet/Home#3865

joelverhagen added a commit to joelverhagen/NuGet.Client that referenced this issue Nov 7, 2016

Remove unnecessary _MSBuildProjectReferenceExistent references
Pass the parent project's TFM down to the client project as _ParentTargetFramework
Fix NuGet/Home#3865

joelverhagen added a commit to joelverhagen/NuGet.Client that referenced this issue Nov 7, 2016

Remove unnecessary _MSBuildProjectReferenceExistent references
Pass the parent project's TFM down to the client project as _ParentTargetFramework
Fix NuGet/Home#3865

joelverhagen added a commit to joelverhagen/NuGet.Client that referenced this issue Nov 8, 2016

@joelverhagen joelverhagen reopened this Nov 8, 2016

@joelverhagen

This comment has been minimized.

Show comment
Hide comment
@joelverhagen

joelverhagen Nov 8, 2016

Member

This has only been checked into dev (4.0.0-rc2). This should be closed when we cherry-pick to 4.0.0-rc branch.

Member

joelverhagen commented Nov 8, 2016

This has only been checked into dev (4.0.0-rc2). This should be closed when we cherry-pick to 4.0.0-rc branch.

@joelverhagen joelverhagen reopened this Nov 9, 2016

@rrelyea rrelyea modified the milestones: 4.0 RC2, 4.0 RC Nov 11, 2016

@joelverhagen joelverhagen modified the milestones: 4.0 RC2, 4.0 RC Dec 7, 2016

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