Nuget Pack Failure - The process cannot access the file 'D:\a\1\a\*.nupkg'

1.7k views Asked by At

Error on Azure Pipeline for NuGet Pack task, using a SDK format .csproj, which autogenerates the .nuspec file:

The process cannot access the file 'D:\a\1\a\*.nupkg' because it is being used by another process.

System.IO.IOException: The process cannot access the file 'D:\a\1\a\*.nupkg' because it is being used by another process.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.IO.File.InternalDelete(String path, Boolean checkHost)
   at NuGet.Commands.PackCommandRunner.BuildPackage(PackageBuilder builder, String outputPath, Boolean symbolsPackage)
   at NuGet.Commands.PackCommandRunner.BuildFromProjectFile(String path)
   at NuGet.CommandLine.PackCommand.ExecuteCommand()
   at NuGet.CommandLine.Command.ExecuteCommandAsync()
   at NuGet.CommandLine.Command.Execute()
   at NuGet.CommandLine.Program.MainCore(String workingDirectory, String[] args))
##[error]An error occurred while trying to pack the files.

The .csproj file being built, uses TargetsForTfmSpecificBuildOutput:

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <Description>Provides a .....</Description>
  </PropertyGroup>


<PropertyGroup>
    <TargetsForTfmSpecificBuildOutput>$(TargetsForTfmSpecificBuildOutput);CopyProjectReferencesToPackage</TargetsForTfmSpecificBuildOutput>
  </PropertyGroup>
  <Target Name="CopyProjectReferencesToPackage" DependsOnTargets="BuildOnlySettings;ResolveReferences">
    <ItemGroup>
      <!-- Filter out unnecessary files -->
      <_ReferenceCopyLocalPaths Include="@(ReferenceCopyLocalPaths->WithMetadataValue('ReferenceSourceTarget', 'ProjectReference')->WithMetadataValue('PrivateAssets', 'All'))" />
    </ItemGroup>
    <!-- Print batches for debug purposes -->
    <Message Text="Batch for .nupkg: ReferenceCopyLocalPaths = @(_ReferenceCopyLocalPaths), ReferenceCopyLocalPaths.DestinationSubDirectory = %(_ReferenceCopyLocalPaths.DestinationSubDirectory) Filename = %(_ReferenceCopyLocalPaths.Filename) Extension = %(_ReferenceCopyLocalPaths.Extension)" Importance="High" Condition="'@(_ReferenceCopyLocalPaths)' != ''" />
    <ItemGroup>
      <!-- Add file to package with consideration of sub folder. If empty, the root folder is chosen. -->
      <BuildOutputInPackage Include="@(_ReferenceCopyLocalPaths)" TargetPath="%(_ReferenceCopyLocalPaths.DestinationSubDirectory)" />
    </ItemGroup>
  </Target>

The above modification to the .csproj file is needed due to legacy dll's being required to be built which can't be packaged up on their own. But is based on this answer: https://stackoverflow.com/a/59893520/1231374

Note: Removing the custom package steps still causes the error.

There is an additional error before this, not sure if this could be related.

Error NU5128: Some target frameworks declared in the dependencies group of the nuspec and the lib/ref folder do not have exact matches in the other location. Consult the list of actions below: 
- Add a dependency group for .NETStandard2.0 to the nuspec 

See the task configuration below:

enter image description here

See the Nuget installer task, which is the first task the installer runs:

Nuget installer task - 5.8.x

2

There are 2 answers

0
nealsu On BEST ANSWER

The resolution for my problem was to use dotnet pack (as I am working with .NetStandard and .NetCore projects) instead of nuget pack.

dotnet pack task

In particular to enable the Do not build option. As a pervious step builds the solution and projects within it.

0
Guillaume On

I finialy found a "reason" to this problem. I can't use dotnet cli on my side because my project is not compatible, but I find a workaround.

It seems related to that https://github.com/NuGet/Home/issues/8713, so I used the "Nuget Tool Installer" to force version "5.2.x" and it just works as expected.

I don't understand why this problem is present since 5 minor versions !