|
JackoBongo Posts: 7
07/12/2023
|
Hi,
I used to start SyMenu from a script (alongside other apps) and noticed since the 8.x it no longer works.
I've tried launching the app either from Powershell console on the standard prompt but neither of this method works. However if I double-click SyMenu.exe ... the application starts.
I've tried to update manually as described in a previous thread but this doesn't work either.
Am I the only one to encounter this problem?
|
|
|
link
|
|
Gianluca Administrator Posts: 1264
07/12/2023
|
Hi JackoBongo,
welcome to the community.
SyMenu has become fully portable from the 8.00 version. It means that it takes with itself all the libraries it needs to execute (you can find them inside the folder Lib).
So if you execute it in a way similar to that:
C:\>D:\Symenu\SyMenu.exe
you'll get an error (see it in the Windows event viewer) because your SyMenu.exe is searching for the dependencies in
C:\Lib
You have two solutions here:
1) Change your script defining the right working dir (SyMenu main folder).
2) Change your execution folder. To be clear this is an example using the Windows shell:
C:\>CD /d D:\SyMenu
D:\SyMenu>SyMenu.exe
Indeed you should solve the problem with two further solutions but I don't like them very much
3) Install .NET Core 8 in your system so that it's available everywhere for everyone. But you will have the same problem every time I change the framework in the future.
4) You can add the SyMenu\Lib in your environment variable Path but you cannot move SyMenu anymore without breaking the path for Lib again
edited by Gianluca on 07/12/2023
|
|
|
link
|
|
JackoBongo Posts: 7
08/12/2023
|
Ok, thanks for the fast feedback.
It works after changing the active directory.
However I've tried installing the "Microsoft .NET Runtime 8.0" and ".NET Windows Desktop Runtime 8.0" packages through winget and SysMenu wasn't starting if the working directory wasn't set.
edited by JackoBongo on 11/12/2023
|
|
|
link
|
|
Gianluca Administrator Posts: 1264
08/12/2023
|
JackoBongo wrote:
However I've tried installing the "Microsoft .NET Runtime 8.0" and ".NET Windows Desktop Runtime 8.0" packages through winget and SysMenu wasn't starting the working directory wasn't set.
Ok, so I'm learning a new thing here: the redirection I did to probe the Lib folder, prevents the runtime to be executed from its normal installation path. Thanks for this info even if, since I will take the framework with every new SyMenu version, it'll be useless for SyMenu.
|
|
|
link
|
|
JackoBongo Posts: 7
11/12/2023
|
Isn't it possible to specify multiple search paths for the libs? Or maybe have an entry-point executable that actually starts the "real" exe file after correctly setting the context.
Just saying because the current behavior feels kinda weird to me.
Anyway, thanks for the great job Gianluca 
|
|
|
link
|
|
Gianluca Administrator Posts: 1264
11/12/2023
|
Taking along the needed libraries it's not weird, think that it's a behaviour Java has allowed for decades.
Today it's possible for the new .NET Core framework too when you want to grant the best portability. They call this behaviour "self-contained deployment mode" and finally freed all the .NET programs (web or desktop) from the dependencies nightmare. When a program takes its own dependency along you are 100% sure it works on any machine. It's paradise!
Anyway, it's possible to allow flexible probing but I would have left all the libraries SyMenu needs on the root folder and I don't want that because this way you won't find the executable anymore.
I don't know if it's possible to redirect the local libraries to a custom folder (Lib) as I'm doing now and at the same time grant a normal probing on the local system but I will study this scenario too.
|
|
|
link
|
|
JackoBongo Posts: 7
16/12/2023
|
Gianluca wrote:
Taking along the needed libraries it's not weird, think that it's a behaviour Java has allowed for decades.
What I meant by "weird" was more the fact that dependencies paths are based from the active directory rather than the executable file location. But maybe this is intended with .NET 8.0
I assume it's not possible to generate a self contained binary where all libs are included right?
edited by JackoBongo on 16/12/2023
|
|
|
link
|
|
Gianluca Administrator Posts: 1264
23/12/2023
|
JackoBongo wrote:
What I meant by "weird" was more the fact that dependency paths are based from the active directory rather than the executable file location. But maybe this is intended with .NET 8.0
Indeed the suggested scenario for a portable program in .NET 8.0 is different because you should put the dependencies lib in the program root. Paint.NET for example is based on .NET 7.0 and works exactly the way Microsoft suggests. Try to open the Paint.NET main folder and you realize why I don't like the standard suggested way (dozens of meaningless files mixed with the main executable file scares anyone in my opinion).
So I hacked the SyMenu.runtimeconfig.json to redirect the libraries probing to the Lib folder. I think it's this redirection that creates a problem on the probing in system folders but, sincerely, who cares? You have all your dependencies included with every new SyMenu release and the update program cleans up every remains. IMHO it's a good option.
JackoBongo wrote:
I assume it's not possible to generate a self contained binary where all libs are included right?
Yes, theoretically it's possible and it's an option I'll probably investigate in the future.
|
|
|
link
|