.net core .exes are not detected as squirrel apps even with SquirrelAwareVersion

[mungojam]

Squirrel version(s)
1.9.1

Description
I am deploying a .net core 3 console application with squirrel, which mostly works. But the tool is not detected as a squirrel aware app so never gets called with --squirrel-install when being installed. This is despite the fact that I have added the required SquirrelAwareVersion version info to the file.

I can tell why it is happening and it is due to the fact that Squirrel is looking for the resource under US-English, language, but .net core and then rcedit adds what looks like a universal language resource instead. See below for my generated resource.

I sort of understand the reason for not searching all languages, but could this universal language be added as an additional search for the squirrel-aware setting?

Steps to recreate

1. md dotnet-test
2. cd dotnet-test
3. dotnet new console
4. dotnet build -r win-x64
5. get rcedit-x64 from https://github.com/electron/rcedit/releases/tag/v1.1.1
6. rcedit-x64.exe bin\Debug\netcoreapp3.1\win-x64\dotnet-test.exe --set-version-string "SquirrelAwareVersion" "1"

Expected behavior
If we manage to add the SquirrelAwareVersion to a .net core exe, then it should be detected by squirrel as a squirrel aware application

Actual behavior
The tool is not detected as a squirrel aware application

Additional information

Using Resource Hacker I can see that the block that has been created has a different language code (000004b0) than what squirrel is looking for. I guess this is a universal one when Squirrel is looking for US-English.

	BLOCK "000004b0"
	{
		VALUE "CompanyName", "dotnet-test"
		..other standard stuff
		VALUE "Assembly Version", "1.0.0.0"
		VALUE "SquirrelAwareVersion", "1"
	}

[lars-29palms]

Unfortunately I ran into the same issue today with my .NET Core 3.1 application which I can't make SquirrelAware.
The problem is, it's using CefSharp which creates a shortcut on the desktop as well.
A workaround is to run the Updater.exe from code: Update.exe --removeShortcut=CefSharp.BrowserSubprocess.exe

This is a bit hacky though. Have you found a better workaround for this already?

[mungojam]

This is a bit hacky though. Have you found a better workaround for this already?

Fortunately we don't have that particular problem as we don't have other exes but the thought had crossed my mind. And we've done an even hackier workaround to get the stub executable and shortcut to it to be created automatically for any exe.

I'm glad to see that maintenance of this repo has picked up again. It's a really neat tool just in need of some loving. I will try and create a PR for this one and have some more confidence now that it will get considered

[WilliamForsdal]

Hey guys. I have the same issue. Dotnet core apps have the wrong block code 000004b0 instead of 040904B0 so squirrel doesn't detect it.

What's the status on that PR @mungojam ? What changes did you want to make to implement a fix for it?

Just as a test, I used Resource Hacker to change the language of all resources to english-US and added VALUE "SquirrelAwareVersion", "1" to the block... and it works! But it doesn't feel very good. Then I have to use Resource Hacker in my release script to modify the resources of the EXE... not so nice.

I also tried cloning squirrel myself and adding this line in SquirrelAwareExecutableDetector.cs GetVersionBlockSquirrelAwareValue:

if (!NativeMethods.VerQueryValue(buf, "\\StringFileInfo\\00004B0\\SquirrelAwareVersion", out result, out resultSize)) {
    return null;
}

But I ran into some issues and gave up on that.

Any feedback about this issue would be much appreciated.

[mungojam]

Sorry, I didn't get around to it in the end and now I've had to move onto other things. I'd love it to get fixed still but the workaround works for our current tools for now.

[WilliamForsdal]

Thanks for the fast reply. I will look into it more then, and see if I come up with anything.

[ComtelJeremy]

@WilliamForsdal Anything you have found since your last post? Looking into this myself a bit now, as our app has two exes, and we would like to move it to Core soon...

.NET 5 can now add an AssemblyMetadata via the csproj like so:

<ItemGroup>
    <AssemblyMetadata Include="SquirrelAwareVersion" Value="1" />
  </ItemGroup>

But I can't seem to see it in the compiled exe or dll with Resource Hacker...
@mungojam Can I ask how you were able to get the build to put that in the Version Info? Was it only on a dotnet publish?

I also found you could change the Assembly Neutral Language, which I hoped would change the language for the Version Info block, but I am not sure now as I can't even get the SquirrelAwareVersion into the wrong block code...

Any ideas?

[mungojam]

But I can't seem to see it in the compiled exe or dll with Resource Hacker...
@mungojam Can I ask how you were able to get the build to put that in the Version Info? Was it only on a dotnet publish?

@ComtelJeremy I'm now seeing the same as you. I'm pretty sure that I saw it in Resource Hacker previously, maybe on an earlier .net version. I think I may have only seen it in the .dll and not the accompanying .exe, but I could be remembering incorrectly.

[mungojam]

@ComtelJeremy

It shows up in dotpeek for the .dll as a detectable attribute, but not for the .exe. So I expect squirrel could be made to detect it explicitly but it would have to find the .exe, then look for the associated dll and read the attribute.

I've checked my original post and I described how I used rcedit to add the SquirrelAwareVersion to the .exe such that it is picked up, which presumably worked. I have found that it corrupts some other .exes though so I wouldn't necessarily rely on it.

[mungojam]

I've put together this PR which fixes my specific problem and removes the US specific requirement. The discussion has also given me an idea for a full fix that would remove the need for the rcedit post-build shenanigans.

[mungojam]

Sorry for the spam. My PR now fully fixes support for .net core. Please give it a test if you can.

[WilliamForsdal]

Really nice @mungojam , I will give this a try.

[mungojam]

The situation is worse with .net 5 because it includes createdump.exe as standard in the deployment. So in all cases you will have at least 2 executables that Squirrel will try and run. I hope my PR can be merged to resolve this.

[ComtelJeremy]

Hi, @anaisbetts. Many thanks for all your work on Squirrel over the years. Just wondering if there is any chance you would please be able to merge this or something like this? We want to move our app to Core (now .NET 6) but this is blocking us as we have 2 exe's in our app. (One of them is a seldom used service that required admin permissions, which we run only when needed so that most users don't have to worry about elevating). Also, the problem is compounded for every .Net 5 or 6 app, since createdump.exe is now included in published apps, even if they are only one exe.

Is there anything we can do to help with moving this along? If so, please just say the word and we will do our best to assist.

[SeriousM]

The situation is worse with .net 5 because it includes createdump.exe as standard in the deployment. So in all cases you will have at least 2 executables that Squirrel will try and run. I hope my PR can be merged to resolve this.

My workaround is to remove the shortcuts right after application start so that the user isn't aware of this problem...

[AArnott]

@mungojam Does your PR resolve the CreateDump.exe shortcut problem too?

[mungojam]

@mungojam Does your PR resolve the CreateDump.exe shortcut problem too?

@AArnott as you found and commented on the PR, it does. Thanks for publishing a version of the package with it. We may switch to that if this isn't resolved here soon.