Self-update isn't working properly about gbclv3 HOT 4 CLOSED

After the self-update the crashing information in Reliability Monitor below:
在自更新后在可靠性监视器下崩溃信息如下：

Faulting Application Path:	***\GBCL.exe

Problem signature
Problem Event Name:	APPCRASH
Application Name:	GBCL.exe
Application Version:	3.0.8.81
Application Timestamp:	5dedc13b
Fault Module Name:	KERNELBASE.dll
Fault Module Version:	10.0.18362.628
Fault Module Timestamp:	f96f12ee
Exception Code:	e0434352
Exception Offset:	000000000003a839
OS Version:	10.0.18363.2.0.0.256.48
Locale ID:	4105
Additional Information 1:	b7d1
Additional Information 2:	b7d191a43339ec4ccfc3a8ae5f8a2352
Additional Information 3:	c2a2
Additional Information 4:	c2a2fe471b5c4cff2414cf3489cc3e0a

According to the clue from procmon.exe, delete the folder %TEMP%\.net\GBCL can make the executive (still the origin version before update) work again.
目前根据 procmon 找到的线索来看，删除 %TEMP%\.net\GBCL 文件夹即可使原程序恢复运行（依然为更新前的版本）。

First run after self-update information in Task Manager below:
以下是更新后首次运行的任务管理器截图。

Guessing what the self update the update the executive happened:
推测更新程序时发生的事情：

• 更新程序下载新程序 Self-update downloads the new executive
• 新程序被移至 %TEMP%\.net\GBCL\********.***\ 文件夹下并被重命名为 GBCL.DLL （之前的同名 DLL 被重命名为 GBCL.old） The new executive is moved to the folder %TEMP%\.net\GBCL\********.***\ and is renamed as GBCL.DLL (the origin DLL file is renamed to GBCL.old in this step)
• 重启后运行的为上一步的 GBCL.DLL Restart and run the GBCL.DLL from the previous step
• 关闭程序 Shutdown the program
• 重新运行程序。程序运行时发现 GBCL.DLL 异常（不是之前 700+K 的文件，更新后实际上这个 DLL 变成了一个完整的 EXE 文件），无法执行，崩溃退出 Click the executive to run. The executive find the GBCL.DLL is not what it used to know (not the 700+K size one, but actually the self-update downloaded the FULL executable) and can't proceed and crash

Alternative:
变通方法：

1. 手动在 GitHub Release 上下载新版本文件替换而不使用内部更新 Directly download the new executive from GitHub Release rather than using the self-update
2. 如果执行了内部更新，删除 %TEMP%\.net\GBCL 文件夹，或者将 %TEMP\.net\GBCL\********.***\GBCL.old 重命名为 GBCL.dll（运行为旧版本） If you have run the self-update, delete the folder %TEMP%\.net\GBCL or rename the file %TEMP\.net\GBCL\********.***\GBCL.old to GBCL.dll (now it should run as the origin version)
3. 如果执行了内部更新，将 %TEMP%\.net\GBCL\********.***\GBCL.DLL 移动至原来启动器目录下并更改扩展名为 exe If you have run the self-update, move the file %TEMP%\.net\GBCL\********.***\GBCL.DLL to the launcher folder and rename its extension to exe

That's all I know and hope it would help.
目前已知情况如上，希望有所帮助。

from gbclv3.

It turns out that in .NET Core, the single-file executable (GBCL.exe) is actually extracted to %TEMP%/.net/GBCL/ and the GBCL.dll in the temp folder is what really runs by the .NET Core runtime. See Extracting Bundled Files to Disk

This is why during the self-update, the current path returned by Application.ResourceAssembly.Location is the path to the dll instead of that to the executable, so the old GBCL.exe is not properly replaced. 😪

Possible solution is to use Process.GetCurrentProcess().MainModule.FileName to get current executable path。

在 .NET Core 中，单文件打包的 GBCL.exe 会在执行时被解压到临时文件夹 %TEMP%/.net/GBCL/ 而其中的 GBCL.dll 才是 .NET Core 运行时真正执行的文件。见 Extracting Bundled Files to Disk

这就是为什么在进行自升级时，由 Application.ResourceAssembly.Location 返回的当前路径是到 dll 的路径而不是到 exe 的路径，因此旧的 exe 没有被正确替换。😪

可能的解决方法是使用 Process.GetCurrentProcess().MainModule.FileName 来得到当前可执行文件的路径。

from gbclv3.

If the launcher isn't working after self-updating, please download the latest version from GitHub release and replace the old executable file.

如果遇到自动更新后打不开的情况，请先暂时从 GitHub release 下载最新版启动器替换原文件。

from gbclv3.

It may be the bug about acquiring the file path and I agree.
When testing the self-update function, I found a file seems like a temporary file besides the packed executable, and it disappeared after the download (maybe after the update).
And, the problem is related to the extraction mechanism of the packed .NET Core executable, I made a test on the packed executable:

1. Remove any DLL file in %TEMP%\.net\GBCL\<bundle-id>\ : the program quit silently and nothing changed in the folder, Reliability Monitor found nothing;
2. Empty %TEMP%\.net\GBCL\<bundle-id>\ : like above, quit silently and nothing happened;
3. Remove %TEMP%\.net\GBCL\<bundle-id> : all file extracted and the app ran normal;
4. Replace the DLL file with a wrong file (even not a DLL): the app crashed, nothing changed in the folder and crash record found in Reliability Monitor ( APPCRASH or CLRxxrx according to the bad DLL file).

Seems it didn't check the files when %TEMP%\.net\GBCL\<bundle-id>\ exists, no extracting and even no checking the integrity to avoid the unexpected change on previous extracted files. But according to https://github.com/dotnet/designs/blob/master/accepted/single-file/extract.md#extraction-mechanism , it should have gave it a check here.
Weird.

大概是更新操作的路径获取上引发的 bug ，同意。
在测试自动更新的时候还留意到，下载过程中原来的可执行文件旁边的确会生成一个类似临时文件的文件，但在下载升级后这个文件消失了。
另外，既然这个问题跟 .NET Core 的单文件打包解压机制有关，做了一点试验：

1. 删除 %TEMP%\.net\GBCL\<bundle-id>\ 下任意一个 DLL 文件：程序安静地退出，文件夹内文件没有变化，可靠性监视器没有痕迹；
2. 清空 %TEMP%\.net\GBCL\<bundle-id>\ ：同上；
3. 删除 %TEMP%\.net\GBCL\<bundle-id> ：文件重新解压，程序正常运行；
4. 将正确的 DLL 文件换成错误的（甚至根本不是 DLL）：程序崩溃，文件夹内文件没有变化（包括大小），可靠性监视器有崩溃记录（视文件报告 APPCHASH 或者 CLRxxrx ）。

似乎和启动时没有校验文件有关，只要 %TEMP%\.net\GBCL\<bundle-id>\ 存在就直接使用里面的文件而没预料到文件发生变化进行校验和重解压。但根据 https://github.com/dotnet/designs/blob/master/accepted/single-file/extract.md#extraction-mechanism 的描述来看，这里本来应该（至少）校验文件是否存在的。
就很奇怪。

from gbclv3.