New stub executable failing on non-Semver compliant packages

[LoyalServant]

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]

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

[TradePeg]

Same problem here with version 1.5

[anaisbetts]

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

[LoyalServant]

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]

Same problem with version 1.5

[YoCsusu]

Same problem with version 1.5

[pdinnissen]

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]

I am afraid of updating to 1.5 should I ?

[inech]

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

[anaisbetts]

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]

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]

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]

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]

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

[matthewc-mps-aust]

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]

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]

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]

@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]

@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]

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

[muffmolch]

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]

@muffmolch Correct.

[anaisbetts]

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]

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]

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

[muffmolch]

ah! I see! no it works like a charm

[wocar]

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]

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

[poma]

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]

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]

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]

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]

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

[anaisbetts]

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

[kjellski]

@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]

@kjellski Please report issue to electron-builder.

[develar]

@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]

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]

@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]

(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]

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]

@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:

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