Closed Nutzzz closed 1 year ago
Visual Studio was not happy when I tried to publish, but I'll look into the settings you've mentioned and try to get a single exe release
I just upgraded to VS2022 and am updating the project to .NET 6, and it looks like EnableCompressionInSingleFile requires SelfContained to be True, so that means you should set EnableCompressionInSingleFile to False.
I've tested the 1.2.0-alpha and I've the following error :
21:16:04.374 › You must install .NET to run this application.
Architecture: x86
App host version: 6.0.9
.NET location: Not found
Learn about runtime installation:
https://aka.ms/dotnet/app-launch-failed
Download the .NET runtime:
https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x86&rid=win10-x86&apphost_version=6.0.9
Do you think there is a way to have a complete self run app without external dependencies like .NET 6?
Do you think there is a way to have a complete self run app without external dependencies like .NET 6?
Well, it's always been a .NET app, but it used to leverage the .NET Framework v4 that's included with Windows.
There's a way to include the framework ("self-contained"), but that obviously makes the file quite a bit larger.
As far as why we don't just stay with Framework v4.8, we're just keeping up with the times (for our education, as a best practice, and to enhance the program's performance). Note that .NET 7 was just released, though 6 is the long-term support version. The cross-platform versions are the new standard (it used to be called ".NET Core" until .NET 5, when the Framework and Core flavors became unified). I'm not sure whether the newer versions will ever be included in Windows again (there are good arguments why it "shouldn't*, but that's a lot to get into here).
Hi. Sorry for not really communicating or doing much besides approving PRs. I just started a new job and it happens to be C# as well so I didn't have the time, nor the motivation to write code in my spare time. But I am starting to get back into it now - I want to complete version 2 as soon as I can to start work on some other projects.
Firstly, allow me to also apologise for not dealing with the "single binary" stuff. I couldn't get it to work without the Fody
plugin. Maybe I didn't try hard enough
To answer your question, there are a few options:
My personal opinion is that we should go for .NET 6/7 or .NET Core 3.1 (I would have to do some testing regarding running the app on fresh windows and Linux installations). I wish I could rewrite the app but it would be too much work and I wouldn't want to force a different language on people.
Also regarding the "single-binary" stuff. Version 2.0 will not be shipped that way. I have probably mentioned it, but V2 will have platforms implemented as standalone dlls and there will be a shared dll for both the client and the extensions - more information will hopefully come soon.
Either way, let me know what you think.
Hi. Sorry for not really communicating or doing much besides approving PRs.
No need to apologize, life happens.
Firstly, allow me to also apologise for not dealing with the "single binary" stuff.
No problem, but could you make it clear what happens when you follow the publish instructions in the README? Even if it's something you can figure out if you "try hard enough," if nothing else it'd be nice to know what the pain point might be for others.
I'd really like a Linux version for myself.
I expect making GLC v2 genuinely Linux-compatible for most of the various distros is going to be something of an interesting task, though I know that not all of our supported launchers have proper Linux versions.
My personal opinion is that we should go for .NET 6/7 or .NET Core 3.1
It doesn't make sense to go back to 3.1. As you say, it's nearly end-of-life, and we could always make a self-contained .NET 6/7 if we really wanted to include the necessary portions of the framework. For the moment, I feel like the error message @samuelmichaud got is sufficient to explain the issue and the resolution for v1.2, but I suggest we also add something to the README.
I have probably mentioned it, but V2 will have platforms implemented as standalone dlls and there will be a shared dll for both the client and the extensions
Right, but I'd suggest we still use single-file publishing with v2 just so we don't have that big mess of dlls in the install directory to wade through. Note you can use ExcludeFromSingleFile for any dlls that are part of the main project that you want to leave unbundled.
Like @Nutzzz said, life is life, no apologies needed ! What you have done is already great ! :)
I have probably mentioned it, but V2 will have platforms implemented as standalone dlls and there will be a shared dll for both the client and the extensions
Right, but I'd suggest we still use single-file publishing with v2 just so we don't have that big mess of dlls in the install directory to wade through. Note you can use ExcludeFromSingleFile for any dlls that are part of the main project that you want to leave unbundled.
From my point of view, single-file publishing is great, but the most important stuff is : "works & run out of the box" / portable / "no any setup or requirements". :)
Got a standalone binary build for 1.2.0. Closing
Thanks for posting v1.2.0, @Solaire !
Note, however, that we don't need all of the stuff you've included in the .rar, as the .exe that is the result of the dotnet publish is all that's necessary for a release (since we're setting PublishSingleFile and IncludeNativeLibrariesForSelfExtract in the .csproj to True). The downside of this approach is that a RuntimeIdentifier must be specified so you don't get the "AnyCPU" possibility (and I've set it to win-x86 instead of -x64 for... reasons).
Note that I've played with these related settings and SelfContained, PublishTrimmed, and PublishReadyToRun need to be set to false. IncludeAllContentForSelfExtract could be set to true for release but it makes debugging harder. I've also set EnableCompressionInSingleFile to true, which isn't supported in .NET 5, but looks like a nice feature in .NET 6.
While I'm looking at this, it looks like we should probably remove the BootstrapperPackage includes for .NET Framework 4.7.2 and 3.5.