New stub executable failing on non-Semver compliant packages #892

LoyalServant · 2016-12-05T16:57:57Z

Installed 1.5 from Nuget (previous 1.44) and ran a test to make sure applications would install properly.
After initial installation the app automatically runs.
If you close the app and try to run it again it simply does nothing.
Noting the shortcut is now the 'stub' application that's about 250kb or so in size
(I actually went back to 1.4.4 to verify that fixes it so I forget the exact size)

If I run this manually it does nothing.
I get no output when running it from the command line.
I tried various things like --help, /?, /h and so forth to see if I get any response but nothing.
It just runs and exits instantly.

There is nothing in the event viewer on either system tested. Both are Windows 10.
I wish I had more information to provide but there is just no indication as to what could the wrong here.

muffmolch · 2016-12-06T12:51:25Z

Same problem here. It starts the stub.exe needs about 644kb RAM and freezes... Is there any more detailed description??

TradePeg · 2016-12-07T14:28:04Z

Same problem here with version 1.5

anaisbetts · 2016-12-07T18:09:58Z

Can you tell me the name of the executable you're having issues with?

LoyalServant · 2016-12-08T05:41:41Z

Sorry for the late reply.
The executable is named "yourapp.exe" and it is the one that is created at install and linked to via the shortcuts created.
Info as described here:
#868

This is similar to how my installed tree looks.
There is a "yourapp.exe" and an update.exe at the install location with a subdirectory "yourapp-x.x.x.x" that contains the application. Running it from here works fine just the smaller "yourapp.exe" that is one directory up that is linked from the shortcuts fails to do anything.

If I can find time I need to dive into it some and figure out how this stub works and try to add some debugging to it if possible to work out if it's simply unable to execute the application and if so, why it cannot.

inech · 2016-12-08T08:17:24Z

Same problem with version 1.5

YoCsusu · 2016-12-08T12:33:50Z

Same problem with version 1.5

pdinnissen · 2016-12-08T19:16:54Z

I can confirm the same issue in Windows 7 for both WPF (32bit and 64bit) and Console applications.

The stub.exe always crashes (ie: %LocalAppData%\MyApp\Myapp.exe), but if I try the exe under app-x.x.x.x then that one works.

I've tried reverting to 1.4.4, but I can't ever get that one to work, it errors with:

---------------------------
hwhoops
---------------------------
This is a dummy update.exe. If you are seeing this, your build did not
correctly replace the IDR_UPDATE_ZIP resource.

Command Line: '--install . '
---------------------------
OK   
---------------------------

wocar · 2016-12-12T09:44:56Z

I am afraid of updating to 1.5 should I ?

inech · 2016-12-12T11:10:08Z

@wocar You can try if it works, for me it doesn't.

anaisbetts · 2016-12-12T17:56:38Z

The stub.exe always crashes (ie: %LocalAppData%\MyApp\Myapp.exe), but if I try the exe under app-x.x.x.x then that one works.

Wait, it crashes? What's the error?

matthewc-mps-aust · 2016-12-13T05:43:45Z

I don't know if this is related to this issue exactly, but I noticed that the StubExecutable does not support version numbers more than "x.x.x"; i.e., my app would not run from the stub with a version number of "2.1.0.1", but it worked fine with "2.1.0"

wocar · 2016-12-13T05:46:51Z

So is that the issue? I'm a bit worried/disappointed because we depend a lot on Squirrel for many programs we have. And breaking an upgrade will cause a lot of issues + time trying to reinstall on all the clients 😐 El El lun, 12 de diciembre de 2016 a la(s) 11:43 p.m., matthewc-mps-aust < [email protected]> escribió:

…

I don't know if this is related to this issue exactly, but I noticed that the StubExecutable does not support version numbers more than "x.x.x"; i.e., my app would not run from the stub with a version number of "2.1.0.1", but it worked fine with "2.1.0" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#892 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIycYYZ2J1BFxF9fqjwSdLyHvcephSxEks5rHjCUgaJpZM4LEdow> .

anaisbetts · 2016-12-13T08:33:54Z

