Squirrel / Squirrel.Windows

An installation and update framework for Windows desktop apps
MIT License
7.35k stars 1.03k forks source link

WriteZipToSetup fails #671

Open DanSantimore opened 8 years ago

DanSantimore commented 8 years ago

Hi there,

Very thankful for this library. I'm happily learning and getting it worked into our CI, but I'm a bit out of my depth with the C++ and resource stuff you're doing.

May be related to #508

Version 1.4 via Nuget

I'm running --releasify against a file share from teamcity. For reasons I haven't been able to tease out, I very suddenly began receiving the following error in the log (though the process returns 0 to TeamCity):

2016-04-27 11:06:18> Program: Starting Squirrel Updater: -l='StartMenu' --releasify squirrel\Mercury.UI.1.0.52-qa.nupkg -r [share-name]\QA\releases 2016-04-27 11:06:18> Program: Bootstrapper EXE found at:D:\BuildAgentData\work\fc02c626e980fb22\squirrel\Setup.exe 2016-04-27 11:06:18> Program: Creating release package: [share-name]\QA\releases\Mercury.UI.1.0.52-qa.nupkg 2016-04-27 11:06:18> ReleasePackage: Creating release package: [share-name]\QA\releases\Mercury.UI.1.0.52-qa.nupkg => [share-name]\QA\releases\Mercury.UI-1.0.52-qa-full.nupkg 2016-04-27 11:06:20> ReleasePackage: Extracting dependent packages: [] 2016-04-27 11:06:20> ReleasePackage: Removing unnecessary data 2016-04-27 11:06:21> Program: Building embedded zip file for Setup.exe 2016-04-27 11:06:23> Program: Failed to update Setup.exe with new Zip file: System.Exception: Failed to write Zip to Setup.exe! Setup: [share-name]\QA\releases\Setup.exe, Zip: D:\BuildAgentData\temp\buildTmp\tmpC335.tmp Starting to read in Zip file! Updating Resource! Finished! Failed to update resource Usage: WriteZipToSetup [Setup.exe template] [Zip File] at Squirrel.Update.Program.Releasify(String package, String targetDir, String packagesDir, String bootstrapperExe, String backgroundGif, String signingOpts, String baseUrl, String setupIcon, Boolean generateMsi)

As I noted, teamcity isn't reading an error code (I'm assuming it's looking at std-out), but I receive the "dummy update.exe" error when attempting to run setup.exe

kenbailey commented 8 years ago

@the-dansan just a plug that we could really use some docs regarding integrating Squirrel with the TeamCity build process. I'd be happy to format any notes or steps you take down during the process. Good luck.

DanSantimore commented 8 years ago

Sure @kenbailey . I'm hardly an authority, but I would be happy to give you some details on what I did -- though we should probably make sure it works first :)

DanSantimore commented 8 years ago

I can pretty reliably reproduce this (though, interestingly, not every time) when running --releasify -r against a share (e.g. \sharename\releases). Seems to generally work fine when writing to a local directory.

JRKelso commented 8 years ago

We're using Squirrel with our build process on TeamCity. We're firing a Cake build script from the powershell build script runner in TC. That cake build script uses a Squirrel add-in we wrote to create the necessary files and then zip it up using Cake and send it up to an AzureStorage container for distribution with another AzureStorage add-in we wrote. This way your build process is build server agnostic.

HitomiTenshi commented 8 years ago

Mine's failing too and I it has pretty much to do with the size of my application.

Log:

Failed to update Setup.exe with new Zip file: System.Exception: Failed to write Zip to Setup.exe!

Setup: C:\Users\hitomitenshi\Documents\Apps\presenter\dist\Squirrel\Releases\Setup.exe, Zip: C:\Users\hitomitenshi\AppData\Local\Temp\tmpF71F.tmp

Starting to read in Zip file!
Updating Resource!
Failed to update resource

MyApp.nupkg is about 1.2 GB in size. It probably crashes, when it tries to insert that amount of space into the Setup.exe.

If I remove all my media files, (leaving the app at a size of 80 MB) the --releasify procedure works flawlessly.

anaisbetts commented 8 years ago

I don't think you can use Squirrel right now with such a large install, sorry :(

HitomiTenshi commented 8 years ago

It's just the same error that @the-dansan seems to have.

Maybe implement a check for now, checking the .nupkg filesize before embedding the zip file into the setup.exe? I had to search for a while until I actually found out, that the filesize was the problem.

