packing on windows with duplicate fsproj file causes lock conflict with self

Start with the pack command path shown in the trace, especially Paket.PackageProcess.Pack and Paket.NupkgWriter.Write, and reproduce it on Windows with a copied .fsproj~ file. Done means the backup file is ignored during packing and the package is created without the self-locking IOException.

Description

A routine projectscaffold build that previously worked has stopped working with a lock conflict on the nupkg file under windows inside GitBash. The ultimate cause is a stray .fsproj~ file left behind by vim but paket picks up the .fsproj~ file and creates a lock conflict with itself.

Repro steps

1. Copy project file GslCore.fsproj to GslCore.fsproj~ in a ProjectScaffold src/GslCore project folder under windows

Attempt to package a file thus

$ .paket/paket.exe pack output "bin" version 0.4.22 releaseNotes  "message"
Paket version 5.1.8
Packed: C:\seq\GslCore\src\GslCore\paket.template
Performance:
 - Runtime: 1 second
Paket failed with:
-> IOException: The process cannot access the file 'C:\seq\GslCore\bin\GslCore.0.4.22.nupkg' because it is being used by another process.

With verbose output

$ .paket/paket.exe pack --verbose output "bin" version 0.4.22 releaseNotes  "Support for seamless primer generation for non linkered designs"
Paket version 5.1.8
found: C:\seq\GslCore\paket.dependencies
Parsing C:\seq\GslCore\paket.dependencies
Could not find AppDataFolder, try to set the APPDATA environment variable. Using 'C:\seq\GslCore\.paket' instead.
Could not detect a root for our (user specific) temporary files. Try to set the 'HOME' or 'LocalAppData' environment variable!. Using 'C:\seq\GslCore\.paket' instead.
Could not find LocalApplicationData folder, try to set the 'LocalAppData' environment variable. Using 'C:\seq\GslCore\.paket' instead
Loading assembly metadata for C:\seq\GslCore\src\GslCore\bin\Release\GslCore.dll
Loading assembly metadata for C:\seq\GslCore\src\GslCore\bin\Release\GslCore.dll
Packed: C:\seq\GslCore\src\GslCore\paket.template
Performance:
 - Runtime: 1 second
Paket failed with:
-> IOException: The process cannot access the file 'C:\seq\GslCore\bin\GslCore.0.4.22.nupkg' because it is being used by another process.
   StackTrace:
        at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
        at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
        at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
        at System.IO.FileStream..ctor(String path, FileMode mode)
        at Paket.NupkgWriter.Write(CompleteCoreInfo core, OptionalPackagingInfo optional, String workingDir, String outputDir)
        at Paket.PackageProcess.Pack@246-4.Invoke(Unit unitVar)
        at Microsoft.FSharp.Control.AsyncBuilderImpl.callA@841.Invoke(AsyncParams`1 args)
     --- End of stack trace from previous location where exception was thrown ---
        at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
        at Microsoft.FSharp.Control.AsyncBuilderImpl.commit[a](AsyncImplResult`1 res)
        at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronouslyInCurrentThread[a](CancellationToken token, FSharpAsync`1 computation)
        at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronously[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
        at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
        at Paket.PackageProcess.Pack[a](String workingDir, DependenciesFile dependenciesFile, String packageOutputPath, FSharpOption`1 buildConfig, FSharpOption`1 buildPlatform, FSharpOption`1 version, IEnumerable`1 specificVersions, FSharpOption`1 releaseNotes, FSharpOption`1 templateFile, FSharpOption`1 excludedTemplates, Boolean lockDependencies, Boolean minimumFromLockFile, Boolean pinProjectReferences, Boolean symbols, Boolean includeReferencedProjects, FSharpOption`1 projectUrl)
        at Paket.Program.main@478-22.Invoke(ParseResults`1 results)
        at Paket.Program.processWithValidation[T](Boolean silent, FSharpFunc`2 validateF, FSharpFunc`2 commandF, ParseResults`1 result)
        at Paket.Program.main$cont@453(ParseResults`1 results, Boolean silent, Boolean fromBootstrapper, Unit unitVar)
        at Paket.Program.main()

Expected behavior

Should ignore the .fsproj~ stray backup left around by vim

Actual behavior

Encounters a file locked error.

Known workarounds

Delete the stray backup file.

Example minimal project file that exercises the bug under windows10, VS2017 envrionment.

GslCoreBug.zip