In this commit, you removed the Clowd.Squirrel.props file from the nuget package. What were the reasons for this?

I'm currently migrating a project away from Squirrel.Windows, and the SquirrelToolsPath property that it exposes is quite important to me. Would it be possible to re-include it?

RandomEngy/VidCoder#979

Just looking at the logs here I noticed the uninstall routine tries to delete Update.exe during the main folder deletion, which fails, obviously, because Update.exe is running. We should avoid attempting to deleting self until the uninstall is finished. At the end of the uninstall routine there is already code to clean up Update.exe after it exits.

Hi. I am unable to create the executable after I did it a couple of times. The command is stopping with the following exception. My published files are about 2.2Gb and the NuGet package it creates is 730MB.

❯         Squirrel.exe pack --packId "app" --packVersion $buildVersion --packDirectory $publishPath
[INFO] NugetConsole: Starting to package 'C:\Users\Rahul\AppData\Local\SquirrelClowdTemp\tempm\app.nuspec'
[INFO] NugetConsole: Successfully created package 'C:\Users\Rahul\AppData\Local\SquirrelClowdTemp\tempm\app.2.2.0.nupkg'.
[INFO] Program: Creating release package: E:\workspace\ReleaseFiles\Releases\app.2.2.0.nupkg
[INFO] ReleasePackage: Creating release package: E:\workspace\ReleaseFiles\Releases\app.2.2.0.nupkg => E:\workspace\ReleaseFiles\Releases\app-2.2.0-full.nupkg
[INFO] ReleasePackage: Removing unnecessary data
[INFO] ReleasePackage: No release notes found in C:\Users\Rahul\AppData\Local\SquirrelClowdTemp\tempo\app.nuspec
[INFO] Program: Package architecture: X64 (implicit, from a SquirrelAware binary)
[INFO] Program: Creating stub executables
[INFO] EasyZip: Compressing 'C:\Users\Rahul\AppData\Local\SquirrelClowdTemp\tempo' to 'E:\workspace\ReleaseFiles\Releases\app-2.2.0-full.nupkg'...


[INFO] Program: Creating Setup bundle

[ERRO] System.ComponentModel.Win32Exception (0x80070008): Not enough memory resources are available to process this command.
   at Microsoft.NET.HostModel.ResourceUpdater.ThrowExceptionForLastWin32Error() in ./Internal/ResourceUpdater.cs:line 472
   at Microsoft.NET.HostModel.ResourceUpdater.AddResource(Byte[] data, String lpType, IntPtr lpName, UInt16 langId) in ./Internal/ResourceUpdater.Squirrel.cs:line 31
   at Squirrel.Lib.BundledSetupInfo.WriteValue(ResourceUpdater updater, Int32 idx, Byte[] buf) in ./Internal/BundledSetupInfo.cs:line 73
   at Squirrel.Lib.BundledSetupInfo.WriteToFile(String exePath) in ./Internal/BundledSetupInfo.cs:line 58
   at SquirrelCli.Program.Releasify(ReleasifyOptions options) in ./Program.cs:line 324
   at SquirrelCli.Program.Pack(PackOptions options) in ./Program.cs:line 124
   at SquirrelCli.CommandAction`1.Execute(IEnumerable`1 args) in ./ValidatedOptionSet.cs:line 160
   at SquirrelCli.CommandSet.Execute(String[] args) in ./ValidatedOptionSet.cs:line 194
   at SquirrelCli.Program.Main(String[] args) in ./Program.cs:line 77



Squirrel (2.7.98-pre+88e1cc) command line tool for creating and deploying Squirrel releases
Usage: Squirrel.exe [verb] [--option:value]

Package Authoring:

pack: Creates a Squirrel release from a folder containing application files
  -r, --releaseDir=DIRECTORY      Output DIRECTORY for releasified packages
  -u, --packId=ID                 Unique ID for release
  -v, --packVersion=VERSION       Current VERSION for release
  -p, --packDir=DIRECTORY         DIRECTORY containing application files for release
      --packTitle=NAME            Optional display/friendly NAME for release
      --packAuthors=AUTHORS       Optional company or list of release AUTHORS
      --includePdb                Add *.pdb files to release package
      --releaseNotes=PATH         PATH to file with markdown notes for version
  -n, --signParams=PARAMETERS     Sign files via SignTool.exe using these PARAMETERS
      --signTemplate=COMMAND      Use a custom signing COMMAND. '{{file}}' will be
                                    replaced by the path of the file to sign.
      --noDelta                   Skip the generation of delta packages
  -f, --framework=RUNTIMES        List of required RUNTIMES to install during setup
                                    example: 'net6,vcredist143'
  -s, --splashImage=PATH          PATH to image/gif displayed during installation
  -i, --icon=PATH                 PATH to .ico for Setup.exe and Update.exe
      --appIcon=PATH              PATH to .ico for 'Apps and Features' list
      --msi=BITNESS               Compile a .msi machine-wide deployment tool with the
                                    specified BITNESS. (either 'x86' or 'x64')

releasify: Take an existing nuget package and convert it into a Squirrel release
  -r, --releaseDir=DIRECTORY      Output DIRECTORY for releasified packages
  -p, --package=PATH              PATH to a '.nupkg' package to releasify
  -n, --signParams=PARAMETERS     Sign files via SignTool.exe using these PARAMETERS
      --signTemplate=COMMAND      Use a custom signing COMMAND. '{{file}}' will be
                                    replaced by the path of the file to sign.
      --noDelta                   Skip the generation of delta packages
  -f, --framework=RUNTIMES        List of required RUNTIMES to install during setup
                                    example: 'net6,vcredist143'
  -s, --splashImage=PATH          PATH to image/gif displayed during installation
  -i, --icon=PATH                 PATH to .ico for Setup.exe and Update.exe
      --appIcon=PATH              PATH to .ico for 'Apps and Features' list
      --msi=BITNESS               Compile a .msi machine-wide deployment tool with the
                                    specified BITNESS. (either 'x86' or 'x64')

Package Deployment / Syncing:

b2-down: Download recent releases from BackBlaze B2
b2-up: Upload releases to BackBlaze B2
  -r, --releaseDir=DIRECTORY      Output DIRECTORY for releasified packages
      --b2BucketId=VALUE
      --b2keyid=VALUE
      --b2key=VALUE

http-down: Download recent releases from an HTTP source
  -r, --releaseDir=DIRECTORY      Output DIRECTORY for releasified packages
      --url=VALUE                 Base url to the http location with hosted releases

github-down: Download recent releases from GitHub
  -r, --releaseDir=DIRECTORY      Output DIRECTORY for releasified packages
      --repoUrl=VALUE             Full url to the github repository
                                    example: 'https://github.com/myname/myrepo'
      --token=VALUE               OAuth token to use as login credentials