Would save a lot of time for other people with big .nupkg files.

anaisbetts commented 8 years ago

Maybe implement a check for now, checking the .nupkg filesize before embedding the zip file into the setup.exe?

We could do this, but I'm not sure what the actual max value is - there's nothing in the Squirrel code that defines this as an arbitrary maximum, I'm not sure how big we can make files before the OS starts complaining or whether it's constant across every machine

owenayres commented 8 years ago

@HitomiTenshi, did you come up with a work-around/alternative solution to your problem? We're having the same issue and need to automate the creation of these installers. Our final app size is going to be as large as 4GB. I know this is an embarrassing size! Ours also fails when it hits around the ~1GB mark.

@paulcbetts Is there anything I can do to help with this? Do you believe there is a potential fix, or shall we start considering alternative methods?

HitomiTenshi commented 8 years ago

@owenayres I moved all media files outside our electron app now. We have implemented an import window before going into the main application logic.

We packed all our media data into a zip file, named it "media.import" and are extracting it's contents to our config folder located at %AppData% (on Windows). Once the data is there, we do not display the import window anymore (unless explicitly called by the user again).

This saves a lot of space on our installer. I would recommend moving your media files into some kind of external import file to import later on if you want to implement an update feature for your app. Having gigabytes of data on your nupkg files makes updating your app to newer versions a mess. (Not to mention it would also require lots of bandwidth.)

owenayres commented 8 years ago

@HitomiTenshi Thanks for the quick reply. I really like the sound of this solution. It would speed up our build process to be lightning fast, but there is one point I'm a little confused on. How does the import window work?

Let's assume I have a Setup.exe file sitting alongside a media.import file (or anything similar). I run the Setup.exe, which installs my Electron app without the media onto the computer. The app launches for the first time and will then try and begin the media import into the App's installed folder. How does it know where the media.import files sit on the computer?

Edit: Just realised you used the word external. Unfortunately our target market is mostly offline, so we'd need to include the media files alongside the lightweight installer package. That's why I'm not too sure this could work for us :(

HitomiTenshi commented 8 years ago

@owenayres Our import window talks to the electron main process (using ipcMain and ipcRenderer) in order to trigger an openFile window (see electron's dialog module). There the user then selects his "media.import" file. So the location of the import file doesn't matter.

For the extraction of the zip file we used npm package extract-zip. It's pretty straightforward.

During the createWindow() function I just check if the import has succeeded, here's a snippet:

// Check the import location
fs.access(importLocation, fs.F_OK, function (error) {
    if (!error) {
        // load the index.html of the app.
        mainWindow.loadURL('file://' + __dirname + '/index.html');
    }
    else {
        // load the import procedure
        mainWindow.loadURL('file://' + __dirname + '/import.html');
    }
});

You could of course do more checks, I kept it short for this example.

@ your edit: Our target market is "mostly" offline as well. We upload our Setup.exe and import files separately, our customer then downloads the latest Setup.exe and import file (when they have an available internet connection) and uses that for their offline app. With "external" I meant external as in, the import file is not bound to the location of the Setup.exe.

owenayres commented 8 years ago

@HitomiTenshi I see, thank you for the insight into your approach. The main problem we have is the client needs a super-simple installer that does everything, as our target market is teachers and students. We'll need to think of a way to automate that process if possible, or otherwise look for an alternative option for creating the installer.

Thanks again for the suggestion there, hopefully we'll be able to get something working!

twadrianlis commented 7 years ago

I am having the same issue but in my case no build server, no network shares or anything like that is involved yet. Simple local files on a disk. It can't be the size issue as the .nupkg file is around 70MB. I tried playing around with switches and nothing helped. Even the stripped plain '--releasify version' does not work.

I am running Squirrel like so:

Squirrel.com --releasify ..\..\editor\nuget\packages\x64\Twe.Project.Editor.x64.0.0.5-alpha.nupkg

It it makes any difference I am running Windows 10 x64.

What I am left with is Releases folder with Setup.exe that is around 210KB, Setup.msi, copy of my nupkg that has been slightly renamed by Squirrel and a .tmp file that is slightly larger than the nupkg file and I guess it was what was supposed to be inserted into the .exe file.

Any ideas?

craigmccauley commented 6 years ago

I was having this issue as well. My problem was that the Setup.exe file (the template one in the same directory as Squirrel.exe) was read only because I put it into TFS. I added a line to set it to not read only in my deployment scripts and I no longer have the issue.