Problem with Releasifying on Network Drive

[LightBender]

I run a build farm and because we use more than one build machine we have our primary release directory on a network drive to ensure that everybody is using the same historical release data.

I verified that no other builds were being run at the time to ensure there we no conflicts.

Complete Logs:
2018-06-04 01:45:03> Program: Starting Squirrel Updater: --releasify=.\TechniqueDev.2018.604.9.nupkg -r Y:\ --signWithParams=/a /tr http://timestamp.digicert.com /td sha256 /fd sha256 --framework-version=net471 --shortcut-locations=Desktop,StartMenu --icon=.\ServiceInSight.Client\Assets\app.ico --setupIcon=.\ServiceInSight.Client\Assets\app.ico
2018-06-04 01:45:03> Program: Bootstrapper EXE found at:C:\Users\hrabuild.nuget\packages\squirrel.windows\1.8.0\tools\Setup.exe
2018-06-04 01:45:04> Program: Creating release package: Y:\TechniqueDev.2018.604.8.nupkg
2018-06-04 01:45:46> ReleasePackage: Creating release package: Y:\TechniqueDev.2018.604.8.nupkg => Y:\TechniqueDev-2018.604.8-full.nupkg
2018-06-04 01:47:12> Unhandled exception: System.AggregateException: One or more errors occurred. ---> System.ArgumentException: WriteEntryTo or OpenEntryStream can only be called once.
at SharpCompress.Readers.AbstractReader2.WriteEntryTo(Stream writableStream) at SharpCompress.Readers.IReaderExtensions.WriteEntryToFile(IReader reader, String destinationFileName, ExtractionOptions options) at Squirrel.ReleasePackage.<>c__DisplayClass14_2.<extractZipWithEscaping>b__2() at Squirrel.Utility.<>c__DisplayClass8_0.<Retry>b__0() at Squirrel.Utility.Retry[T](Func1 block, Int32 retries)
at Squirrel.Utility.Retry(Action block, Int32 retries)
at Squirrel.ReleasePackage.<>c__DisplayClass14_0.b__0()
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at Squirrel.ReleasePackage.CreateReleasePackage(String outputFile, String packagesRootDir, Func2 releaseNotesProcessor, Action1 contentsPostProcessHook)
at Squirrel.Update.Program.Releasify(String package, String targetDir, String packagesDir, String bootstrapperExe, String backgroundGif, String signingOpts, String baseUrl, String setupIcon, Boolean generateMsi, String frameworkVersion, Boolean generateDeltas)
at Squirrel.Update.Program.executeCommandLine(String[] args)
at Squirrel.Update.Program.main(String[] args)
---> (Inner Exception #0) System.ArgumentException: WriteEntryTo or OpenEntryStream can only be called once.
at SharpCompress.Readers.AbstractReader2.WriteEntryTo(Stream writableStream) at SharpCompress.Readers.IReaderExtensions.WriteEntryToFile(IReader reader, String destinationFileName, ExtractionOptions options) at Squirrel.ReleasePackage.<>c__DisplayClass14_2.<extractZipWithEscaping>b__2() at Squirrel.Utility.<>c__DisplayClass8_0.<Retry>b__0() at Squirrel.Utility.Retry[T](Func1 block, Int32 retries)
at Squirrel.Utility.Retry(Action block, Int32 retries)
at Squirrel.ReleasePackage.<>c__DisplayClass14_0.b__0()
at System.Threading.Tasks.Task.InnerInvoke()
at System.Threading.Tasks.Task.Execute()<---

[LightBender]

This does NOT effect 1.7.9

[Thieum]

@LightBender it's a recurring issue, at least since #488 , and I suspect a more recent issue like #1406 is a variation of this.
An indirect solution to this issue is to work in local for releasify, as it is a lot of read/write over network. So I robocopy/sync the remote folder to something local, make the releasify, then resync back to remote.
Let me know if that helps.

[Thieum]

#671 is another example of issue occurring with releasify over network.

[LightBender]

How about this. Would Squirrel function without the delta packages? My guess is that, in most common cases, simply downloading the whole package for every update is not significantly onerous. Could we be given a switch that disable delta package generation?

[Thieum]

@LightBender it would save more headaches to make the sync / releasify / re-sync part of releasify with a local temp folder imho. We rely on third parties for some operations in releasify, and some of them are not so much network-friendly.

[shiftkey]

Would Squirrel function without the delta packages? My guess is that, in most common cases, simply downloading the whole package for every update is not significantly onerous. Could we be given a switch that disable delta package generation?

@LightBender you can pass in --no-delta to disable this at package time, if desired. And Squirrel should fall back to downloading and installing the full package for the current release if it's unable to generate the release from the delta packages.