I don't know if this is related to this issue exactly, but I noticed that the StubExecutable does not support version numbers more than "x.x.x"; i.e., my app would not run from the stub with a version number of "2.1.0.1", but it worked fine with "2.1.0"

I suspect this is the issue, we use a Semver library to compare version numbers, and shipping a non-Semver one was always incorrect but apparently seemed to work. NuGet packages are always Semver-versioned.

muffmolch · 2016-12-13T10:29:37Z

I see. Will there be a solution for that one?

matthewc-mps-aust · 2016-12-13T11:51:07Z

I suspect this is the issue, we use a Semver library to compare version numbers, and shipping a non-Semver one was always incorrect but apparently seemed to work. NuGet packages are always Semver-versioned.

I've just tried a Semver-versioned package (1.0.0-rc1) and it works - once I tweaked it to strip the "-rc1" from the args before passing to the SquirrelAwareApp.HandleEvents (it was crashing trying to convert that to a System.Version - shouldn't it be creating a SemanticVersion object?).

I also had to use NuGet.Core 2.14.0-rtm-832 to create the nupkg because the current NuGet doesn't like packing with a SemVer, but that's not Squirrel's issue...

pdinnissen · 2016-12-13T13:07:02Z

I can also confirm that dropping Revision from the assembly version fixes the issue I was encountering. Heads up to anyone using @poma's 'docs/using/visual-studio-packaging.md' that is should most likely be updated (see my comment in #630).

Not to be semver stickler but maybe 1.5 should have actually been 2.0.0? Since going to semver looks like a breaking change :S.

anaisbetts · 2016-12-13T18:03:41Z

Not to be semver stickler but maybe 1.5 should have actually been 2.0.0? Since going to semver looks like a breaking change :S.

NuGet packages have always been required to have SemVer versions, it just happened that some people got away with it and ignored the warning that NuGet prints out

pdinnissen · 2016-12-13T19:31:54Z

@paulcbetts I meant that having the Stub.exe enforcing SemVer potentially breaks existing systems if they upgrade. But then again... if they were always supposed to be SemVer... then it's not technically a breaking. I hate logic semantics (no pun intended).

I retract my 2.0.0 suggestion.

anaisbetts · 2016-12-13T19:45:05Z

@pdinnissen You're not wrong, but like, lots of stuff would be broken, including how we check for if you have the latest version (i.e. I'd be very very surprised if 2.0.0.0 => 2.0.0.1 would actually update the app)

pdinnissen · 2016-12-13T20:37:38Z

I just tested that a couple of days ago. It does in v1.4.1, but it is impractical.

muffmolch · 2016-12-14T08:19:06Z

Ok, just to get sure: neglecting the fourth version number ensures that every thing works fine again?

e.g. instead of 4.2.5.1 -> 4.2.5.2: 4.2.5 -> 4.2.6

pdinnissen · 2016-12-14T12:24:38Z

@muffmolch Correct.

anaisbetts · 2016-12-14T19:06:45Z

It looks like we've gotten to the bottom of this. To be super clear, I'm not happy that anyone is broken, and we do our best to have as few breaking changes as absolutely possible, but in this case I don't know how we can support this, since the Semver assumption is built into so many places in the app. Sorry again for the stress!

muffmolch · 2016-12-21T14:42:31Z

sorry, but it still does not work for me!

Do I have to change anything else to get it work again?

My install folder looks like that:

.\Local\RunCMake\app-5.7.3.0
.\Local\RunCMake\app-5.7.4.0
CefSharp.BrowserSubProcess.exe
RunCMake.exe
SquirrelSetup.log
Update.exe

The properties of my RunCMake in start menu ist:
target C:\Users\st\AppData\Local\RunCMake\RunCMake.exe
execute in: C:\Users\st\AppData\Local\RunCMake\app-5.7.4.0

The dummy RunCMake.exe needs about 800kB Memory, is pending some seconds an closes.. No app ist starting!

pdinnissen · 2016-12-21T15:34:32Z

@muffmolch You need to drop the last '.0' in your version for when you pack your nuget package.

muffmolch · 2016-12-21T16:00:47Z

ah! I see! no it works like a charm