sometime between releases 2.7.34 and the current release, Versioning appears(at least in my case) to be broken. I've cloned the repo and taken a look at whats going on behind the scenes. It appears to first version correctly and pack my project into a nuget package successfully. However it then proceeds to run releasify on that nuget package. At which time it calls SemanticVersion.TryParseInternal

On the initial pack command that method is used to verify the version is correct and while debugging i can indeed see my versioning get through validation

When releasify is then ran on the nuget package instead of my version being passed to that command, It seems to duplicate my version with a dash. So, for example, if i provided 1.0.0 what i see come in is actually 1.0.0-1.0.0 this will obviously fail validation and causes builds to not complete.

Hi Casey,

warning SYSLIB0014: 'WebClient.WebClient()' is obsolete: 'WebRequest, HttpWebRequest, ServicePoint, and WebClient are obsolete. Use HttpClient instead.'

Do you have any plans to remove the WebClient und use HttpClient in FileDownloader.cs instead?

Best,
Andreas

Update.exe should be automatically updated during regular app updates.
We should probably copy Update.exe into the app release packages, and copy it into the correct location when applying updates, so Squirrel can also be updated automatically.

I'm calling Squirrel via this msbuild target. The Squirrel http-down command works fine however the Squirrel pack command produces the error message i included below.

A quick internet search revealed that this is error message is from nuget complaining about $PATH, i check $PATH multiple time and spotted nothing unusual.

The strangest thing is that when i copy the command that msbuild executes and call it manually it just works.

Msbuild target:

  <Target Name="Package" AfterTargets="Publish" Condition=" '$(Configuration)' == 'Release' ">
    <PropertyGroup>
      <PackageDir>$(MSBuildProjectDirectory)\Packages\</PackageDir>
      <cs_PublishDir>$(MSBuildProjectDirectory)\$(PublishDir)</cs_PublishDir>
      <Squirrel>$(PkgClowd_Squirrel)\tools\Squirrel</Squirrel>
    </PropertyGroup>

    <Exec Command="$(Squirrel) http-down --url=http://update-server.com/updates/package --releaseDir=$(MSBuildThisFileDirectory)Releases\ " />
    <Exec Command="$(Squirrel) pack --packName=package --packVersion=$(Version) --packAuthors=company --packDirectory=&quot;$(cs_PublishDir) &quot; --splashImage=.\installdisk.gif --framework=net5 --releaseDir=&quot;$(MSBuildThisFileDirectory)Releases&quot;"/>

  </Target>

Squirrel pack error:

[ERRO] System.Exception: Failed nuget pack (exit 1): 
   Illegal characters in path.
     at SquirrelCli.Program.Pack(PackOptions options)
     at SquirrelCli.CommandAction`1.Execute(IEnumerable`1 args)
     at SquirrelCli.CommandSet.Execute(String[] args)
     at SquirrelCli.Program.Main(String[] args)

Squirrel pack command called by msbuild:

.nuget/packages/clowd.squirrel/2.6.2-pre/tools/Squirrel pack --packName=package --packVersion=10.3.0 --p
ackAuthors=company --packDirectory=bin/Release/net5.0-windows/publish --splashImage=installdisk.gif --framework=net
5 --releaseDir=Releases

A user might ship a net5 app, and subsequently publish an update to net6 - but this is impossible with Squirrel as the runtime bootstrapping is done by Setup.exe which is not preserved.

Now that Update.exe is fully self-contained, we could move the runtime bootstrapping to Update.exe (or even Squirrel.dll) to allow new runtimes to be installed during updates.