wocar · 2016-12-21T22:23:11Z

Is it going to be fixed? El El mié, 21 de diciembre de 2016 a la(s) 10:01 a.m., Sören Textor < [email protected]> escribió:

…

ah! I see! no it works like a charm — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#892 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIycYRYfoeQ4CyQ_bR7Oqd43ROXSiF_Sks5rKU0zgaJpZM4LEdow> .

muffmolch · 2016-12-22T08:59:58Z

Fixed? Why? it works and just take a closer look at paulcbetts post and you'll see the answer for you question ;-)

poma · 2016-12-22T09:03:39Z

The only thing that needs a fix is documentation. I'm currently don't have time to verify @pdinnissen's solution to #630 so it would be nice if someone posts a quick update to docs.

arda-a · 2016-12-26T14:39:56Z

There should have been a big bold warning that explains the issue in the release notes at least. Phew, gotta revert the updates now.

anaisbetts · 2016-12-26T18:29:22Z

There should have been a big bold warning that explains the issue in the release notes at least. Phew, gotta revert the updates now.

This issue wasn't known at the time of release. Next release we'll make sure that releasify throws on this case so people don't get into it

kjellski · 2017-01-06T09:29:17Z

We're seeing the same issue here and the execution stub is recognized as a virus by antivirus scanners...
Is there a reliable way to check if this is exactly our problem?

@paulcbetts is there a version where releasify includes this already? We'd love to test that one ;)

anaisbetts · 2017-01-06T09:35:03Z

@kjellski a reliable way? Check the version number of your Nuget package. Does it have a fourth digit? If so, you're affected

anaisbetts · 2017-01-06T09:37:03Z

The fix is to remove the 4th digit, there will be no change to Squirrel to allow non Semver version numbers

kjellski · 2017-01-06T09:54:12Z

@paulcbetts we're using squirrel only through electron-builder(https://github.com/electron-userland/electron-builder). We don't produce any Nuget Package ourselves, any idea on how to debug this? Or should we maybe just get in touch with @develar on the matter?

Right now it seems that the stubs are beeing placed in the wrong fodler, always one directory too high in the file tree. We've got that behaviour for multiple *.exe files in the 'electron-app/resources' sub directories.

develar · 2017-01-06T10:52:29Z

@kjellski Please report issue to electron-builder.

develar · 2017-01-11T08:19:58Z

@paulcbetts electron-userland/electron-builder#1101 Reported that "Windows 8 & 10 work correctly" and "I've compared it with the older versions ( Squirrel.Windows 1.4.x) and the structure seems the same, same version number format." electron-userland/electron-builder#1101 (comment)

So, I guess, maybe Squirrel.Windows stub exe doesn't work on Windows 7 correctly?

anaisbetts · 2017-01-11T08:23:31Z

So, I guess, maybe Squirrel.Windows stub exe doesn't work on Windows 7 correctly?

This seems unlikely, we've shipped this to lots and lots of people at Slack on Windows 7 already

develar · 2017-01-11T08:28:13Z

@paulcbetts So, could you please explain

I've just tried a Semver-versioned package (1.0.0-rc1) and it works - once I tweaked it to strip the "-rc1" from the args before passing to the SquirrelAwareApp.HandleEvents (it was crashing trying to convert that to a System.Version - shouldn't it be creating a SemanticVersion object?).

Is version 1.3.2-demonl allowed for nuget packages or not?

anaisbetts · 2017-01-11T08:32:18Z

(it was crashing trying to convert that to a System.Version - shouldn't it be creating a SemanticVersion object?)

This is a known bug that's hard to fix because it requires exporting a type from our hacky internal version of NuGet.Core. However, HandleEvents is only called from C# applications, this will never get called in Electron anything.

Is version 1.3.2-demonl allowed for nuget packages or not?

Afaik, it should be, ya.

develar · 2017-01-11T08:37:43Z

electron-builder sets product-version and file-version for executables. Maybe users of windows-installer doesn't set versions and not affected by this issue. Or it is not related at all. Thanks for clarification. I will ask crash log for further investigation.

anaisbetts · 2017-01-11T08:44:08Z

@develar np, https://github.com/Squirrel/Squirrel.Windows/blob/master/src/StubExecutable/StubExecutable.cpp is the code that it's running, basically the gist of it is:

List all of the app-* directories under our app root
Sort by semver version, take the highest
Take whatever that directory is, add on whatever our current executable name is
Run it

YoCsusu mentioned this issue Dec 8, 2016

Multiple exe files in installation folder #894

Closed

anaisbetts changed the title ~~New stub executable failing?~~ New stub executable failing on non-Semver compliant packages Dec 13, 2016

anaisbetts closed this as completed Dec 14, 2016

GeekJosh mentioned this issue Dec 16, 2016

App crash on startup - BEX #905

Closed

joelweiss mentioned this issue Jan 9, 2017

App crashes on startup if there were 4 groups of digits in assembly version #917

Closed

TimvdEijnden mentioned this issue Jan 10, 2017

Crash after autoupdate downloads nuget package electron-userland/electron-builder#1101

Closed

develar mentioned this issue Jan 11, 2017

Stub crashes after extracting update #923

Closed

akashnimare mentioned this issue Jan 20, 2017

Zulip Electron not connecting, clash with Zulip Qt? zulip/zulip-desktop#101

Closed

simquad mentioned this issue Jan 26, 2017

SemVer - "But I don't want to" #937

Closed

phw198 mentioned this issue Apr 27, 2017

SquirrelAwareApp events not getting called #435

Closed

Thieum mentioned this issue May 21, 2019

VersionExtensions Regex does not support package ID ending with numbers #472

Open

New stub executable failing on non-Semver compliant packages #892

New stub executable failing on non-Semver compliant packages #892

Comments

LoyalServant commented Dec 5, 2016

muffmolch commented Dec 6, 2016

TradePeg commented Dec 7, 2016

anaisbetts commented Dec 7, 2016

LoyalServant commented Dec 8, 2016

inech commented Dec 8, 2016

YoCsusu commented Dec 8, 2016

pdinnissen commented Dec 8, 2016 • edited Loading

wocar commented Dec 12, 2016

inech commented Dec 12, 2016

anaisbetts commented Dec 12, 2016

matthewc-mps-aust commented Dec 13, 2016

wocar commented Dec 13, 2016 via email

anaisbetts commented Dec 13, 2016 • edited Loading

muffmolch commented Dec 13, 2016

matthewc-mps-aust commented Dec 13, 2016 • edited Loading

pdinnissen commented Dec 13, 2016

anaisbetts commented Dec 13, 2016 • edited Loading

pdinnissen commented Dec 13, 2016 • edited Loading

anaisbetts commented Dec 13, 2016

pdinnissen commented Dec 13, 2016

muffmolch commented Dec 14, 2016

pdinnissen commented Dec 14, 2016

anaisbetts commented Dec 14, 2016

muffmolch commented Dec 21, 2016

pdinnissen commented Dec 21, 2016

muffmolch commented Dec 21, 2016

wocar commented Dec 21, 2016 via email

muffmolch commented Dec 22, 2016

poma commented Dec 22, 2016

arda-a commented Dec 26, 2016

anaisbetts commented Dec 26, 2016

kjellski commented Jan 6, 2017

anaisbetts commented Jan 6, 2017

anaisbetts commented Jan 6, 2017

kjellski commented Jan 6, 2017

develar commented Jan 6, 2017

develar commented Jan 11, 2017

anaisbetts commented Jan 11, 2017

develar commented Jan 11, 2017

anaisbetts commented Jan 11, 2017 • edited Loading

develar commented Jan 11, 2017 • edited Loading

anaisbetts commented Jan 11, 2017

pdinnissen commented Dec 8, 2016 •

edited

Loading

anaisbetts commented Dec 13, 2016 •

edited

Loading

matthewc-mps-aust commented Dec 13, 2016 •

edited

Loading

anaisbetts commented Dec 13, 2016 •

edited

Loading

pdinnissen commented Dec 13, 2016 •

edited

Loading

anaisbetts commented Jan 11, 2017 •

edited

Loading

develar commented Jan 11, 2017 •

edited

Loading