We now have the capability to check the app manifest for the SquirrelAwareVersion attribute (and this should probably be the preferred way going forward as it works uniformly for native apps, C# apps, and single file apps).

Perhaps the runtime dependency could also be read from the manifest (net6), and we can check binaries during updates to confirm that all the required runtimes are indeed installed. This could also allow us to automatically update minor versions (eg. 5.0.6 to 5.0.7) if an app requests it.

We need to be using a different tool for signing (we have one in our company that signs via azure). It would be great if there was an argument to squirrel.exe to be able to use it in addition to the signParams that are already there. Something like this (applied to the sample from the docs):

Squirrel pack`
 --framework net6,vcredist143-x86`  # Install .NET 6.0 (x64) and vcredist143 (x86) during setup, if not installed
 --packName "YourApp"`              # Application / package name
 --packVersion "1.0.0"`             # Version to build. Should be supplied by your CI
 --packAuthors "YourCompany"`       # Your name, or your company name
 --packDirectory ".\publish"`       # The directory the application was published to
 --setupIcon "mySetupIcon.ico"`     # Icon for Setup.exe
 --splashImage "install.gif"        # The splash artwork (or animation) to be shown during install
 --signingExe "C:/path/to/my/signtool.exe"
 --signParams "params to my signtool"

This should be calling C:/path/to/my/signtoo.exe params to my signtool (note that the "sign" argument should not be in here if overriding the signingExe).

For reference, ours needs to be called like this: AzureSignTool.exe -f "filetosign" -p "password"

It's currently possible for x86 squirrel, running on x86 windows, to install an x64 program. Of course, this program will fail to run hooks, fail to create shortcuts, and be entirely useless.

It would be better if Setup.exe verified the bitness of Squirrel Aware apps, and refused to install if the binaries are unsupported on the current operating system.

It would probably make sense to analyse the binaries ahead of time while building releases and storing metadata in the package somewhere, so the executables do not need to be extracted during install if they are incompatible.

Now that Squirrel is on dotnet 6, there is no reason we can't build cross-platform binaries and consider adding support for other operating systems.

Windows arm64

There are not a lot of code changes required to support arm64 properly, most of this is just recompiling binaries. There also should not be any compatibility issues creating x64 packages on arm, or vice versa.

To support applications being deployed to arm64:

• Add appropriate enumerations to RuntimeCpu
• Update AssemblyRuntimeInfo to check for ARM when detecting OS machine architecture
• [ ] Compile StubExecutable.exe, Setup.exe, Update.exe for arm64. (they are all x86 at the moment, technically windows on arm supports x86 emulation, so maybe we could skip this) (x86 binaries can be virtualised on x64 and arm64)
• Update SquirrelCli.Releasify to check for incompatibilities between x86/x64 and ARM when building packages and store the correct machine architecture into the package metadata.
• [ ] Also update SquirrelCli.Releasify to use the appropriate Setup86 or SetupArm64 (and Update86/etc...) depending on the package architecture. (not needed since we are only building x86)
• Update error message logic in Update.Setup when checking current architecture

To support compiling releases on arm64:

• Update WiX and investigate how to build an arm64 MSI (wixtoolset/issues#5558 (comment))
• [ ] Compile Squirrel.exe for arm64 (not needed as Squirrel.exe is now a cross-platform csq tool)
• Add arm64 variants of other vendor binaries or confirm that they can run successfully on arm64 (rcedit, signtool, singlefilehost)

macOS

I do not believe we can support building packages for macOS on windows as codesign and xcrun/altool is not available. Similar issues trying to build windows packages from MacOS, but we can use Wine to fill in some of the gaps. I will not support installing dotnet runtimes on linux/macos, so only self-contained apps will be supported.

We can create universal binaries for mac that work natively for more than one operating system / cpu architecture using lipo, this seems to be preferred instead of having separate downloads in Apple's ecosystem. Example:

clang++ main-mac.mm -o bin/mac_x86 -fobjc-arc -framework Cocoa -target x86_64-apple-macos10.12
clang++ main-mac.mm -o bin/mac_arm64 -fobjc-arc -framework Cocoa -target arm64-apple-macos11
lipo -create -output bin/mac_universal bin/mac_x86 bin/mac_arm64

We should probably bundle RID osx.10.12-x64 and osx.11.0-arm64 at a minimum to cover off the two widely used CPU architectures.

We install to %localappdata% on windows, the closest thing on macos is probably %userprofile%/Applications which seems to be uncommon but used by some.

• Generate .app bundle during releasify instead of Setup.exe
  Can look at https://docs.avaloniaui.net/docs/distribution-publishing/macos for some inspiration.
• Binaries need to be codesigned, and .app bundle needs to be notarized.
• Create a .pkg which installs the application into ~/Applications (NOT /Applications)
• #24 needs to be completed
• Comb through Utility, make sure all the file paths, process starts, process enumeration etc have abstractions for macos
• Cross-platform ZIP implementation to replace 7z
• Remove MsDelta logic, we have bsdiff anyway and it's faster
• Review temporary paths used by UpdateManager, these can not be stored in the app folder like we do on Windows.
• Replace the "Apply Updates" logic, remove shortcuts, registry entries etc. We'll update the program by just replacing the current .app with a new one.
• Create a new Update.exe for macos - most of the windows functionality is not relevant, we really only need it to swap out the .app bundles during an update.

After successful packing of the application. I'm experiencing an install error.

Error in /SquirrelTemp/Squirrel-Install.log:
error: ApplyReleasesImpl: Couldn't run Squirrel hook, continuing: C:\Users\mitja\AppData\Local\GBot\app-0.4.4\GBot.exe: System.ComponentModel.Win32Exception (14001): An error occurred trying to start process 'C:\Users\mitja\AppData\Local\GBot\app-0.4.4\GBot.exe' with working directory 'C:\Users\mitja\AppData\Local\SquirrelTemp'. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

Error in EventViewer:
Activation context generation failed for "C:\Users\mitja\AppData\Local\GBot\app-0.4.4\GBot.exe".Error in manifest or policy file "C:\Users\mitja\AppData\Local\GBot\app-0.4.4\GBot.exe" on line 3. The element SquirrelAwareVersion appears as a child of element urn:schemas-microsoft-com:asm.v1^assembly which is not supported by this version of Windows.

The same application was installed successfully using previous release.

Content of GBot.manifest:

<assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1">
  <assemblyIdentity version="0.4.4.0" name="GBot.App"/>
  <SquirrelAwareVersion>1</SquirrelAwareVersion>
</assembly>´

Are there any log files written when the app install is happening? I'm having reports come in of people getting stuck and I need to figure out what's going on:

RandomEngy/VidCoder#979

Using 2.7.98-pre.

Using net5, TrimMode=link can achieve a binary size of around 21mb. It's not amazing and could be improved.

Using the following settings, and .net6.0-preview7, we can achieve 13.7mb. I've not tested this binary extensively.

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <PublishSingleFile>true</PublishSingleFile>
    <SelfContained>true</SelfContained>
    <LangVersion>10</LangVersion>
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>link</TrimMode>
    <EnableCompressionInSingleFile>true</EnableCompressionInSingleFile>
    <TrimmerRemoveSymbols>true</TrimmerRemoveSymbols>
    <EnableUnsafeBinaryFormatterSerialization>false</EnableUnsafeBinaryFormatterSerialization>
    <EnableUnsafeUTF7Encoding>false</EnableUnsafeUTF7Encoding>
    <EventSourceSupport>false</EventSourceSupport>
    <HttpActivityPropagationSupport>false</HttpActivityPropagationSupport>
    <MetadataUpdaterSupport>false</MetadataUpdaterSupport>
    <InvariantGlobalization>true</InvariantGlobalization>
    <UseSystemResourceKeys>true</UseSystemResourceKeys>
  </PropertyGroup>

NativeAOT looks promising but requires further changes beyond the above, probably primarily the removal of COM in favor of ComWrappers.

Some additional properties to possibly look in to if using NativeAOT:

  <PropertyGroup>
    <IlcGenerateStackTraceData>false</IlcGenerateStackTraceData>
    <IlcDisableReflection>true</IlcDisableReflection>
    <IlcOptimizationPreference>Size</IlcOptimizationPreference>
    <IlcFoldIdenticalMethodBodies>true</IlcFoldIdenticalMethodBodies>
  </PropertyGroup>

Currently the file size is far too large with NativeAOT, much larger than the normal PublishSingleFile. I'm afraid that we will need to cut out some of the larger dependencies, primarily NuGet where there is a huge amount of unused code and dependencies we're carrying around.

During PublishSingleFile builds, corehost/apphost.exe is compiled and dependencies are appended in a bundle. When run, dependencies are extracted to a temporary directory and loaded.

When using BeginUpdateResource and EndUpdateResource, this bundle is removed, and the resulting exe is useless. This means that neither WriteZipToSetup nor rcedit.exe can be used to update the icon of Update.exe.

Potentially we could detect the presence of a .net core native bundle, copy it to a temporary file, and copy it back after the resources are updated but far more research is needed.

See following for more info -
https://github.com/dotnet/runtime/blob/main/src/native/corehost/apphost/bundle_marker.cpp
https://github.com/dotnet/designs/blob/main/accepted/2020/single-file/

ResourceHacker seems to be able to replace the icon without losing the bundle, but the resulting exe is still broken. This deserves some more testing.

I have a .net48 project, planning on upgrading to .net6 as soon as I get upgrading figured out. Using 2.7.89-pre and following the examples on the front page readme, I do a simple Squirrel.exe pack and get a PlaceHolderNotfoundInAppHostException.

I tried .39-pre and got the same error. .34-pre would caused my code not to compile, so I didn't check any other versions.
I noticed that IsSingleFileBundle is passing in the Update.exe, so I deleted and restored the nuget cache to ensure it wasn't a corrupt file.

I haven't been able to determine if the Update.exe file is actually in the temp location as it is cleaned up directly after the error.

~\.nuget\packages\clowd.squirrel\2.7.89-pre\tools\Squirrel.exe pack --packId "Simulator" --packVersion "1.0.0" --packDirectory .\bin\net48\ --releaseDir C:\Users\chase_wallis\SimulatorRelease\

[INFO] NugetConsole: Starting to package 'C:\Users\chase_wallis\AppData\Local\SquirrelClowdTemp\tempa\Simulator.nuspec'
[INFO] NugetConsole: Successfully created package 'C:\Users\chase_wallis\AppData\Local\SquirrelClowdTemp\tempa\Simulator.1.0.0.nupkg'.

[ERRO] Microsoft.NET.HostModel.AppHost.PlaceHolderNotFoundInAppHostException: Exception of type 'Microsoft.NET.HostModel.AppHost.PlaceHolderNotFoundInAppHostException' was thrown.
   at Microsoft.NET.HostModel.AppHost.HostWriter.<>c__DisplayClass4_0.<IsBundle>g__FindBundleHeader|0() in ./HostModel/AppHost/HostWriter.cs:line 234
   at Microsoft.NET.HostModel.RetryUtil.RetryOnIOError(Action func) in ./HostModel/AppHost/RetryUtil.cs:line 32
   at Microsoft.NET.HostModel.AppHost.HostWriter.IsBundle(String appHostFilePath, Int64& bundleHeaderOffset) in ./HostModel/AppHost/HostWriter.cs:line 242
   at SquirrelCli.SingleFileBundle.IsSingleFileBundle(String peFile) in ./SingleFileBundle.cs:line 30
   at SquirrelCli.Program.Releasify(ReleasifyOptions options) in ./Program.cs:line 161
   at SquirrelCli.Program.Pack(PackOptions options) in ./Program.cs:line 124
   at SquirrelCli.CommandAction`1.Execute(IEnumerable`1 args) in ./ValidatedOptionSet.cs:line 160
   at SquirrelCli.CommandSet.Execute(String[] args) in ./ValidatedOptionSet.cs:line 194
   at SquirrelCli.Program.Main(String[] args) in ./Program.cs:line 77

I was building a few and installing a few clowd.squirrel based releases locally when windows defender started to complain about a trojan in squirrel.exe/update.exe. I can now neither run the pack/releaseify commands nor any previously built installer :(. Have you seen this before?

As of 2.7.34-pre, UpdateManager requires an applicationName parameter. I assume this is the --packName/--packId? But the examples in README.md still have one parameter.

DisplayErrorMessage can be called with either no logFile, or with a path to a logFile that does not exist. In both of those cases, a modal is shown with the buttons Open Setup Log and Close - but clicking Open Setup Log does nothing.

Fix:

• If there is no log file provided, or the file does not exist, the Open Setup Log button should not appear.
• If Update.exe --install is the thing that failed, we should link up to that log file. (maybe, we specify a log file location via a command line argument when starting Update.exe?)
• Review logging in Setup.exe more generally - make sure it is working, being stored in a sensible location, has good coverage etc.

Currently, Update.exe has to scan Setup.exe for the placeholder marker to extract the setup bundle when installing. This is not needed, because Setup.exe has access to the offset and length variables already.

We should remove the reference from Update->Squirrel.Shared and then pass the bundleOffset and bundleLength arguments via cli to Update.exe during install to speed this up.

I have a .NET 5.0 project which uses the Clowd.Squirrel package (2.7.79-pre at the time of writing).

I use a powershell command to releasify my NuGet package of the project. It works perfectly when used directly from a powershell window (paths and names are simplified here, but otherwise the same command):
& "C:\Program Files\Clowd.Squirrel\Squirrel.exe" releasify --releaseDir "C:\My Releases" --package "C:\My NuGet Packages\My_App.0.1.2.nupkg" --framework "net5" --splashImage "C:\My Resources\splash.png" --icon "C:\My Resources\logo.ico" --appIcon "C:\My Resources\logo.ico"

This creates all the necessary files, the setup works and the application updates correctly.

I use a TeamCity build pipeline to automate my release process. Using the previous command in a powershell build step yields the following messages:

Step 7/7: Clowd Squirrel Releasify (PowerShell) (6s)
[11:13:11][Step 7/7] PowerShell Executable: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
[11:13:11][Step 7/7] Working directory: C:\TeamCity\buildAgent\work\d720619d382a4b8a
[11:13:11][Step 7/7] Command: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
[11:13:11][Step 7/7] PowerShell arguments: -NoProfile, -NonInteractive, -ExecutionPolicy, ByPass, -File, C:\TeamCity\buildAgent\temp\buildTmp\powershell8389058061481115215.ps1
[11:13:12][Step 7/7] [INFO] SingleFileBundle: Extracting Update.exe resources to temp directory
[11:13:12][Step 7/7] [INFO] SingleFileBundle: Patching Update.exe icon
[11:13:13][Step 7/7]
[11:13:13][Step 7/7] [INFO] SingleFileBundle: Re-packing Update.exe bundle
[11:13:14][Step 7/7] [INFO] Program: Creating release package: C:\My Releases\My_App.0.1.2.nupkg
[11:13:14][Step 7/7] [INFO] ReleasePackage: Creating release package: C:\My Releases\My_App.0.1.2.nupkg => C:\My Releases\My_App-0.1.2-full.nupkg
[11:13:14][Step 7/7] [INFO] ReleasePackage: Removing unnecessary data
[11:13:15][Step 7/7] [INFO] Program: Creating stub executables
[11:13:15][Step 7/7] [INFO] Program: Using app icon from command line arguments
[11:13:15][Step 7/7] [INFO] EasyZip: Compressing 'C:\Windows\system32\config\systemprofile\AppData\Local\SquirrelClowdTemp\tempb' to 'C:\My Releases\My_App-0.1.2-full.nupkg'...
[11:13:17][Step 7/7] [INFO] DeltaPackageBuilder: Extracting C:\My Releases\My_App-0.1.1-full.nupkg and C:\My Releases\My_App-0.1.2-full.nupkg into C:\Windows\system32\config\systemprofile\AppData\Local\SquirrelClowdTemp\tempc
[11:13:17][Step 7/7] [INFO] EasyZip: Extracting 'C:\My Releases\My_App-0.1.1-full.nupkg' to 'C:\Windows\system32\config\systemprofile\AppData\Local\SquirrelClowdTemp\tempb'...
[11:13:17][Step 7/7] [INFO] EasyZip: Extracting 'C:\My Releases\My_App-0.1.2-full.nupkg' to 'C:\Windows\system32\config\systemprofile\AppData\Local\SquirrelClowdTemp\tempc'...
[11:13:17][Step 7/7] 
[11:13:17][Step 7/7] [ERRO] System.InvalidOperationException: Sequence contains no matching element
[11:13:17][Step 7/7]    at System.Linq.ThrowHelper.ThrowNoMatchException()
[11:13:17][Step 7/7]    at Squirrel.DeltaPackageBuilder.CreateDeltaPackage(ReleasePackage basePackage, ReleasePackage newPackage, String outputFile) in ./Internal/DeltaPackage.cs:line 40
[11:13:17][Step 7/7]    at SquirrelCli.Program.Releasify(ReleasifyOptions options) in ./Program.cs:line 258
[11:13:17][Step 7/7]    at SquirrelCli.CommandAction`1.Execute(IEnumerable`1 args) in ./ValidatedOptionSet.cs:line 160
[11:13:17][Step 7/7]    at SquirrelCli.CommandSet.Execute(String[] args) in ./ValidatedOptionSet.cs:line 194
[11:13:17][Step 7/7]    at SquirrelCli.Program.Main(String[] args) in ./Program.cs:line 77

I have tried:

• Placing the command into a .ps1 file to run it in the build step (instead of pasting the command into TeamCity)
• Running Command Line to execute the same .ps1 file
  Both cases produced the same error.

Workaround:
Adding the --noDelta flag skips the delta package building, where the build step otherwise fails. This works both "by hand" and "through TeamCity". On the flip side, updating the application will always download the full package (since there or no deltas).

Personal findings:
It seems that the DeltaPackageBuilder fails because the packages have wrong version numbers (based on source code). This was also evident when I checked the SquirrelClowdTemp temporary folders. One of the .nuspec files contained an earlier version number, while the newest one was nowhere to be found.

I don't entirely understand the releasify process and I currently don't have the time to dive into it so that's why I opened this issue.

Because ZipPackage does not implement IDisposable, it closes the underlying stream after each read. This means that GetFiles needs to copy every file in the package into memory before the end of the method (so subsequent file accesses do not attempt to read from a closed stream)

This behaviour was inherited from NuGet, but there is very little left of the original NuGet code. This method should be removed entirely, or refactored such that only the necessary/requested files are loaded into memory.

I'm testing with version 2.7.34-pre and I found that Squirrel.exe remains in the application directory.
When I was using version 2.6.34-pre, Squirrel.exe didn't exist after installation (only Update.exe in the directory above).
* I am aware that Squirrel.exe has been in the full nupkg files before 2.7.*

My understanding is that Update.exe and Squirrel.exe are exactly the same (I checked that their file hash match), and maybe Squirrel.exe is renamed to Update.exe after installation/update.

Not a super big deal, but both Squirrel.exe & Update.exe occupy around 12 MB for a .NET 6.0 app and having these large files duplicated seems a bit wasteful to me.

Do we really need both Squirrel.exe & Update.exe?
Or am I doing something wrong?

Thanks

2.7.79-pre fails to pack due to Windows Defender detecting a threat:

* Here, "EventViewer" is just an app's name.

PS C:\Users\Admin\Desktop\EventViewer> C:\Users\Admin\.nuget\packages\clowd.squirrel\2.7.79-pre\tools\Squirrel.exe pack --packName EventViewer --packVersion 0.11.11 --packAuthors 'me' --packDirectory .\EventViewer\bin\Release\net6.0-windows\

... snipped...

[INFO] EasyZip: Compressing 'C:\Users\Admin\AppData\Local\SquirrelClowdTemp\tempc' to 'C:\Users\Admin\Desktop\EventViewer\Releases\EventViewer-0.11.11-full.nupkg'...
[WARN] EasyZip: Unable to create archive with 7z.exe
7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21

Open archive: C:\Users\Admin\Desktop\EventViewer\Releases\EventViewer-0.11.11-full.nupkg
--
Path = C:\Users\Admin\Desktop\EventViewer\Releases\EventViewer-0.11.11-full.nupkg
Type = zip
Physical Size = 12955594

Scanning the drive:
25 folders, 899 files, 33066695 bytes (32 MiB)

Updating archive: C:\Users\Admin\Desktop\EventViewer\Releases\EventViewer-0.11.11-full.nupkg

Keep old data in archive: 9 files, 5553 bytes (6 KiB)
Add new data to archive: 25 folders, 899 files, 33066695 bytes (32 MiB)


Files read from disk: 899
Archive size: 12956222 bytes (13 MiB)

WARNINGS for files:

lib\native\EventViewer_ExecutionStub.exe : Operation did not complete successfully because the file contains a virus or potentially unwanted software.
----------------
WARNING: Cannot open 1 file


WARNING: Operation did not complete successfully because the file contains a virus or potentially unwanted software.
lib\native\EventViewer_ExecutionStub.exe


[ERRO] System.IO.IOException: Operation did not complete successfully because the file contains a virus or potentially unwanted software. : 'C:\Users\Admin\AppData\Local\SquirrelClowdTemp\tempc\lib\native\EventViewer_ExecutionStub.exe'
   at Microsoft.Win32.SafeHandles.SafeFileHandle.CreateFile(String , FileMode , FileAccess , FileShare , FileOptions )
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String , FileMode , FileAccess , FileShare , FileOptions , Int64 )
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String , FileMode , FileAccess , FileShare , FileOptions , Int64 )
   at SharpCompress.Archives.IWritableArchiveExtensions.AddAllFromDirectory(IWritableArchive writableArchive, String filePath, String searchPattern, SearchOption searchOption)
   at Squirrel.EasyZip.CreateZipFromDirectory(String outputFile, String directoryToCompress) in ./Internal/EasyZip.cs:line 40
   at Squirrel.ReleasePackage.CreateReleasePackage(String outputFile, Func`2 releaseNotesProcessor, Action`2 contentsPostProcessHook) in ./Internal/ReleasePackage.cs:line 126
   at SquirrelCli.Program.Releasify(ReleasifyOptions options) in ./Program.cs:line 194
   at SquirrelCli.Program.Pack(PackOptions options) in ./Program.cs:line 124
   at SquirrelCli.CommandAction`1.Execute(IEnumerable`1 args) in ./ValidatedOptionSet.cs:line 160
   at SquirrelCli.CommandSet.Execute(String[] args) in ./ValidatedOptionSet.cs:line 194
   at SquirrelCli.Program.Main(String[] args) in ./Program.cs:line 77

When the issue occurs, Windows Defender shows the following:

This is 100 % reproducible with 2.7.79-pre.
However, when I use Squirrel.exe of 2.7.34-pre on the same machine for the same app, the issue does not occur.

[ERRO] System.AggregateException: One or more errors occurred. (The data is invalid.)
---> System.ComponentModel.Win32Exception (0x8007000D): The data is invalid.
at Microsoft.NET.HostModel.ResourceUpdater.ThrowExceptionForLastWin32Error() in ./Internal/ResourceUpdater.cs:line 472
at Microsoft.NET.HostModel.ResourceUpdater.Update() in ./Internal/ResourceUpdater.cs:line 367
at SquirrelCli.Program.createExecutableStubForExe(String exeToCopy) in ./Program.cs:line 388
at Squirrel.Utility.<>c__DisplayClass20_11.<<ForEachAsync>b__1>d.MoveNext() in ./Internal/Utility.cs:line 323 --- End of inner exception stack trace --- at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean ) at System.Threading.Tasks.Task.Wait(Int32 , CancellationToken ) at System.Threading.Tasks.Task.Wait() at SquirrelCli.Program.<>c__DisplayClass4_0.<Releasify>b__9(String pkgPath, ZipPackage zpkg) in ./Program.cs:line 237 at Squirrel.ReleasePackage.CreateReleasePackage(String outputFile, Func2 releaseNotesProcessor, Action2 contentsPostProcessHook) in ./Internal/ReleasePackage.cs:line 123 at SquirrelCli.Program.Releasify(ReleasifyOptions options) in ./Program.cs:line 187 at SquirrelCli.Program.Pack(PackOptions options) in ./Program.cs:line 126 at SquirrelCli.CommandAction1.Execute(IEnumerable`1 args) in ./ValidatedOptionSet.cs:line 160
at SquirrelCli.CommandSet.Execute(String[] args) in ./ValidatedOptionSet.cs:line 194
at SquirrelCli.Program.Main(String[] args) in ./Program.cs:line 79

Hi,

we have migrated our app from NET framework using the regular squirrel.windows to NET5 using clowd.squirrel. When installing from a setup file generated with clowd.squirrel the proper frameworks are installed correctly (we're using --framework net5-x86,vcredist142-x86) in this case. If these runtimes are already installed, upgrading from the old application to the new using auto-update works fine. But if they are not installed, windows will complain about them not existing and launch a website to download them instead of the installer taking care of it. I get that it may not be possible to fix this, but is there a workaround to this perhaps? I guess the same worry would apply when later upgrading to NET6 later.

Thanks

In one of the recent updates it seems like packName has been deprecated in favor of PackId. So that brings up a question around the naming conventions here. For example a program named Example Application, Would work just fine as a program name. However that wouldnt work as a packId since no spaces are allowed within the packId.

In that example we have a nuspec file that specifies the displayName but it seems to be ignored. When desktop shortcuts and uninstall triggers are ran, they are done without the space. I realize this is a pretty minor issue but I'm just wondering if I'm missing something

When installing .net 5/6 applications, Squirrel will allow an application to be installed if the major version matches. Eg, using the --framework net6 argument, Squirrel only verifies that any version of net6 is installed (6.0.0, 6.0.1, etc).

If an application depends on a higher version (6.0.1) and a lower version is installed (6.0.0) this can produce extremely undesirable behaviour. The user does not even get the expected "Net 6 is not installed, click here to download" dialog, which is shown when no version of net6 is installed. Instead, the exe can just silently crash if they require code from the higher runtime version.

It will be important to support this properly to ensure people do not install broken applications.

One option is to require application authors to be extremely specific about what version the application is built for (eg --framework net602 instead of just --framework net6).

Another option might be using a tool like ildasm and reading the dll manifest references which are version specific. We could detect the highest required version and then automatically make sure it's lower to or equal to the installed runtime during setup. Possibly PeNet can read this manifest already rather than shipping another external tool. (edit: PeNet can load the CLR MetaData Tables and look at AssemblyRef, but only MajorVersion is shown on http://penet.io/ - need to have a look at code and see if we can get minor/revision too. ILSpy can show the full version, so presumably it's possible)

See more RandomEngy/VidCoder#979

This issue does not impact the full framework or vcredist as major/minor/revision versions are already considered there; this issue only impacts netcore3 and net5/6.

Mono.Cecil can't load an exe produced by PublishSingleFile. Do we try to read the entry assembly by looking for the bundle offset and parse the attribute? Probably not a great idea as these bundles might change significantly in future versions of dotnet.

It's also not possible to add the native SquirrelAwareApp entry to the version table (with rcedit or other) because this breaks the bundle. (see #1)

Perhaps we need a way to detect a Squirrel app that is a bit more universal. Reading exe manifest? Looking for a sidecar file (eg. myapp.exe.squirrel)?

It should be fairly straight-forward to implement native ARM support for packages on Windows, but I don't have an ARM machine currently so can't progress this at the moment.

To support applications being deployed to arm64:

• Add appropriate enumerations to RuntimeCpu
• Update AssemblyRuntimeInfo to check for ARM when detecting OS machine architecture
• Compile StubExecutable.exe, Setup.exe, Update.exe for arm64. (they are all x86 at the moment, technically windows on arm supports x86 emulation, so maybe we could skip this)
• Update SquirrelCli.Releasify to check for incompatibilities between x86/x64 and ARM when building packages and store the correct machine architecture into the package metadata.
• Also update SquirrelCli.Releasify to use the appropriate Setup86 or SetupArm64 (and Update86/etc...) depending on the package architecture.
• Update error message logic in Update.Setup when checking current architecture

To support compiling releases on arm64:

• Update WiX and investigate how to build an arm64 MSI (wixtoolset/issues#5558 (comment))
• Compile Squirrel.exe for arm64
• Add arm64 variants of other vendor binaries (rcedit, signtool, singlefilehost)

Related #17 and #35.

Problem

Currently an application will be running from a directory like app-1.0.1. The application binaries moving around in each version has several disadvantages:

• Application shortcuts (particularly taskbar-pinned ones) need to be continually updated
• File associations / url protocol mappings get broken on updates (as they need to point to an absolute exe location)
• Tray icons can not be pinned. There was an attempt to implement a fix for this in the original Squirrel by modifying a binary registry entry, but this does not work because Explorer keeps the pinned icons in memory and overwrites this value when it exits.
• Firewall rules will be lost on updates

A workaround for taskbar-pinned shortcuts exists, and StubExecutable's were created in an attempt to fix some of the other issues, but from the above, it only helps with shortcuts and associations/protocols that require a static exe location.

Tray icons and firewall rules are based on the currently executing process path - so these things remain broken.

Additionally, StubExecutable's create additional issues

• They are marked as WINDOWS_GUI_SUBSYSTEM, meaning they do not attach a console, and will fail to run a console app properly. (this could be fixed by patching stub's with the same subsystem as their target exe, but it is a significant unnecessary effort)
• They are C++ and windows-specific, meaning for #17 they will either need to be removed, or a cross-platform implementation would need to be created.

Proposal

• Squirrel extracts MyApp.nuspec into each app directory. This file can be parsed to determine the current version, and other metadata (like release notes), instead of relying on the folder name.
• We create and maintain a 'current' junction, which always points to the latest app directory.
• Stub's are removed, and shortcuts etc always point to %localappdata%\MyApp\current\MyApp.exe
• We add hooks at various startup points, such as during Update.exe:ProcessStart, UpdateManager.RestartApp which will update the current junction to point to the latest app version.

Even though the real binary location will still change in each version, as long as it's always executed via the junction, windows will see the binary path as %localappdata%\MyApp\current\MyApp.exe and all the aforementioned issues should work. This needs to be tested with firewall rules and tray icons beforehand.

Side note: If we are extracting the nuspec to each app dir and using it for metadata storage, perhaps we could automatically add a <squirrelFramework>...</> tag when creating releases, and verify that the required dependencies are installed before updating the junction (eg. for #9)

I have been trying to get the GithubUpdateManager working with a private github repo. After some investigating it looks like personal access tokens only with with github api calls and calls to github.com will fail. See here for a simular issue.

I have been trying to fix the issue myself but feel like i am going down a path of significant rework. I though it would make more sense to talk it out incase i have just missed something simple.

The root of the issue is here. There is a missing access token plus the url is to the browser url where it looks like it needs to be the api asset url. Something like https://api.github.com/repos/{org}/{repo}/releases/assets/{asset_id}. The accept header also needs to be application/octet-stream otherwise you will get a json response.

I feel like to get this method to work we would need to add some kind of abstraction layer for interfacing with the files that make up a release. Maybe the IFileDownloader is a good place to do this kind of work.

Which we unfortunately have a third party dependency on for one of our applications.

I could even try my hand at a PR if you want.

A number of things need to be considered:

• dotnet core runtimes are either x64 or x86. apps built with a win-x64 runtime identifier must have the x64 runtime installed and vice versa.
• we would need to allow user to choose to install an x86 runtime at setup (eg. net5, or net5-x86, or even net5,net5-x86 for both)
• we currently discover installed runtimes with dotnet --info, but this only returns x64 versions of the runtime because dotnet.exe is x64. We would need to parse the dotnet directory structure instead.
• Update.exe would need to ship with x86 and x64 versions (or be self contained, in which case just shipping x86 would be enough)
• Setup needs to be x86 (I think it already is but need to double check)
• Setup should check if trying to install an x64 app on an x86 OS and fail early.

I don't even know if this is a popular requirement yet. Do people still even ship x86 hardware in 2021?

If the package we're bundling contains "SquirrelLib.dll" we can check the version. If the version of the dll is not the same as the currently executing Squirrel.exe, we should show a warning (or maybe totally fail the release?) because mismatched versions could cause broken packages to be created that fail to update.

CreateShortcutForThisExe is only capable at creating shortcuts at built-in locations, but it could be desirable to create shortcuts in non-standard locations.

We should add an overload to this function allowing an absolute directory path to create the shortcut in.

Hi Caesy,

When there is a .net6 WPF Application with GenerateManifests=true in the .csproj, Squirrel Releasify will fail

<GenerateManifests>true</GenerateManifests>

[ERRO] System.ArgumentException: There are no SquirreAwareApp's in the provided package. Please mark an exe as aware using the assembly manifest, or use the '--allowUnaware' argument to skip
this validation and create a package anyway (at your own risk).
at SquirrelCli.Program.<>c__DisplayClass4_0.b__8(String pkgPath, ZipPackage zpkg)
at Squirrel.ReleasePackage.CreateReleasePackage(String outputFile, Func2 releaseNotesProcessor, Action2 contentsPostProcessHook) in C:\Source\Clowd\clowd-windows\modules\Clowd.Squirrel\s
rc\Squirrel\ReleasePackage.cs:line 120
at SquirrelCli.Program.Releasify(ReleasifyOptions options)
at SquirrelCli.CommandAction1.Execute(IEnumerable1 args)
at SquirrelCli.CommandSet.Execute(String[] args)
at SquirrelCli.Program.Main(String[] args)

If this setting is set to false everything works.

If needed I can provide a sample

Hi,

Do you have any plans to push your changes back to the main squirrel repo?

Best,
Andreas

If a splash image is shown and we need to download a dotnet framework, we show the progress in the task bar and over the progress window. If there is no splash image, there is no indication for the user the download progress. We should show a generic progress dialog while this is happening.

There are currently 3 binary files in the git repository. These should be removed and shipped as source code instead.

rcedit.exe

this can be removed/replaced entirely by including the rescle library inside of WriteZipToSetup. It also means we could generate Setup.exe in a single step (eg. WriteZipToSetup.exe Setup.exe --setZip blah.zip --setIcon setupIcon.ico --setSplash splashImg.png)

signtool.exe

can be distributed in the final builds & through nuget, but should be removed from source. can be grabbed from the current windows SDK automatically during builds.

update.com

how to build this file appears to be completely undocumented and frankly I have no idea. we should remove it and add a new minimal C++ project to the solution which is responsible for building this file. Ideally we'd be able to find the original source code somewhere.

Edit - 7zip and Wix are also being distributed in the source as binaries, but I don't think there's much we can do about that. Maybe we just update these to the latest versions.

https://techmonitor.ai/technology/cybersecurity/microsoft-teams-vulnerability etc.

Do we need to do anything about this? As long as we're not allowing privilege elevation is it a problem?
What can be done to mitigate risks of executing untrusted code?
Check for a matching code signature before --processStart?
Embedding update URL in Update.exe?

The entry in Programs and Features is determined by the --packName parameter to Squirrel.exe pack ...

According to the Squirrel naming conventions, that entry is set by the title property on the NuGet package metadata. Could we get a --title option added to pack to set this value when we are skipping the NuGet packaging? That way we could have spaces and dots in the Programs and Features entry.

Hi,
I'm having problems signing my application files using the "new" command squirrel pack.
The command is executed using custom publish target in VS .csproj.

Command:
<Exec Command="squirrel pack --packName=APPNAME --releaseDir=..\Version_Releases --packVersion=VERSION --packAuthors=&quot;COMPANY&quot; --no-delta --splashImage=.\APP_splash.png --packDirectory=bin\publish --setupIcon=.\Assets\APPBeli.ico --signParams=&quot;/t&#160;http://timestamp.digicert.com&#160;/sha1&#160;HASH&quot;" />

ERROR:
[ERRO] System.AggregateException: One or more errors occurred. (Failed to sign, command invoked was: 'C:\Users\usr.nuget\packages\clowd.squirrel\2.6.2-pre\tools\signtool.exe sign /t http://timestamp.digicert.com /sha1 HASH C:\Users\usr\AppData\Local\SquirrelTemp\tempd\lib\app\e_sqlite3.dll')
---> System.Exception: Failed to sign, command invoked was: 'C:\Users\usr.nuget\packages\clowd.squirrel\2.6.2-pre\tools\signtool.exe sign /t http://timestamp.digicert.com /sha1 HASH C:\Users\usr\AppData\Local\SquirrelTemp\tempd\lib\app\e_sqlite3.dll'
at SquirrelCli.Program.signPEFile(String exePath, String signingOpts)
at SquirrelCli.Program.<>c__DisplayClass9_0.<b__16>d.MoveNext()
--- End of stack trace from previous location ---
at Squirrel.Utility.<>c__DisplayClass13_11.<b__1>d.MoveNext()
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean )
at System.Threading.Tasks.Task.Wait(Int32 , CancellationToken )
at System.Threading.Tasks.Task.Wait()
at SquirrelCli.Program.<>c__DisplayClass9_0.b__7(String pkgPath)
at Squirrel.ReleasePackage.CreateReleasePackage(String outputFile, Func2 releaseNotesProcessor, Action1 contentsPostProcessHook)
at SquirrelCli.Program.Releasify(ReleasifyOptions options)
at SquirrelCli.Program.Pack(PackOptions options)
at SquirrelCli.CommandAction1.Execute(IEnumerable1 args)
at SquirrelCli.CommandSet.Execute(String[] args)
at SquirrelCli.Program.Main(String[] args)

The "SIGN" command is executed successfully using powershell.
The nbsp character ( ) was needed to use all the input parameters for sign command.

I've started looking into this project as a potential drop-in replacement for squirrel, which we currently have forked to apply some bug fixes. One of these is to avoid the installer creating shortcuts for every executable that is in the package directory.

As of net5.0 or net6.0 we noticed that createdump.exe is included as standard with dotnet publish output. We could probably trim this, but interested in your thoughts on whether there is a better way to explicitly define which shortcuts to make, rather than blanket creating them for all executables (seems like a very rare scenario that more than one would exist).

The fix we have applied is a bit of a hotfix one (ppy@db2bc0b), but does the job for our needs. If you can confirm that createdump is a common thing (seems to still be), it may be worth applying the same fix as an interim best-effort. I'm happy to PR that if it helps.

Thanks for the fork of Squirrel for .NET 6!
I'm porting an application to .NET 6 and this fork doesn't seem to be creating Start Menu and desktop shortcuts. It is properly installing everything into the %localappdata% folder. I am packing using the template (Squirrel.exe pack --packName "YourApp" --packVersion "1.0.0" --packAuthors "YourCompany" --packDirectory "path-to/publish/folder") found in the README. I've tried on my almost fresh install of Windows 10 and someone else's heavily modified system. Any thoughts?

It's common for apps to ship with a combination of .net and native binaries - those native binaries often dynamically link the vcredist and need it to be pre-installed. We can allow squirrel to install this - for example, a dependency list such as net6-x86,vc90-x86

This is just a suggestion.

GitHubUpdateManager uses a few "await", but it should be using ConfigureAwait(false):

Suggested Code Change:

using (var client = new HttpClient() { BaseAddress = baseAddress }) {
  client.DefaultRequestHeaders.UserAgent.Add(userAgent);
  var response = await client.GetAsync(releasesApiBuilder.ToString()).ConfigureAwait(false);
  response.EnsureSuccessStatusCode();

  var releases = SimpleJson.DeserializeObject<List<Release>>(await response.Content.ReadAsStringAsync().ConfigureAwait(false));

This change will avoid a deadlock in a scenario where the caller of GitHubUpdateManager() waits synchronously such as:

  var mgr = GetUpdateManagerAsync().GetAwaiter().GetResult();

If the caller uses the UI thread to invoke like this, the UI thread will wait for the task to finish, while GitHubUpdateManager() awaits a task and resume on the same UI thread. However, the UI thread cannot resume GitHubUpdateManager() because it's already waiting.

From Discord:

I'm back at this problem--it's been a while since I resumed the work. I upgraded to 2.8.1 and still get it. It's a Windows build box. [INFO] Program: Package architecture: X86 (implicit, from a SquirrelAware binary)
[INFO] Program: Creating stub executables
[ERRO] System.AggregateException: One or more errors occurred. (The system cannot open the device or file specified.)
 ---> System.ComponentModel.Win32Exception (0x8007006E): The system cannot open the device or file specified.
   at Microsoft.NET.HostModel.ResourceUpdater.ThrowExceptionForLastWin32Error() in ./Internal/ResourceUpdater.cs:line 472
   at Microsoft.NET.HostModel.ResourceUpdater.Update() in ./Internal/ResourceUpdater.cs:line 367
   at SquirrelCli.Program.createExecutableStubForExe(String exeToCopy) in ./Program.cs:line 388
   at Squirrel.Utility.<>cDisplayClass20_1`1.<<ForEachAsync>b1>d.MoveNext() in ./Internal/Utility.cs:line 323
   --- End of inner exception stack trace ---
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean )
   at System.Threading.Tasks.Task.Wait(Int32 , CancellationToken )
   at System.Threading.Tasks.Task.Wait()
   at SquirrelCli.Program.<>cDisplayClass4_0.<Releasify>b9(String pkgPath, ZipPackage zpkg) in ./Program.cs:line 237
   at Squirrel.ReleasePackage.CreateReleasePackage(String outputFile, Func2 releaseNotesProcessor, Action2 contentsPostProcessHook) in ./Internal/ReleasePackage.cs:line 123
   at SquirrelCli.Program.Releasify(ReleasifyOptions options) in ./Program.cs:line 187
   at SquirrelCli.Program.Pack(PackOptions options) in ./Program.cs:line 126
   at SquirrelCli.CommandAction1.Execute(IEnumerable1 args) in ./ValidatedOptionSet.cs:line 160
   at SquirrelCli.CommandSet.Execute(String[] args) in ./ValidatedOptionSet.cs:line 194
   at SquirrelCli.Program.Main(String[] args) in ./Program.cs:line 79
Squirrel (2.8.1-pre+bba777)

Build machine info:
Windows VM run via gitlab yaml pipeline
74GB free on C
245GB free on D
MSbuild 16.5.012.403
what other info do you need?
Uses General purpose ssd drives: gp2 hosted on Amazon EBS / elastic compute
OsName : Microsoft Windows Server 2019 Datacenter
OsType : WINNT
OsOperatingSystemSKU : DatacenterServerEdition
OsVersion : 10.0.17763
16GB RAM, 4 vCPU

Probably need to add some retry logic in and around the ResourceManager.Update method.

[13/12/21 16:48:56] info: ApplyReleasesImpl: Creating shortcut for Clowd.exe => C:\Users\Caelan\Desktop\Clowd.lnk
[13/12/21 16:48:57] error: IEnableLogger: Can't write shortcut: C:\Users\Caelan\Desktop\Clowd.lnk: System.NotSupportedException: Built-in COM has been disabled via a feature switch. See https://aka.ms/dotnet-illink/com for more information.

Since we're building Update.exe as a single file assembly, traditional COM is being disabled. We need to use ComWrappers to create shortcuts, or investigate if this can be turned back on? (<BuiltInComInteropSupport>true</BuiltInComInteropSupport>?)

The documentation on the installer seems a little light. I realize this is a carry over from the original squirrel branch but I was wondering if there was any arguments I could pass to the installer to make it quietly install with no autostart after install.